Differences between revisions 26 and 28 (spanning 2 versions)
Revision 26 as of 2006-07-07 03:43:57
Size: 25453
Editor: DonArmstrong
Comment:
Revision 28 as of 2006-07-11 00:53:09
Size: 25453
Editor: DonArmstrong
Comment:
No differences found!

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:

  • 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?
  • Should a new GPL attempt to explicitly broaden its applicability to works other than computer programs (e.g., image, sound, or music files; documentation; dictionaries; encyclopedias)?
  • What parts of the GPL are difficult to understand?
  • If you have copyright in a GPL-licensed work, what area(s) of the GPL do you find difficult to adjudicate?
  • 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?

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,

  • sometimes to GPL as a standard. and sometimes to GPL as a set of moral norms.

* What are the current GPL's strengths?

  • + It seems to do the job. + The spirit of it is well considered, and more info about it is easily findable.

* What are the current GPL's deficiencies?

  • + It is not very thoroughly phrased
    • in 'on a medium', i think it hardwires implementation. and 'machine-readable copy' ; the machine might even be proprietary. and 'customarily used for software interchange' ; what if you invented a brand new medium ? 'sourcecode means preferred format for modifying' ; so obliged to ship entire cvs. '...components of THE operating system on which the software runs' ; argh. etc.
    + It is written in pidgin-legalese, without translation.
    • This is not the same language the authors use in daily life,
      • consequently they don't have full command over it, and it shows.
      Adding a number of annotations at each article,
      • not legally binding, saying same in plain english would make the information much more accessible ;
      Currently it tries to comment on the terms and conditions in the terms and conditions ;
      • A clear separation of which would enable use of plain english.
      so:
      • Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
      or:
      • Dear reader ; we don't want to take away your rights,
        • we just wanna insure the freedom of copylefted works, okay ?
        So that's why your entire work comes under the GPL
        • if you quote even the tiniest part of a GPL'ed work.
      I think it would make the GPL much more understandable.
      • (and revisable).
    + It does not give all users the rights that all american citizens have on this software.
    • Wouldn't cost them any,
      • they just refuse cooperation with anyone who doesn't share their dedication.
      Dutch law allows quoting small parts of any work, whether GPL'ed or not,
      • and i think so does american law, but FSF refuses to acknowledge that their country's lawmakers had common sense.
      You call that free ?
    + It does not tell that most people have additional rights (like to quote),
    • and thus does not empower the users to use their rights.
    • This sounds more like free beer than like freedom to me.
    + It insufficiently limits what is allowed as invariant section.
    • It requires that contents of invariant sections must be metadata. Then it (seemingly out of the blue)
      • allows obligation to put an invariant section at a specific place.
      This creates an unbearable restriction on freedom of that work,
      • which can clearly be seen in a work that contains quoted portions of two GPL'ed manuals :
        • It would need to state on it's frontpage 'this is a foo manual' and 'this is a bar manual'. It would need to falsely 'acknowledge' on frontpage that
          • main authors of this document are authors of any GPL'ed document of which a part was quoted.
      I think the GPL could allow more lenient quotation on condition of
      • 'not more than x % of a work is quoted'.
      This example is about manuals, but same applies to libraries ;
      • if one function is copied, copyer would have to put same acknowledgement as when whole library was copied.
    • This has as a consequence that, imo, Debian should not automatically consider a GPL'ed work free. There are clear examples of what should be allowed :
      • copyright, acknowledgement of significant contributors, pointer to project homepage, notify that this is a modification, obligation to rename to avoid confusion. For the rest, i do not know of any things that should be invariant.
    + It does not distinguish between full copies and copies of minor parts of it.
    • I said that above already ; i think it is an independent point.
    + It works within the law.
    • That is to say, it does not offer any real protection :
      • Only the form is protected, not the content. Consequently, if it is copied into another form and then upgraded to it's next major version,
        • original work is used and GPL has not protected it.
      There's not much that can be done about this one.
    + It requires to provide source, but does not specify that requirement.
    • If source is not provided a year after it is asked for, it would not be a breach of GPL.
      • (breach requires proving in court that the intention to distribute was never present).
    + Does not allow pointing to Debian's archive for sourcefiles.
    • This restricts distribution more than it protects rights.
    + Demands that the act of running the program is not restricted,
    • which seems inconsequent as it forbids restricting use of the program to free platforms.
    + The thing that really protects the freedom is the availability on the web, not the GPL.

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

  • + It does not delete microsoft. + It does not keep Debian from becoming over-zealously idealistic. + Seriously, it does not require any derived work to be documented as well as the original is.
    • (i had this kde installation once, where it's helpfiles told me to click on the kde icon on
      • the toolbar ; and i couldn't find it anywhere. Later i found it hat been replaced with a picture of a red hat.)
    + It is itself not lenient enough. + It does not address the rightfull desire of authors to get rewarded
    • (like: if you do make a profit on this,
      • i want 10% times the fraction of your work that is my work)
    • Probably as a consequence of that, it requires PROMINENT notifications ; Paying attention is a form of paying,
      • so they don't really give it away for free, yet requirement to pay authors is not allowed by GPL.
    + It considers many things as not free that are seen by the general public as free.
    • Debian has that same problem. It results from looking from the standpoint of a limited class of users.
      • IT professionals (and professionalistic amateurs) need the source. End-users need the documentation. GPL only protects pro's

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

  • + It sets a standard. + It raises awareness. + It improves interoperability Maybe the GPL prevents abuse. I don't know an example where enforcing the GPL rectified abuse.

* Should a new GPL attempt to explicitly broaden its applicability

  • to works other than computer programs (e.g., image, sound, or music files; documentation; dictionaries; encyclopedias)?
  • + It should first be updated (or clarified that it's literal text is uptodate) + Then it should be amended, specifically to be more lenient. + If the result of that would be so well-considered as to be more widely applicable,
    • then broadening it's scope would be natural.
    • I would like it to be so general that
      • at it's extremes it would converge to an ideal for-profit copyright. I have not seen that yet.
      For freely distributable works, RFC's for example, balance of
      • need to distribute modified versus need to correctly document would be different.
      I am not overly impressed with GPL2's idea of optimal balance for programs.
      • On one hand it is so afraid of evil hijackers that it forbids more than necessary, On other hand It's ideals are so high that it does not allow
        • restricting use to platforms based on whether that platform as a whole is free.
    + The GPL itself can not be brought under the GPL. So in my opinion : No, it should not try to force that.

* What parts of the GPL are difficult to understand?

  • Every part of it that is not plain english.

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

  • what area(s) of the GPL do you find difficult to adjudicate ?

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

  • + How applicable it is in countries whose law is not based on roman law. + Everything that is not annotated.
    • (i am not an expert. there can be things i am unaware of everywhere.)
    + The differences between it's stated spirit and it's terms. (no quoting for example).

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

  • + It's original spirit and intent.

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

  • + Insensitiveness of it's invariant sections + It's legalese :
    • FREE LICENSES NEED FREE DOCUMENTATION
    • There are parts of it that are neither obvious nor annotated,
      • and for foreign readers plain english might be the only thing they can understand.
      Plus that it is not well-phrased to begin with.

* Is the time ripe for revising the GPL ?

  • Ie: will harvesting now yield good fruits ? Who knows. I hope it would include my two cents.

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

  • + Benefit. + The idea of it is sound,
    • even to the extent that awareness of it has grown over the years. Consequently, it could do with an update.
    + The idea of it being usable in a law setting is good,
    • but it is a bit too much like a law for my liking.

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

  • + Option variants.
    • If they want their entire work to be an invariant section,
      • why not give them that freedom of choice.
      But accompany it with a mention that Debian does not accept that as free. This way all (nearly) free licenses could be GPL variants. And it separates the legal formulation from the moral judgement,
      • which would be a good thing.

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

  • and how do you feel about these ?
  • + None that i'm aware of,
    • but if we want to comment on theirs, we should let them comment on ours.


Siward--

A couple of comments:

  • I'm glad that my call for comments has piqued your interest enough to join the wild and woolly world of Wiki. :) The formatting of your message, though, makes it more difficult for me to follow than it could be. Would you edit it to be more conventional, or permit people to update the formatting?

  • Some of your comments, such as those about "Invariant Sections" and "FREE SOFTWARE REQUIRES FREE DOCUMENTATION", are out of scope; they are about the GFDL (GNU Free Documentation License), not the GNU GPL (General Public License). While Don, Mako, and I are aware of deficiencies in the GFDL -- and the FSF is aware of our concerns -- the scope of this conference is the GPL. I'm pretty sure the GFDL will come up from time to time, but nevertheless, it would be helpful if you could limit your critique on this particular Wiki page to the GPL itself. Asides about the GFDL are fine, but right now your comment looks as if you have mistaken parts of the GFDL for parts of the GPL.

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


  • What are the current GPL's strengths?
    • Generally careful drafting.
    • Avoids being overly specific: specifies required results, not methods. This is necessary for a license which we want to last for a long time.
    • Almost totally unrestricted permission to use, examine, modify, etc.; the only substantial restrictions are restrictions on distribution, and that's as it should be.
    • Definition of "source code" as "preferred form for modification", and the requirement to make source code available when distributing a work in another form.
    • The fact that rights are received upon receiving a copy. This allows for private activities.
  • What are the current GPL's deficiencies?
    • Overly specific specification of means in certain places, such as clause 2a (almost never actually followed; the requirement that a changelog be present in every file is obsolescent)
    • "Activities other than copying, distribution and modification are not covered by this License; they are outside its scope." This is a bad piece of drafting. Instead, it should specify that any other activities restricted by copyright or patent law (such as use or performance) are permitted by the license without restrictions, provided the license is otherwise followed.
    • There is no explicit grant of unrestricted permission to use the Licensed Work (although there's an implied one in the preamble). Given trends in copyright law, as well as patent law, this should be made explicit.
    • Similarly, there should be an explicit statement that accepting the license does not restrict any "fair use", "fair dealing" or other rights which you would have if you didn't accept the license.
    • Clause 2c, which is an obnoxious non-free advertising clause, and is only saved by the "Exception:".
    • Sloppy drafting (in places).
    • Organized rather poorly in some ways.
    • The document -- specifically the preamble -- is not free software. This sucks and there's no excuse for it. The GPL should be licensed under the terms of the GPL. :-)

    • See all the other sections below for more suggested changes, all of which are "tweaks".
  • Are there significant threats to software freedom that the current GPL does not address?
    • Not really. By specifying the permissions which are guaranteed to any recipient provided the license is followed -- rather than making a list of prohibitions -- it covers it all, including *future* threats. I would have no objection to adding clauses specifying that the distributor may not use any means to restrict the recipient's exercise of the rights granted under the license.
    • However, the issue of patent and other non-copyright restrictions could be made more explicit. I would not change the terms, but it would be worthwhile to specify that the licensor is licensing the work for unrestricted use under any patents held, as well as licensing it under copyright law. In fact, it should license the work under any other potential laws which might restrict the granted rights in future -- such as the European database right. It can't "license away" all possible legal restrictions on use, modification, and distribution (such as export restrictions), but it can "license away" any restrictions which can be licensed by the licensor, and it should.
  • Should a new GPL attempt to explicitly broaden its applicability to works other than computer programs (e.g., image, sound, or music files; documentation; dictionaries; encyclopedias)?
    • Yes, but this should *not* involve substantive changes. The phrase "the Program" should be replaced with "the Licensed Work" throughout, after the "program or other work" line. The term "source code" should be clearly defined as "preferred form for modification" upfront (rather than buried at the bottom). In section 3, "Object code or executable form" should be replaced with "Object code, executable form, or another form other than source code".
  • What parts of the GPL are difficult to understand?
    • The "redefinition" of derivative work in clause 0. Simply defer to copyright law, and make it clear that the redefinition is not normative. This is important to make sure that no matter how copyright law changes, the GPL will still apply to everything covered by it.
    • The way it applies to works other than traditional computer programs. See above. I think there's only one reasonable interpretation, but it's confusing to a lot of people.
  • If you have copyright in a GPL-licensed work, what area(s) of the GPL do you find difficult to adjudicate?
    • The exact meaning of "distribution". However, I would not try to pin that down too much, because of the danger of specifying means. I would say that it consists of transferring a copy to another human.
    • The source code, which the distributor must provide, is the "preferred form for modification". But preferred by whom? In practice this has rarely been a problem, but it comes up occasionally -- we have often used "preferred by the person doing the distribution", but this may be open to abuse. "Preferred by the recipient" may be better but may also be open to abuse.
    • "Preferred form for modification" has raised one other interesting issue: Can the "preferred form" be a form which doesn't exist (such as lost source code, a translation of FORTRAN to C, etc.)? This should mean "preferred form for modification, out of those forms which the distributor knows to exist". This would assist projects which directly hack freely licensed machine code, which may once have been generated from source code decades ago, but for which the source code is long lost.
  • What part of the current GPL would you most like to see preserved as-is?
    • I have to pick one? Well, I would like to absolutely guarantee that no further restrictions on the permissions of recipients are added. No loss of freedom, that is. Contrast the GFDL, which was a loss of freedom relative to the old GNU documentation license.
    • After that, I guess the provisions about providing source code are really well designed and shouldn't be significantly changed.
  • What part of the current GPL would you most like to see changed?
    • 2c should be removed
    • 2a should be generalized to allow various forms of ?ChangeLogs, and generally to require less bookkeeping. I believe its purpose is to avoid "masquerading" versions, misrepresenting authorship, etc. -- trademark-like issues. Debian-legal has now had a lot of experience in such issues, and can suggest a much freer, better-written way to do the same thing.

  • Is the time ripe for revising the GPL?
    • No. Doing so while the GNU Project has damaged its own credibility with the GFDL and its completely phony "public outreach" effort for the GFDL is dangerously stupid. The GNU Project should have repaired its credibility (by, uh, FIXING THE GFDL) before attempting this.
  • On balance, has the GPL been a benefit or a detriment to the Debian Project?
    • Benefit.

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 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, [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