octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: overloaded function handles


From: Robert T. Short
Subject: Re: overloaded function handles
Date: Mon, 27 Jul 2009 11:34:29 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090606 SeaMonkey/1.1.17

Jaroslav Hajek wrote:
On Mon, Jul 27, 2009 at 7:33 PM, Robert T.
Short<address@hidden> wrote:
  
John W. Eaton wrote:
    
On 27-Jul-2009, John Swensen wrote:

| I think patent number 6,857,118 is the more applicable one: "Function  |
values in computer programming languages having dynamic types and  |
overloading."

Yes, sorry.  I pasted the wrong number in.

|  That being said, I find it ridiculous that the ability  | to overload a
function by string name is actually patentable.  There  | has got to be gobs
of languages that did the same thing before this  | patent was issued,
right?

Yes,  I agree that the claims for using '@' and 'feval' seem to go too
far, and I don't see how they could hold up, but they could.

However, if I understand it correctly, that's not the major point of
this patent.  Instead, the point is that you can create a function
handle in one context, and then use that handle in another context to
call a function, and the dispatch will be determined by the arguments
given and information about which functions are available at the point
where the funtion handle was created, not where it is used.  Do you
know of prior art for that?  Is there a way to implement this feature
in a way that does not use the method described in the patent?  The
language of claim 1 seems fairly broad.

jwe



      
Just glancing through the patent, I don't see how it is possible to avoid
infringing.  I also don't see how a patent like that ever issued, but that
is really beside the point.
    

I second that. While I haven't read the patent, what John sketched
seems simply (and obviously) necessary for any reasonable
implementation of the mere idea of taking a handle from an overloaded
function.

  
Since the patent has issued it has already been
evaluated for obviousness and prior art.  Even if you know of prior art,
challenging an issued patent is not likely to be a pleasant or cheap
endeavor.

I am not a member of any patent bar so this certainly can't be taken as
advice.  I have, however,  spent an absurd amount of time in the patent
infringement world.  I will take a look.  It will take some weeks though.  I
am seriously over committed at the moment.  For the time being, I would say
not to worry about it, but we do need to recognize that all the Mathworks
has to do is file a lawsuit and we will have to react - probably just by
immediately pulling contested features out of the language (or maybe pulling
octave from all U.S. distribution sites?) while we examine the problem.
 Since there is no profit involved, there won't be any royalty issues, or at
least I don't think so.

    

Although I agree that some action would be desirable in the case of
infringement threat, probably reverting the relevant changes, I would
also plead for a way to keep the useful feature working for those of
us not (yet, at least) affected by this patent. The idea of forking a
"patent-safe" branch of Octave is not very nice, though. Hmm - does
the mere fact that I uploaded those changes create problems for anyone
in USA? What if they use Octave, but don't use overloaded handles?
What if there's a global flag to disable it, i.e. turn the infringing
code into dead code? Is that acceptable? Better consult a lawyer, I
guess.

  
I will talk to my patent attorney this evening.  I don't believe that the *user* has any liability.  The octave developers are probably the liable parties, but I don't really know nor do I really know what the ramifications or penalties are.

I like the idea of turning off the feature so that those of you not in the U.S. can continue to use the feature in case of disaster.  I am not sure we need a whole patent-safe branch.  Maybe just a patch that non-U.S. users can apply that turns the code on.

Keep in mind that this is a tempest in a teapot at the moment.  Let me do some "due diligence" before we put any real effort into this.  It would, however, be worth thinking about the turn-off mechanism now but first I should find out what is acceptable.

I will chat with Matt and report back.

Bob


reply via email to

[Prev in Thread] Current Thread [Next in Thread]