IPcentral Weblog: Delusions of Grandeur: GPLv3 Is A License That Thinks It‘s a Regulation

I'm concerned about the ambiguities, too.

To set the context, I'll note that I'm a lawyer who represents a lot of software companies, some of whom have open-sourced their products, others who incorporate open source into their products, and, yes, some proprietary companies.

For all its merits, GPLv2 was less than clear in certain aspects. I've spent a lot of time, for instance, helping clients understand whether something is a derivative work or "a work based on the Program." But over the years, we all got a level of comfort with the document. There were disagreements on the edges, sure, but there was a general consensus about how the GPLv2 worked.

The object of revising GPLv2 was ostensibly to improve and clarify it. With respect, this latest draft of GPLv3 is hardly clear; to the contrary, there's a lot more ambiguity. For instance:

-it's hard to tell what position the draft takes with regard to embedded code and DRM.

-the automatic licensing of downstream recipients in Section 10 isn't very clear. What rights are conveyed, and to whom?

-the draft uses a lot of different language to refer to patent licenses. In Section 11, para 1, for instance, says "each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims in the contribution, to make use, sell, offer for sale, import, and otherwise run, modify, and propagate the contribution." Section 10 says "each time you convey a covered work, the receipient automatically receives a license from the original licensors to run, modify and propagate that work." Section 11, para 3 requires a party relying on a patent license to cause source code "to be so available." Are these licenses supposed to be all the same? Or are there differences?

-Section 11, para 2 defines "patent license" for the following paragraphs. The definition would seem to include the broad patent pools or licenses that are common in the industry or related to defined standards. If so, it would make it hard for GPLv3 code to include popular standardized technologies that are covered by patents.

I've heard Eben Moglen speak on several occasions, and he's acknowledged that he's intentionally included ambiguous terms in the license. While those ambiguities may give Moglen and the FSF flexibility to interpret and enforce the license, it creates real problems for software developers that genuinely want to try to understand and apply it. In fact, the point of a written license is to provide the parties with some clarity about what they can and can't do. Deliberate ambiguity undermines this goal -- and it creates a real risk that a court will apply the well-established legal rule that it should construe the ambiguous terms against the person who drafted it.

In sum, then, I'm concerned that the efforts to tailor the GPLv3 to target the Microsoft/Novell deal have created a lot of uncertainties that will dissuade commercial open source developers from adopting it.