Richard Stallman: Entrepreneur of Freedom

In the run-up to the release of GPL3, Eben Moglen of the Free Software Foundation sought to calm anyone concerned by noting that the changes would be very small – so small, in fact, that everyone would wonder why there was any cause for alarm about the terms of GPL3. Well, the initial draft of GPL3 has now been released to the world and presented to a large community meeting in Cambridge, Mass. (You can also see a document discussing the FSF’s rationale for the license.)

Taken altogether, it’s not clear that GPL3 is a minor extension of GPL2. Perhaps a better way to characterize it would be to say that GPL3 reflects GPL2 concepts, but updated for today’s technology environment of software patents, downloadable content, and global Internet access. GPL3 is consistent with the longstanding principles of the FSF; however, some of its requirements may be difficult to accept for organizations interested in using GPL3-licensed code.

What then, are the areas in which GPL3 extends the existing GPL2 license?

Digital Rights Management (Section 2.4 3)

One area the license addresses is DRM – usually understood as Digital Rights Management, but referred to in GPL3 as Digital Restrictions Management. In Section 3, the license essentially states that no GPL3-covered work can illegally invade users’ privacy or deny them the full exercise of GPL3 rights. However, it goes on in the next paragraph to say that “distribution of a covered work as part of a system to generate or access certain data constitutes general permission at least for development, distribution and use, under this License, of other software capable of accessing the same data.”

Considered in light of DRM, this seems to say that you can’t lock up content using GPL3-licensed software. In other words, if you use GPL3 software to protect content via a DRM system, you must also allow people to access that data without use of a DRM system. This would seem to have the effect of forfeiting use of GPL3 software in DRM systems, since no one is going to construct a DRM system that must also allow unfettered access to the protected content.

In reading the language plainly, though, the section seems to be quite broad about denying the use of GPL-licensed software in any scheme to control access to data – for example, this section could be read as meaning that GPL-licensed software cannot be used in a password authorization mechanism. It may be the FSF does not intend for this section to apply so broadly – but, as it stands, this section would preclude most organizations from using GPL3 software in any security scheme due to its requirement for alternative data access mechanisms. I expect this section to generate a lot of discussion and controversy, once its implications are considered. It definitely needs to be drawn more carefully, assuming the FSF’s intention is related to DRM for copyrighted works rather than general data access.

Software Patents (Section 2.4 11)

Another area the license addresses is patents; specifically the right to use GPL3 software if the user holds applicable patents. In the rationale document, the FSF notes that it has taken a relatively restricted approach to this, in that the license requires that a patent holder must license the use of a patent applicable to the work in question on a nonexclusive, royalty-free, and worldwide basis, or else forfeit the use of the licensed software. GPL3 does not attempt, as some licenses do, to cause the user to forfeit use of the software should it attempt to enforce a patent claim of any type against other users of the software. As the FSF observed, the leverage a license holds against a user regarding other actions is, in real world terms, very limited – so why bother to try? Far better to impose conditions that can be enforced than attempt to impose a world view without the ability to enforce it.

License Compatibility (Section 2.8 7)

A third area GPL3 addresses is license compatibility: the capability to marry other open source-licensed software with GPL software. This is a true pain for real-world users, who want to create works that use the best available software, no matter what type of open source/free license its components carry.

The requirements of GPL3 in this respect may be summed up as: you can add license requirements to the fundamental GPL3 requirements, but GPL3 is the foundation. So if a license requires trademark display, it’s OK for the overall product to require that, but if the license allows distribution without reciprocity (e.g., the Apache license), that is forbidden.

The license compatibility of GPL3 is a very positive step. It offers users the ability to mix-and-match software components to suit their needs while still adhering to the vision of the Free Software Foundation.

The Sting in the Tail: User Access to Source Code

As to the stickiest area of the draft license, it’s buried in Section 7 (License Compatibility). Within this section, there is a paragraph that states:

Aside from additional permissions, your terms may add limited kinds of additional requirements on your added parts, as follow:

1. They may require that the work contain functioning facilities that allow users to immediately obtain copies of its Complete Corresponding Source Code.

I initially read this as stating that if someone merges some other-licensed open source code (e.g., Mozilla-licensed code), the person merging the code could add this requirement. Not particularly controversial.

However, in discussions with Karen Copenhaver of Black Duck Software, she shared with me that during the meeting at Cambridge, Richard Stallman (founder of the FSF and author of the license) said that he would recommend that this paragraph be attached, as a matter of course, to GPL3-licensed software. In other words, this paragraph, rather than being an occasional (or even rare) presence in a merged product, would become a common feature of all GPL-licensed software. If this is true, it’s likely to be a major controversy regarding GPL3.

First, there is the practical difficulty of making source code immediately available. Does that mean every organization using GPL3 software must set up a code repository and somehow make it available via its system? That would be challenge enough.

More troubling, the paragraph is ambiguous as to the definition of user (in fact, user is nowhere defined in the license). Does it mean that an end user accessing a system via a browser residing on their home machine must have immediate access to a GPL3 derivative work running within a company’s data center?

What could this look like in the real world? To take a hypothetical example, suppose a large banke has used GPL3 code within a proprietary credit scoring application. This paragraph would require it to hand that code out – immediately — to its customers, employees, competitors, and anyone else that exercises the code through a remote user interface. In other words, this paragraph would impose complete transparency of any part of an organization’s software infrastructure that contains GPL-licensed code and is somehow accessible to an outside user. According to Karen, the code availability requirement would also include code accessed via service-oriented architecture mechanisms as well as end-user interfaces.

While this condition is quite consistent with the FSF’s perspective on software creation and use, it’s likely to be a killer for organizations. No organization is going to use software that imposes the practical challenge of becoming a software distributor; much more threatening is the requirement for distribution of all software incorporating GPL3 code. (As an aside, the license is also tightened up regarding the definition of source code to include dynamically linked code; that is to say, code that integrates with an executing program at runtime).

As I stated at the beginning of this post, this is a draft of GPL3. So, what will happen between now and when the license is finalized? In my next blog posting, I’ll discuss what happens next, and, crucially, how you can get involved in the comment process. I plan to discuss in a future post (near future, I promise) my thoughts on how you can respond to the potential changes in GPL3 in a way that enables you to continue using GPL3-licensed code without sharing any company secrets.

–Bernard Golden