[Harmony-Review] Feedback

[Scott James Remnant]

On Wed, Apr 27, 2011 at 9:01 PM, Allison Randal <allison at lohutok.net> wrote:

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


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


> 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.)
>
> Those are the least concerning things that Evil Company can do; Evil
Company can do far more to scupper the project thanks to Harmony.


> 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.
>
> Since Upstart has been developed under the previous Canonical Copyright
Assignment agreement, the only contributor is Canonical. Given our scenario
involves Canonical being purchased by Evil Company, the Evil Company would
now be a primary Contributor.

We can therefore assume Evil Company won't deal; and thus the majority of
the code is stuck under the old license.

And this the same scenario with or without Harmony.


> 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.
>
> I don't agree it says that at all. If that's what it's supposed to say
(it's one of Harmony's more impenetrable clauses) then it needs rewording.


> >     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.
>
> An incredibly wide and crazy license.


> 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.
>
> I disagree, I think Harmony is actually constructing a potential bomb by
licensing all of the rights into one basket that is much easier for a patent
troll to acquire.


> 99.99...% of contributors to FLOSS projects don't own patents, so the
> patent license doesn't apply to them.


Really? Because last time I looked the majority of contributions to FLOSS
projects were corporations like Google, Red Hat, IBM, etc. Lots of patents
owned by them.


> 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.
>
> So why doesn't Harmony do this? This was the crux of my patent argument -
the holder gets all the rights, and doesn't reciprocate. If it actually
licensed them back, the problem would go away.


> 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).
>
> Canonical is owned by a single person who can get bored, hit by a bus or
tempted by a very large offer. Today's Canonical is not tomorrow's
Canonical.


> 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).
>
> What patent license? There is no such text in Harmony.


> >     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.
>
> Which is why I suggested Apache 2.0 to Matt two weeks ago.

GPLv3 is not an option due to Upstart's heavy use in the embedded and mobile
sectors.

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.harmonyagreements.org/pipermail/harmony-review/attachments/20110427/91898301/attachment-0001.html>