[Harmony-Review] Feedback

[Allison Randal]

On 04/27/2011 04:21 PM, Scott James Remnant wrote:
> 
> To be honest, I found the entire thing quite difficult to read. In
> particular a continual need to keep referring from the text back to the
> glossary at the top was just mind-bending.

Thanks, we'll work on it.

When definitions are done well (and defined terms are chosen well), they
actually make an agreement more readable. I've been nicknamed the
"definition killer" in Harmony, I've whacked and trimmed so many of
them, but I still think we have too many and the ones we have are too
complex. :)

>     >     * the right to sub-license the Contribution is granted from
>     >       Contributor to Canonical, but no reciprocal right is granted for
>     >       the Work as a whole back to the Contributor (ie. the right to
>     >       sub-license is exclusive to Canonical)
> 
>     [...] Now, if the project also
>     granted all rights in the entire work to all contributors, that would
>     mean that any contributor (even if they only contributed one line) could
>     arbitrarily decide on their own to release the entire work under a BSD,
>     commercial, or proprietary license, completely undermining the copyleft
>     goals of the developers. [...]
> 
> The case being considered here is Upstart, with Canonical as the
> copyright holder asking for Option Five.
> 
> This leaves Upstart open to the problem of *Canonical* being acquired by
> an entity without the best interests of the project in mind. And due to
> the agreement, none of the other contributors being able to do anything
> about it.

Okay, let's flesh out that scenario. (With the usual disclaimer that I
don't work for Canonical's legal department, and don't represent
Canonical in Harmony, so this is personal perspective.)

