Multitouch support for Ubuntu 10.10

Of course it does. But I want to make sure everyone is fully aware of that fact and what that implies for the future of these libraries. They are doomed to be integrated as upstream framework components because of the copyright control requirements. Even if these are worthwhile pieces of technology, by keeping copyright control now via an assignment policy, Canonical is knowingly making it much more likely that a fork or re-implementation that is incompatible with their libraries will end up as the upstream implementation for application developers to depend on.

This policy of copyright assignment works against the long term interests of both the operating system developers who do their contribution beneath these libraries and to application developers who do their contribution above these libraries.... all for the sake of preserving Canonical's ability to re-license these libraries under a proprietary license at some future date. The continued insistence of Canonical as a for-profit entity to require copyright assignment will just end up marginalizing their implementation and the ecosystem will either fork it or re-implement the functionality in a codebase that does not require assignment to a for-profit entity.

-jef

The FSF guarantees that they will not hijack your code. Cannonical does not.

What happens if Oracle buys Cannonical?

FSF's copyright agreement is actually quite different.

http://ebb.org/bkuhn/blog/2010/02/01/copyright-not-all-eq...

LWN covered this at

http://lwn.net/Articles/359013/

From a risk management pov... generally speaking..assigning copyright to a not-for-profit represents lower risk of the code being re-licensed as proprietary code. Generally speaking... not-for-profits like the FSF have a mandate as part of their charter to do public good and are much less likely to be bought out by another controlling interest and change internal policy.

But more importantly, when reading any such assignment contract its vital that there be a guarantee for code access for all future versions of the code. The FSF in particular has strong guarantees in place which explicitly prohibit them from taking the code and re-license it in a proprietary manner which would later restrict access of the codebase to any and all contributors who have assigned copyright to the FSF.

This is exactly the sort of guarantee that is rarely found in the assignment contracts with for-profit entities...exactly because the for-profit entity _knows_ and _values_ the potential _profit_ to be made in a proprietary re-licensing and want to keep that option open to themselves..and only for themselves. What is thought of as enlightened self-interest to a not-for-profit with a charter to do public good can be very different than what is thought of as enlightened self-interest for a for-profit start-up desperately looking for a solid revenue stream.

The basic problem is that when any for-profit company stands itself up as a more than equal contributor and gives itself more flexibility to use the code than other contributors..its ultimately unhealthy for the software project. There is a history of this happening. Just look at Openoffice. Copyright assignment to a for-profit company actively dissuades external contributors from participating in that code development because of the less-than-equal nature of the relationship among contributors.

The one failing of the GPL is that in some ways it encourages these situations by giving for-profit-entities the ability to have their cake and eat it too via copyright assignment and dual licensing. If this library code were BSD there would be less of an issue here because such a license allows anyone to make a proprietary fork and run with it. Copyright assignment coupled with BSD code doesn't really have a downside because every contributor has equal rights to the BSD codebase (including making a proprietary product from it) even if they assign copyright to a central authority who later shutters the BSD version completely.

If the goal was wide distribution of this multitouch technology, then the libraries would be licensed with a much more liberal and business interest friendly license. But the choice of license and the requirement for copyright assignment is as much about control of the business opportunity as it is about technology innovation. History so far hasn't really all that kind to vendors who try to exert this sort of control. This multitouch stuff even if its very good technically will be marginalized and replaced with re-implementations unless Canonical lets go of its copyright assignment requirement for the convenience libraries that sit above X and below the application level. There's very little upside to controlling the copyright of the convenience library layer of technology as tightly as Canonical wants. Honestly assigning their copyright to the FSF for these libraries is actually overall a better strategy than holding the copyright themselves... if there really is concern about legal protection down the road. But in reality, these libraries may be better licensed BSD than LGPL for widest impact and uptake.

-jef