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 branden@debian.org 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,


Siward--

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!

--?BrandenRobinson


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.

--NathanaelNerode


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 libfoo.so 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 first 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, [http://sourceforge.net/projects/libedit/ libedit]). [http://mail.fsfeurope.org/pipermail/fsfe-ie/2003-October/000303.html 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 [http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation 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.

--KevinMcCarty


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: * the combination of the GPL shared library with the executable creates a derived work in memory *at runtime* -- so the user, not the distributor, needs a license to modify. * The executable is a derived work of the *header files* and other interface data for the shared library, if they are covered by copyright. If a shared library is shipped as such, it can be argued that that grants an implicit license to use the interface "as advertised", but otherwise this requires permission. * The definition of derived work is actually fairly complicated legally, involving stuff like the "abstraction-filtration-comparison" test. If the executable was fundamentally written to depend on the inner structure or quirks of the shared library, it's probably legally a derived work of the library; if it was written at 'arms length' to use a specified interface, it's presumably only a derived work of the interface.

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