Let's say Canonical adopts a Harmony contributor agreement, either
copyright license or copyright assignment, and chooses Option Five. They
accept contributions to Upstart under the Harmony agreement, and release
Upstart under GPLv2. They go on doing this for a long time, and a
sizable body of code is collected from a wide variety of contributors
(it's a thriving success). Either the contributors own the code and
Canonical has a broadly open license to it (license), or Canonical owns
the code and the contributors have a broadly open license to it
(assignment).

Evil Company takes control of Canonical, and sets on a path that's
harmful to Upstart. There are any number of ways Evil Company could do
this, from pursuing development the existing contributors consider a bad
technical direction for the project, to embarking on business models the
existing contributors find morally objectionable, to entirely refusing
to update or distribute Upstart. (See Mambo and Joomla! for an example.)

What can the contributors do? The first bit: Under either license or
assignment, the contributors have the right to take their contributions
and establish a new project (call it Startup) under any license they
choose. If the contributors are unified in this action, they're going to
carry a large body of the code away, possibly even all of it. If the
contributors disagree on whether to leave the old project, then Startup
will have control over a smaller body of code. I find it appealing that
each contributor casts their vote on what to do, using the code that
they wrote. That code is their stake in the project.

The second bit: For the rest of the code in Upstart, the parts that
weren't developed by the contributors forming Startup, they still have
the full body of Upstart code from the most recent release (version
42.0) under GPLv2. Evil Company can't take that back. Once 42.0 is
released as GPLv2, it's always available as GPLv2. And, what's more,
because of Option Five's reciprocity, the Startup developers have access
to the full body of any contributions checked into Upstart after release
42.0, also under GPLv2.

The third bit: Evil Company can't escape the reciprocity, because the
Harmony agreements guarantee (section 6.2) that Canonical can't give
Evil Company the rights they got from the Harmony agreements unless Evil
Company agrees in writing to respect all the terms of the Harmony agreement.

>     The scenario I think you're describing is that Bar holds a patent B,
>     Alex writes code that uses patent B, and then contributes that code to
>     project Bar. Without a patent license from Bar to Alex, Bar isn't
>     infringing on their own patent because they hold it, and Alex isn't
>     infringing on Bar's patent because the code is distributed by Bar. So,
>     no patent license needed for that "usual" case.
> 
> Except when taken into account that Bar is owned by Canonical, and
> Canonical is acquired by Evil an (NP entity/patent troll).
> 
> Now all patents A or B are owned by Evil, and Alex doesn't have a patent
> license to continue development in the newly forked project to keep Bar
> open and free.
>  
> 
>     But personally, as far as I understand it, I'd say this is every bit as
>     dangerous as the joint ownership scenario above. It would leave projects
>     open to "submarine contributions", where someone tries to get seemingly
>     innocuous patches accepted so they can gain access to the project's
>     patents, or more likely to the patents of other contributors.
> 
> The inverse leaves just as dangerous scenario - Evil using the harmony
> agreement to acquire patents by soliciting contributions.

No one acquires a patent through contributions, all they acquire is a
license to a patent.

The fundamental problem is that software patents are a really, really,
really bad idea. When Harmony and other FLOSS contributor agreements and
licenses handle patents, we're not fooling ourselves into thinking that
we can fix software patents this way. All we're doing is partially
defusing the bomb, creating an ecosystem where, as much as possible,
contributors, projects, and users can work without fear of software patents.

99.99...% of contributors to FLOSS projects don't own patents, so the
patent license doesn't apply to them. For the small fraction of
contributors (mostly corporate) who do own patents, the "best practice"
that's grown in FLOSS is to take patent licenses from contributors for
anything infringed by their contributions. That's enough to protect the
project (and the users) from evil companies slipping in code covered by
their own patents, then turning around and attacking the project, or
more likely attacking some big, wealthy company that uses the project.

Curiously, this kind of defusing behavior is exactly how patents are
mostly used in the rest of the world. "I'll license you my patents if
you license me your patents, and then we'll both be accountable to the
other and won't be able to attack." It isn't perfect, but it's the best
approach so far to a broken system.



In the specific case of Upstart and Canonical, you have one advantage in
the fact that Canonical is completely against software patents, as
evidenced by their lobbying to the European Patent Office, and in
multiple public statements by the founder (e.g.
http://www.markshuttleworth.com/archives/118).

In the case of an Evil Company patent troll, who holds a number of
patents relevant to Upstart, the first question is "How did they get
those patents?" If the Upstart code existed before the patent, that's
prior art, and the patent can be invalidated.

If the patent existed before Upstart, then you're in trouble. Evil
Company may have nothing to do with Canonical, and you're still in
trouble if they decide to make a mess of things. Just rip that code out
of Upstart (or the fork Startup), it's far less painful than the
alternative. Patents are by nature narrowly defined, so you're looking
at rewriting one algorithm, process, or feature to avoid the patent, not
losing the entire codebase.

Oddly, you're slightly better off on this point if Evil Company does buy
Canonical, because then any patents Evil Company holds that are
infringed by Upstart, are covered by the Harmony patent license. Evil
Company's patent claims against Upstart are weakened or destroyed once
they're a party to the Harmony agreement (that's one of the relevant
purposes of the patent license).

>     The contributor does get a patent license to the whole work, though, the
>     same patent license as all users through the outbound license. It varies
>     by choice of outbound license (and so is something that every project
>     needs to think through, whether they're using a Harmony agreement or
>     not), but FLOSS outbound licenses that address patents do so in a way
>     that grants a patent license sufficient to use, modify and redistribute
>     the work, but not sufficient to cover any arbitrary reuse of any
>     arbitrarily tiny contribution. That is to say, the outbound licenses
>     have been carefully thought through, and the patent licenses they
>     include are safe.
> 
> Upstart is GPLv2, there is no outbound patent license included in that
> copyright license.
> 
> An alternate option I proposed was changing the outbound license of
> Upstart, I understand that is being considered by Canonical.

Sounds like a reasonable idea. One advantage of GPLv3 is clearer patent
protection than GPLv2. The FSF, SFLC, and RMS took the position during
the GPLv3 process that GPLv2 had an implicit patent license (search for
"implicit patent license" in http://gplv3.fsf.org/rms-why.html), you can
decide for yourself whether you agree with that. Apache 2.0 is another
option with clear patent protection.

Allison