This page is an area where Debian developers and users can leave comments so that ?BrandenRobinson, DonArmstrong and BenjaminMakoHill can better represent the desires and hopes of the Project when they attend the GPL v3 Launch conference at MIT in Boston, Massachusetts on 16 and 17 January 2006.

Branden suggests drafting comments to answer questions along the following lines:

Do not feel compelled to comment on areas that don't interest you.

Please do not edit other users' comments except as they request (e.g., for spelling corrections and improved grammar).

Branden recommends placing comments between two horizontal rules. Please sign your contributions; anonymous comments are not possible on this Wiki, as it is only editable by registered users. If you would like to comment but want your identity to be held in confidence, please send private mail to with the subject GPLv3 launch comment. Feel free to GPG-sign and/or -encrypt such mails.

Branden is monolingual in English, so comments left in other languages will have to be translated for him to understand them.

This is an example comment.

-- ?BrandenRobinson

At various points, people have wanted to base distributions on top of GPL-incompatible but still free (or arguably free) system components. GPLv2 makes this difficult, but it's not obvious that preventing this provides any benefits to the recipients of software. It would be advantageous to suggest that this situation be examined in GPLv3.

-- ?MatthewGarrett

Comment of siward :

Sorry about the formatting ; this is the first time i edit a wikipage. ALL OF THIS IS 'in my (not very well-informed) opinion'. My comments apply sometimes to GPL as a licence,

* What are the current GPL's strengths?

* What are the current GPL's deficiencies?

* Are there significant threats to software freedom that the current GPL does not address?

* Are there significant threats to software freedom that the current GPL does address ?

* Should a new GPL attempt to explicitly broaden its applicability

* What parts of the GPL are difficult to understand?

* If you have copyright in a GPL-licensed work,

:-) dict adjudictate to try and determine, as a court

* What part of the current GPL would you most like to see preserved as-is?

* What part of the current GPL would you most like to see changed?

* Is the time ripe for revising the GPL ?

* On balance, has the GPL been a benefit or a detriment to the Debian Project ?

*** Which improvements would you like to see in the new GPL ?

*** Which things do you think the FSF would like to change about Debian,


A couple of comments:

Thanks again for your comments. Your final suggestion is particularly noteworthy; in fact, as I recall, we have invited RMS to DebConf in the past (DC3 in Oslo at the very least), but he has declined. Still, we should keep trying!


Oh! ?ObLicense: This comment is free software. Anyone may use (, copy, modify, distribute, etc.) this comment under the terms of the GNU General Public License, version 2.


I would like to see the controversy about linking with shared libraries addressed somehow. On the one hand, there is no difference (from the point of view of the end user) between static and dynamic linking: if exists in /usr/lib, she ends up with a program dynamically linked against libfoo; otherwise if libfoo.a exists in /usr/lib, she ends up with a statically linked program, using exactly the same compiler command. But in the static case, parts of the library end up in the executable, so it is clear that the combined work program+library must be under GPL when either of the components is.

In the second case, the executable only contains references to the shared library (which is a separate file). Hence it has been argued that dynamic linking of a non-GPL executable to a GPL shared library is OK, especially as it is feasible to write a binary-compatible shared library that may swap out the GPL library (witness the BSD-licensed readline replacement, [ libedit]). [ Example argument from this viewpoint.] However, this argument would essentially reduce the GPL to the LGPL since if it was valid, anyone could scavenge desired GPLed code out of a project, compile it as a shared library, and link their own proprietary code against the library.

The official position of the FSF seems to be that dynamic linking is not just "mere aggregation"; see [ this], for instance. But this position has not, as far as I know, been tested in court. Nor is it clear that the GPL could be written in such a way as to enforce this interpretation without becoming a contract rather than a license.

I'm not sure exactly what could be done here, but it would be nice to see the situation at least clarified.


This is a little off-topic, but regarding dynamic linking I believe the view which makes the most sense under copyright law is as follows:

Perhaps the best rule would be that proprietary programs can link against GPLed shared libraries if they program strictly to specs (for instance, linking against glibc, but programming strictly to POSIX), but they can link against LGPL shared libraries even if they peer into the innards.

It's worth noting that as it is, anyone can scavenge desired GPLed code out of a project, compile it as a program with a command-line interface, and have their proprietary code execute that program as needed. The FSF has always said that that doesn't create a derived work, though I think in some situtations it probably does (think of relying on undocumented options or behavior). Practically there should be no difference between this and the shared library situation, and I don't think any court would ever find a difference between the two, so it would be good for the FSF to get their act together and come up with a legally plausible view.

--Nathanael Nerode


The GPL's core strength is that it allows businesses to contribute open source code without worrying about that code ending up in competitors' propietary software. It helps solve the problem of subsidizing the competition.

The key defficiencies include an unwillingness on the part of the FSF to provide linking exceptions to other Free software licenses and a reliance on local laws without providing any guidance over jurisdiction (hence the GPL may mean fundamentally different things in different places).

The GPL v2 was far easier to understand than the GPL v3. With effort, I find both licenses are generally comprehensible but leave difficult questions based on vague legal standards such as "work as a whole" and "derivative work" without any guidance in the license as to where these lines should be drawn. However, I have the following questions:

Does the GPL v3 implicitly discriminate against fields of endeavor such as wireless cards' firmware, DRM, etc? If so, is it really a Free software license by Debian's standars?

The key difficulties in adjudicating issues based on the GPL involve borderline questions where the answers are likely jurisdiction-dependant. Here are a few questions (should be applicable to both versions 2 and 3):

Suppose I create an add-in for a GPL'd application which allows it to dynamically link to a class of third-party proprietary libraries coded to a specific standard (for example ndiswrapper and the GPL v2), does this violate the terms of the license under either derivation or work as a whole definitions?

If I create a LGPL'd bridge for a pre-existing proprietary solution built for another environment (i.e. not derivative), if this is distributed separately such that it links to a GPL'd program, does that violate the terms of the license?

If I distribute a CDROM which includes a GPL'd work *and* third party plug-ins normally distributed separately which meet the above criteria, have *I* violated the GPL even though the developers of the software have not?

I think the outline of the GPL is good. I would like to see the following limited changes:

1) Some clause for determining jurisdiction so that one does not need to hire international IP lawuers for interpretation of the license. In the alternative, clear definitions *in the license* of derivative work and work as a whole would be appreciated.

2) Linking exceptions to other free software licenses.

3) An abandonment of the Affaro GPL as a licensing option as I do not believe that this is compatible with the FSF's stated principles, the DFSG, or the OSI's OSD. (the AGPL is either entirely ineffective in that application proxies could be used to prevent source code dissemination or it restricts the right to use the software in such environments by mandating configurations on other network devices consistant with the intent of the licnese. In the former case, it is ineffective but limiting to developers, and in the latter case, it imposes broad usage requirements acting as a traditional EULA.)

-- Chris Travers