Re: overloaded function handles

[Jaroslav Hajek]

On Sat, Aug 1, 2009 at 5:42 AM, Robert T.
Short<address@hidden> wrote:
> 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.

That may make the difference. I pull almost every day (except the
weekend). I also have multiple repos to build from on different
machines.

> 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.
>

A slight correction: The present situation is that we know that the
technique in question is almost surely covered by the patent.
According to wikipedia,
"a patent is a right to exclude others from making, using, selling,
offering for sale, exporting components to be assembled into an
infringing device outside the U.S., importing the product of a
patented process practiced outside the U.S., inducing others to
infringe, offering a product specially adapted for practice of the
patent"
This seems to imply that MathWorks can eventually prohibit usage of
Octave in the US, hosting the Octave archive in the US, or
contributing to Octave by US citizens.

>
> 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.
>

Yeah, probably not (given that it would be technically difficult).
Still; they might make an unofficial disclaimer that they don't intend
to collect royalties from Octave users, or from non-commercial usage
only.

>
> 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.
>

True; however, I think it is apparent that here the patent was fairly
obvious to a person ordinarily skilled in the art (me) and the only
actually useful idea that I got from MathWorks is not even part of the
patent.

>
> 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!).
>

Interesting.

>
> 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.
>

That sounds serious. But I wonder what "in control" means here and
where did JWE claim it.

>
> 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.

Depends. I have profit from using Octave (or my employer has).

> -  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.
>

Oh god. Another ridiculous calculation of lost profits, no doubt.

> -  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.
>

OK, that's nice of you.

>
> 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.
>

OK, no problem. I just wanted to avoid some user from USA getting into
trouble due to my contribution. Now that I saw the claims, I have no
idea how to implement the feature without violating the patent.
(Mathematically speaking, even the previous implementation seems to be
covered by the claims).

Indeed, if nobody brought up the patent issue, I would be just happy I
improved Octave a bit further, as usual :)

cheers

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz