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

Re: Patent clauses in licenses



Matthew Garrett wrote:

> Recently, we've begun seeing more licenses that are designed to
> discourage patent lawsuits. They usually involve something along the
> lines of "If you engage in patent action against the licensor, bad
> things will happen".
> 
> "Patent action against the licensor" usually takes one of two forms. The
> first is "Any patent action against the licensor", with the second being
> "Any patent action against the licensor connected to the licensed work".
> An example of the first is the RPSL[1]. Any patent action against the
> licensor terminates your copyright license, even if you're alleging
> infringement in an entirely separate area. The MPL[2] is an example of
> the second. Here, patent action only results in termination of the
> copyright license if the action alleges infringement in the copyrighted
> work.

This is the distinction I care about.  The Apache License 2.0 was redrafted
based on commentary from myself and other debian-legal members specifically
to make sure it only addresses allegations of infringement in the specific
licensed work.

The broad version is just excessively, dangerously broad.  Suppose IBM
issues some program under the RPSL.  If you have a valid and legitimate
patent on a chip manfacturing process, and IBM is violating it, and you sue
them, you may lose your license.  

(Restricting action to "patents applicable to software" is not nearly
sufficient to deal with this.  It could be argued that my chip
manufacturing process patent is, in some tangential and unimportant way,
"applicable" to software under US law.  "Applicable to software" is a
lawyerbomb.)

Restricting action to patent lawsuits alleging that a work of software
(possibly a different one) infringes the patent is a better and less
offensive restriction.  If you believe that patenting software algorithms
is never valid, then this seems fine.  If you believe that occcasionally it
is valid, this isn't fine.

--
But in any case, the narrower version is *very* defensible on free-software
grounds.  If someone (call them "SCO") alleged that work X, by person Y,
infringes their patent -- and succeeded in court -- and work X is under a
license which doesn't have a narrow-style patent retaliation clause -- then
only "SCO" and those to whom "SCO" issues (perhaps costly) patent licenses
to can use work X, contrary to the intent of person Y.  In other words,
"SCO" would have actually succeeded at stealing work X and taking it
proprietary without even asking the author.  Person Y would almost
certainly be happier if *nobody* was allowed to use X.

With a narrow retaliation clause, "SCO" would lose its license and this
particularly nasty scenario would be rendered unlikely if not impossible.

The narrow version satisfies the goal of eliminating this sort of scenario
without doing any "collateral damage".  The broad versions do additional
things, and seem to be more designed to discourage patent lawsuits in
general than to protect the freedoms regarding the licensed work in
particular.

Narrow clauses protecting the freedoms regarding the licensed work are the
type of restriction which is most legitimate in a free software license. 
Accordingly, I think the narrow (this-work-only) clauses are free and
should be encouraged, but the broad clauses are not free and should be
discouraged.

> "Bad things" can also take one of two forms. The first is "Termination
> of copyright license", which is the result of the two examples listed
> above. The second is "Termination of patent license", which also appears
> in the MPL[3]. In the first case, you lose all rights to do anything
> with the software. In the second case, you only lose the right to make
> use of the patents - you are still permitted to use the software, though
> doing so may result in you being open to patent infringement suits
> yourself.
> 
> The motive behind these licenses is, in many cases, simply to discourage
> software patent lawsuits. This is probably an entirely reasonable aim.
> However, it's a situation that didn't really exist at the point where
> the DFSG were written. As a result, it's difficult to gain any real idea
> as to whether Debian should consider these free or not. Of course, it's
> also possible to come to the conclusion that certain classes of these
> clauses are free and some aren't - there's an obvious degree of
> difference between termination of copyright license and termination of
> patent license, and also between termination on all patent suits or
> termination on relevant patent suits.
> 
> As a non-strictly related point, both the FSF and the OSI appear to
> consider clauses of this nature free. The lack of any real consensus
> on this topic within Debian makes it difficult to negotiate with license
> authors. If we disagree with the FSF, we probably need to make it clear
> precisely why we hold this opinion, and then set about trying to change
> other people's minds.

I believe the broad clauses are non-free (and I have convinced many other
people) based quite specifically on what I mentioned above.

I also suspect that the FSF and the OSI either
(a) simply have not noticed the dangerous potential of the overly-broad
clauses,
or (b) mistakenly think "applicable to software" is a sufficient limitation
If I am correct, there should be a lot of room to convince them of my view.

I believe that Debian should consider the "narrow" clauses free (they only
impact people explicitly trying to make the work non-free) and the "broad"
clauses non-free (they hit random inventors).

(It may be possible to design a "broad" clause which really specifically
singles out software patents, although I have never seen one.  I think that
that would still be non-free, but Debian will have to make up its own mind;
there are arguments both ways, amounting essentially to the question of
whether there is *ever* a legitimate software patent.  I think there is
really no doubt that broad clauses of the sort currently used are
non-free.)

-- 
This space intentionally left blank.



Reply to: