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: Fri, 31 Jul 2009 20:42:58 -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 Thu, Jul 30, 2009 at 10:38 PM, Robert T.
Short<address@hidden> wrote:
  
Jaroslav Hajek wrote:
    
I would stretch it even a little farther - I wouldn't like the feature
to be removed or severely crippled (yes, performance also matters)
just to workaround a US patent (and I still say workaround would be
darn hard), because I want to use it. OTOH, I understand that this may
be a really big problem for users from USA, so maybe we should really
fork. This particular patent is fairly broad (intentionally, no
doubt), but even if it can be worked around, future patents may not
be.

Finally, one more, slightly silly idea: What position would the
Mathworks take on this matter? Maybe they wouldn't actually mind to
make some sort of license disclaimer, giving Octave users from USA the
license to use the feature? Or at least for non-commercial use
(provided that it's not automatically guaranteed by the law)?

      
Well, I am a U.S. citizen and have never felt unfortunate.  I also am OK
with the idea of software patents, but this one seems to egregiously
violate the obviousness criteria.  The U.S. patent system has gone kind
of whacko in recent years to the point that the U.S. Congress and the
USPTO are really rethinking the problem.  Unfortunately this patent has
already been issued.


I don't think we should cripple octave for some silly U.S. issue.  I am
meeting with my patent attorney for some other matters in the next few
weeks and we have put this on the agenda.  I will get some formal
advice.  I will ask him about the whole problem including remedies and
penalties, but for the short term here is what I think we should do.

First, Jaroslav (and anybody else working this problem), just do the
work so that this feature is available.

Second, I don't think a simple compile-time flag is enough.  However
suppose you leave some critical piece of the code out so the feature
can't simply be compiled back in.  Then create a patch that is available
only from a non-U.S. web site that enables the code.  For example, maybe
just pull the parser section out or brain-damage the data structure or
something that makes it nontrivial for a U.S. user to recreate the
feature.  The patch will not be available in the U.S. and so I think we
have demonstrated a willingness to abide by the U.S. patent laws.  If
this isn't enough, I will get real advice on how to proceed.

Of course, we can't prevent U.S. residents from downloading the patch,
but I don't think that is really our problem.  This is not a new issue.
The debian distribution used to (still does?) have a nonus portion of
the archive mostly because of encryption and other export issues.

I would really like to avoid a whole fork.  That may be the best way to
manage it, but it seems like a small set of patches would suffice.

    

To me, having a separate branch seems much simpler. It would be a real
burden to always reapply a set of patches when rebuilding Octave (and
I do that often). A patent-free branch could be hosted on Thomas
Weber's site, for instance. The main point is, that while I like
developing Octave, I'm really not willing to scan through the US (or
any other, for that matter) patent database for possible
infringements, so I can't guarantee that I won't create more
infringements in the future.


  

Hmmm.  I apply a set of local patches every time I pull from savannah (at least once each week).  Doesn't seem like much of a burden.  Once in a while I have to fix the patches because of changes, but not often.  On the other hand, I was suggesting a short term fix.  At this point all we know is that we might infringe a patent.  It doesn't make much sense to create a real infrastructure to deal with a situation we don't really understand.  Furthermore, I don't really care how we do it.  In fact as long as I am not personally liable I don't even care IF we do it.  It was just a suggestion.


  
If anybody else has access to the appropriate attorney types it wouldn't
hurt to get some other advice.  Also, even though I think it unlikely,
would it hurt to ask the Mathworks folks about some sort of
permissions?
    

The problem is whom the permission would be given to, and how. I think
it can't be made part of the license, because then it couldn't be
limited to non-commercial usage (due to GPL).

  

Well, it WAS your idea.  I think it is incredibly unlikely that the other guys would license octave to use anything.

I think we just see the negative effect of software patents in
reality. If there was always an easy way out, they wouldn't be such an
issue.
  


This is simply a reality of the patent system.  Not just software patents.


So, I would like to warn any Octave users whom it may concern, that
the development archive of Octave infringes certain US software
patents (this might have been true even before, but now it's almost
sure), with all possible implications for users of Octave in USA.

  

Sounds good. 


Some notes.

In the following, remember my "I ain't a patent attorney" disclaimer.  I am simply interpreting some readings and really don't KNOW anything.

Here is a quote from a patent law text.

"use of a patented device which has been legally purchased does not constitute infringement"

Even though octave is not purchased, our users obtain the product legally and are probably not liable to infringement charges.  The point here is that the users of octave are very unlikely to have penalties applied for the use of the product.  I know that there have been attempts to impose fees on users of allegedly infringing products (c.f. Jaroslav's earlier message), but I feel this is simply a scare tactic.  I think it very unlikely that any U.S. court would approve any penalties for users that honestly obtained the software (opinion!).

In contrast, I am reasonably sure that the octave developers are at risk for liability.  Since octave is not a product and is not owned by anybody, I don't have any idea how that would play out in court, but since JWE has publicly stated that he is in control of the software, I wonder if he could be the primary target.  Also, anybody who contributes infringing code may be liable.  The question is who else could be liable?  Does that mean anybody who contributes is liable?  I have no idea.  It may be that anyone who redistributes octave could be liable.  Again, I don't know.

Now comes the question that really matters.  Assuming liability is decided, what is the penalty?  Referring to the same text (An Introduction to Patent Law, Mueller),

-  There have been no profits, so the standard formulas for profits don't work.

-  It could be argued that octave has hurt the sales of MATLAB in which case someone may be liable for the lost revenue, but only for the revenue lost due to infringing items.  It seems that the octave developers could be liable for the portion of the lost sales.  Again, I am just guessing.

-  Legal costs.

Except for legal costs, I don't see how any of this is a serious problem.  Most likely octave would simply end up with an injunction to cease U.S. distribution.  That alone seems pretty serious to me!


My real point in all of this is that we are trying to solve a problem without understanding the problem.  We need legal advice and we need a short term solution until we get it.

I have offered to obtain such advice, but this will take a while - I can't fork out the cash required to get a good attorney to drop what he is doing and research the problem.


So, for now, I am going to withdraw from this discussion.  I have contributed all I can.  My opinions are just that, opinions, and anything else I say is just more speculation.  This problem requires leadership and legal advice and I am not in a position to contribute much of either.


Bob
--
Robert T. Short, Ph.D.
PhaseLocked Systems



reply via email to

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