Stuff Michael Meeks is doing

Seeing Mark's blog over the weekend promoting corporate ownership aggregation reminded me of an overdue response to Project Harmony. Mark writes compellingly, as normal, I'm just not so convinced about the moral excellence of generosity, without sensible safeguards, towards profit chasing corporations. But anyhow, Project Harmony:

Having initially been involved with the project, I'm rather disappointed by its output. There are many applications of Harmony that are problematic legally, pragmatically, ethically and from a software freedom perspective. I've written about the practise of to-corporate Copyright Assignment though that title would better be expanded to certain licenses, such as Harmony's, which are tantamount to (C) assignment enabling an unhelpful corporate ownership aggregation. Others writing in detail on this are Bradley Kuhn, Richard Fontana, Dave Neary and Simon Phipps.

My two cents is that, best practise is the Free Software norm, where the inbound contributor agreement (CA) is identical to the outbound license. There is some extent to which Harmony does improve things - it is rather like a hypothetical ISO standard for weapons sales. Such a standard, with clear escrow provisions perhaps, might help accelerate arms sales, making them cheaper, and perhaps may have a legitimate use: helping some defend themselves and others under threat. The only slight down-side being the scope for littering the world with yet more unwanted land-mines. In the same way I fear that Harmony has the potential to make acceptable the corporate control Free Software projects, bringing many complications. There are many rather good reasons not to sign a CLA, often focued on the horrible imbalance of power that they create. Here is one such specimen reason focused on the corporate sphere:

Why Harmony's CLA can be dangerous

Broken options - the one way street

Consider a BSD licensed Harmony option. The BSD license gives no out-bound patent rights to the software, so it is easy to end up with code that requires a separate patent license to effectively use it. Now - consider that you have assigned your patent rights under a Harmony CLA to FooCorp, you assign:

"For patent claims ... which You own, control or have the right to grant, now or in the future, You grant to Us [FooCorp] a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable patent license with the right to sublicense these rights to ..."

By signing this - you have comprehensively given away your patent rights, to the code you contributed to FooCorp, but interestingly, you get no license granted back, either by the outbound BSD license or by the Harmony agreement. That is deeply generous but highly broken. It is thus easy to create a situation, where only FooCorp, and its for-fee licensees can use the project's code.

No self defence provisions

Another problematic down-side follows from this. If there is any ethical justification for acquiring patents it is self defence (from the madness of the real world). More sane non-copy-left outbound licenses have reciprocity clauses to enable self defense against patent aggression. Lets look at Apache's:

3. ... each Contributor hereby grants to You a perpetual, worldwide ... irrevocable (except as stated in this section) patent license ... If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) ... then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

Which means - if MegaCorp sues me for patent infringement, while they are using my own patented code: I get to use that patent to defend myself. So how does that jive with the Harmony CLA ? Sadly, none of that nice termination logic is there - you just gave away your current and future patent rights completely. Pathologically in the previous (BSD outbound) case; quite feasibly FooCorp can immediately threaten you for patent infringement on their work. Add some simple corporate mechanics such as making FooCorp a shell company, even with an Apache licensed project FooCorp's parent can sue you for using their code.

Third parties get to tread on you

That situation can be seen in a different way. Say you are defending yourselves in some patent war cf. the mobile space. Perhaps your major defensive tool is a patent covered by code you've included into FooCorp's product. Unfortunately, whatever the outbound license used (perhaps it has a sensible termination provision) the patent license comes, not from you, but from FooCorp. Of course perhaps you only discover when it comes to defending yourself that FooCorp already sold your code + patent rights to MegaCorp under a confidential proprietary license some years back; better hope you keep them sweet by not competing with them.

A FUD factory - who knows what you're missing ?

Thus FooCorp is sitting pretty, on its pile of aggregated patent and copy rights, and has a great marketing tool to sell their proprietary licenses to other companies: "better safe than sorry" - "who knows what key rights you might be missing; we don't ?" - "sign here for safety". Similarly other (big) companies are incentivised to only appear to work inside the community, limiting their exposure by taking bespoke, non-reciprocal, proprietary licenses. That can make project contributors feel safe - "MegaCorp is distributing OpenBaa under the LGPL too right ?" when in fact they have a neat way of avoiding giving you key rights, via paying FooCorp.

I initially tried to encourage the Harmony project to address this sort of issue, but without success.

The net effect - more complexity on top of the license

One of the aims of Project Harmony is to make review easier for lawyers, yet it conceals this non-reciprocal loose your job minefield. By parameterising 'license', and including the scope for future license change it provides a very clear definition of the rights you surrender now and in the future, and a very vague aspiration to the rights you get back. Thus, you cannot read the Harmony CLA without also paying very careful attention to its interaction with the selected outbound license as well. So - I am fairly convinced that large companies will not be signing such an 'Entity agreement'. If they need to contribute there are plenty of ways to look like they are doing that, eg. via a shell entity, or by letting employees contribute as individuals.

Where is a CLA useful ?

Some projects are not blessed with a copy-left license. That means that every time they see a patch floating across their mailing list, the ownership of it can be less than clear; after all, it is fine to claim that your changes to a non-copy-left code-base are proprietary, even after you happened to publish them. Some explicit statement can help in this case to clarify that you are indeed contributing this code in good faith - paperwork can do that. Also many non-copy-left licenses have no "or later version" upgradeability in them via a license steward (the FSF provides that for the GPL). An example of that is the Apache license. In that context some CLAs make some sense.

Of course, it probably makes more sense, to have a copy-left license, with a clear license steward. That makes it clear that distributed changes are licensed under the project license, and can be easily merged as/when they are published. This is the beautiful inbound equals outbound symmetry that underpins most Free Software projects.

A quick reflection on the barrier to entry to non-copy-left projects with sign-and-fax-in assignment/license documents makes you wonder how they have survived. Perhaps the un-written social contract around respecting a project's license and not soft forking it without good reason has protected them thus far from being hollowed out by more fun, free-wheeling, copy-left variants. It seems that that unwritten contract is under quite some strain these days; who knows what the future holds there.

Conclusion

I hope that examining just one weakness in some detail highlights that, while Harmony may have some uses, in general a much better approach is to use a uniform copy-left license that gives the same rights and protections to all. That also reduces the scope for corporate malfeasance that will ultimately betray your generosity.