Emacs and the GPL
The Free Software Foundation (FSF) prides itself on being the champion of free software and its licensing, so a recent misstep with Emacs source code has to be a little embarrassing. But it is just that, a misstep, and one that was quickly addressed in two separate ways. While it may be tempting to lambaste the FSF and the Emacs developers for the oversight (and many have done so), it really should be seen as a lesson for projects and companies to be ever more vigilant regarding the licensing of their code. That may cause some to question whether complying with free software licenses is harder than it needs to be, but that would be ignoring the huge benefits that the GPL and free software bring to the table.
The problem stems from the inclusion of CEDET (a Collection of Emacs Development Environment Tools) into Emacs 23.2. CEDET has parsers for various languages that are based on Bison grammar files that get translated into Elisp (an Emacs dialect of Lisp). The grammar files were not included with Emacs 23.2 and 23.3, but, in addition, the Lisp output from the Bovine and Wisent parser generator tools used to do the translation had been hand-edited. That meant that even having the grammar files was insufficient to reproduce the Lisp code that got shipped with those versions of Emacs.
Needless to say, shipping code without providing source in the "preferred form of the work for making modifications" is not at all GPL-compliant. That's not really a legal issue for the Emacs project because the FSF owns the copyright to the code and is thus not required to follow the GPL. It certainly sets a bad precedent, however, and one that Richard Stallman and others wanted fixed in short order. That fix took two paths.
To start with, Chong Yidong created new versions of the two affected Emacs releases. Those included the grammar files and a script to apply the changes made to the Lisp output. That means that anyone distributing 23.2a or 23.3a would be in compliance with the GPL.
But that left those who had already distributed the earlier versions in a
bit of a bind, as they were in technical non-compliance with the GPL for
doing so. Stallman solved that problem with a grant of permission that essentially absolves
those distributors of any copyright violation and "extends to versions with unrelated modifications, provided those
versions comply with GNU GPL version 3 in all other respects
". He
also notes that the GPLv3 makes the process a little easier:
The version numbers aren't quite right in his explanation above (though they are in the grant), but his point is an interesting one. The GPLv3 has explicit language that reinstates the distribution right for violators if they cease the violation (which the permission grant effectively does) and aren't contacted by the copyright holder in 60 days. The picture for GPLv2 would have been a bit murkier because it lacked the automatic reinstatement of the license. Though, obviously, the FSF could have explicitly forgiven the earlier violations had Emacs been released under GPLv2.
Clearly Stallman is a stickler for adhering to the letter of the GPL—as he should be—and the problem was resolved less than a week after it came to his attention. The fact that it took more than a year for the problem to be recognized is unfortunate, but it stemmed from a misunderstanding about the "preferred form". It seems that Chong believed that the Lisp source code, which was distributed, was a reasonable interpretation of providing the source—which it is. Where it falls down, of course, is that it isn't the form that a programmer would want to use if they were to make modifications to CEDET.
There was some unhappiness expressed in the thread on emacs-devel regarding the coverage of the issue, specifically that which appeared at LWN. While there may have been some intemperate comments in the thread, it's a little strange to hear that coverage of the issue should have been out-of-bounds. As Stephen J. Turnbull points out, it's important for word to get out about the problem:
Turnbull's footnote notes that it is extremely unlikely that it would go that far, but his point is well taken. Whether one likes the coverage (and comments) or not, it is important for the word to get out to downstream distributors so that they can decide if they want to update to 23.2a or 23.3a. It would be well-nigh impossible for the project to find and contact all of the different distributors who have shipped the non-compliant code. The Linux and free software media have a role to play, though the coverage here and elsewhere still won't reach every downstream of course.
Turnbull also makes a larger point:
There is a cost associated with using free software, and complying with the license is the biggest part of that cost. Proprietary licenses have their costs as well, of course, and those can be partially measured in dollars. Complying with a thick stack of legalese in order to license some bit of proprietary code may seem easier, at least partly because companies are used to those kinds of licenses, but probably isn't. In the end, free software is an enormous bargain, in general, because the amount of work required to comply is far outweighed by the usefulness of the code. It may take a bit of a different mindset, but the value gained is enormous.
Beyond that, the GPL also provides a level playing field for contributors, so that individuals and companies can contribute to a common code base and know that no one has the upper hand. No one can take the code proprietary or make changes and distribute them without sharing those changes back. Copyright assignment (or licensing) may muddy the water to some extent, but, for many projects, the GPL provides the needed cover for competitors to collaborate.
In the end analysis, this was a minor problem that was addressed fairly quickly. The grammar files were always available at the CEDET site, and the handmade changes were pretty trivial overall. That said, it is important that it was found and fixed, not least because the FSF is the poster child for GPL compliance. The silver lining is that other projects are likely to remember this mistake and keep an eye out for similar problems in their own code. If suffering a little public embarrassment results in fewer GPL mistakes (and violations) down the road, the FSF's goals will have been well-served in the process.
Posted Aug 4, 2011 7:10 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
The "preferred form" issue also comes up when people license non-software works under the GPL. If you distribute an image under the GPL, and you created it with the Gimp, no one can pass it on if you didn't include the preferred form for making modifications; if you save your work in XCF, that's the "source" (likewise for Photoshop users it's the PSD). If you distribute music, and you produced it by mixing, again you haven't provided the preferred form (so your recipients can remix it). If it's a document, you can't just include a PDF, that isn't the source. The preferred form is the form that you, the author, preferred (perhaps you like LaTeX, or maybe LibreOffice).
Posted Aug 4, 2011 14:43 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Aug 5, 2011 17:06 UTC (Fri)
by hummassa (subscriber, #307)
[Link]
The GPL does not say to whom the "preferred form" is to be preferred...
Posted Aug 4, 2011 7:21 UTC (Thu)
by Thue (guest, #14277)
[Link] (4 responses)
Posted Aug 4, 2011 10:03 UTC (Thu)
by juliank (guest, #45896)
[Link] (3 responses)
Posted Aug 4, 2011 10:38 UTC (Thu)
by Thue (guest, #14277)
[Link] (2 responses)
> The problem here is that upstream is distributing created code without corresponding source code on their website.
but the source code is available from svn from the same download page which distributes the tarballs. (technically svn is at http://smarty-php.googlecode.com , but still arguably controlled by the person distributing the tarballs).
Isn't that good enough? As I wrote in the original bug report, you can get the source of fx 3.0.8 by doing
> svn export http://smarty-php.googlecode.com/svn/tags/Smarty_3_0_8/
Posted Aug 4, 2011 11:47 UTC (Thu)
by juliank (guest, #45896)
[Link] (1 responses)
The problem here being that the SVN is on a different server, maintained by the Google people. Tarballs of the source need to be provided together with the non-source, or the non-source tarballs must contain at least an offer to offer the source code if requested.
6. [...]
c) Accompany the work with a written offer, valid for at
d) If distribution of the work is made by offering access to copy
They should fix this by offering source code tarballs as well, we require them for Debian anyway (and other distributions probably do so as well).
Posted Aug 4, 2011 12:46 UTC (Thu)
by Thue (guest, #14277)
[Link]
The keyword here is "same place". I would argue that since both the tarballs and svn is available from the same download page, then the source is available from the "same place". Nowhere does the GPL say that the source has to be available as a tarball.
The svn repository is administered by the smarty developer, but hosted by Google. The smarty.net webpage is also administered by the smarty developer, but perhaps actually hosted in some datacenter, or on a rented virtual server. As long as the top layer of control is the Smarty developer, then it seems good enough according to my reading of the GPL.
Posted Aug 4, 2011 8:30 UTC (Thu)
by ayers (guest, #53541)
[Link] (4 responses)
The clear simplicity of Free Software licenses (and yes that includes the GPLv3 when compared to your classic EULA or redistribution agreements) just makes it much more obvious when a violation occurs that it becomes possible that nearly anyone using common sense can identify a potential violation.
That simply isn't the case in case in the proprietary world. Show me someone who understands the copyright, patent license and trademark obligations of distributing a .NET application for further redistribution, and I'll show you someone who is most likely confused.
The proprietary model as I see it, is about creating an unsurmountable confused mess of interdependent obligations, instating a direct or indirect revenue stream and ignoring the convoluted obligations as long as that revenue stream is satisfactory. Once that satisfaction falls below a threshold you start looking for violations, which are bound to exist, to increase that revenue be it by negotiation or litigation.
Posted Aug 7, 2011 8:45 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
This is not the most important distinction. The most important distinction is the fact that you operate within framework of for-profit people. If violation is found (and it happens with proprietary software more often then with free software, actually) then your development team is rarely affected. Different people are dealing with proprietary licenses and with free software licenses. Proprietary licenses are confined almost exclusively to legal department: developers contact them when they need/want to use some proprietary tool, get the approval (or rejection) and forget all about licenses: when the approval is given it's up to legal department to solve further problems. Copyleft works in entirely different fashion: it does not contain any complex puzzles for legal department, but it does contain strict requirements for developers which are accustomed to entirely different modus of operandi. Exactly. This makes it safer for companies: it's easier for them to estimate risks. Since it's all about money it's easier for them to estimate what is expected, but, what is more important it's up to the legal department to settle the problems, developers are never involved... Well, legal department can revoke the right for some component and then developers need to redo their work, but this all happens in the same fashion, developers never need to think about how their source is organized and what pieces can never be published and what they are expected to publish, etc. Free software imposes smaller burden then typical proprietary licenses (that's why they are growing much faster), but this is entirely different kind of burden - a lot of companies just don't know what to do about it.
Posted Aug 8, 2011 12:15 UTC (Mon)
by Trelane (subscriber, #56877)
[Link] (2 responses)
Proprietary software can come with all kinds of restrictions, not just on what you can and cannot ship and how you can ship it but also what you can and cannot *do* with the software yourself. Keep in mind also that not all proprietary customers are equal, and some really *do* get to look at (some of) the source and do (highly restricted) things with it.
Posted Aug 8, 2011 12:20 UTC (Mon)
by Trelane (subscriber, #56877)
[Link]
B. License to Distribute Software. Subject to the terms and
conditions of this Agreement and restrictions and
exceptions set forth in the Software README file,
including, but not limited to the Java Technology
Restrictions of these Supplemental Terms, Sun grants you a
non-exclusive, non-transferable, limited license without
fees to reproduce and distribute the Software, provided
that (i) you distribute the Software complete and
unmodified and only bundled as part of, and for the sole
purpose of running, your Programs, (ii) the Programs add
significant and primary functionality to the Software,
(iii) you do not distribute additional software intended to
replace any component(s) of the Software, (iv) you do not
remove or alter any proprietary legends or notices
contained in the Software, (v) you only distribute the
Software subject to a license agreement that protects Sun's
interests consistent with the terms contained in this
Agreement, and (vi) you agree to defend and indemnify Sun
and its licensors from and against any damages, costs,
liabilities, settlement amounts and/or expenses (including
attorneys' fees) incurred in connection with any claim,
lawsuit or action by any third party that arises or results
from the use or distribution of any and all Programs and/or
Software. [...] D. Java Technology Restrictions. You may not create,
modify, or change the behavior of, or authorize your
licensees to create, modify, or change the behavior of,
classes, interfaces, or subpackages that are in any way
identified as "java", "javax", "sun" or similar convention
as specified by Sun in any naming convention designation. E. Distribution by Publishers. This section pertains to
your distribution of the Software with your printed book or
magazine (as those terms are commonly used in the industry)
relating to Java technology ("Publication"). Subject to and
conditioned upon your compliance with the restrictions and
obligations contained in the Agreement, in addition to the
license granted in Paragraph 1 above, Sun hereby grants to
you a non-exclusive, nontransferable limited right to
reproduce complete and unmodified copies of the Software on
electronic media (the "Media") for the sole purpose of
inclusion and distribution with your Publication(s),
subject to the following terms: (i) You may not distribute
the Software on a stand-alone basis; it must be distributed
with your Publication(s); (ii) You are responsible for
downloading the Software from the applicable Sun web site;
(iii) You must refer to the Software as JavaTM 2 Platform
Standard Edition Development Kit 5.0; (iv) The Software
must be reproduced in its entirety and without any
modification whatsoever (including, without limitation, the
Binary Code License and Supplemental License Terms
accompanying the Software and proprietary rights notices
contained in the Software); (v) The Media label shall
include the following information: Copyright 2004, Sun
Microsystems, Inc. All rights reserved. Use is subject to
license terms. Sun, Sun Microsystems, the Sun logo,
Solaris, Java, the Java Coffee Cup logo, J2SE , and all
trademarks and logos based on Java are trademarks or
registered trademarks of Sun Microsystems, Inc. in the U.S.
and other countries. This information must be placed on the
Media label in such a manner as to only apply to the Sun
Software; (vi) You must clearly identify the Software as
Sun's product on the Media holder or Media label, and you
may not state or imply that Sun is responsible for any
third-party software contained on the Media; (vii) You may
not include any third party software on the Media which is
intended to be a replacement or substitute for the Software;
(viii) You shall indemnify Sun for all damages arising
from your failure to comply with the requirements of this
Agreement. In addition, you shall defend, at your expense,
any and all claims brought against Sun by third parties,
and shall pay all damages awarded by a court of competent
jurisdiction, or such settlement amount negotiated by you,
arising out of or in connection with your use, reproduction
or distribution of the Software and/or the Publication.
Your obligation to provide indemnification under this
section shall arise provided that Sun: (i) provides you
prompt notice of the claim; (ii) gives you sole control of
the defense and settlement of the claim; (iii) provides
you, at your expense, with all available information,
assistance and authority to defend; and (iv) has not
compromised or settled such claim without your prior
written consent; and (ix) You shall provide Sun with a
written notice for each Publication; such notice shall
include the following information: (1) title of
Publication, (2) author(s), (3) date of Publication, and
(4) ISBN or ISSN numbers. Such notice shall be sent to Sun
Microsystems, Inc., 4150 Network Circle, M/S USCA12-110,
Santa Clara, California 95054, U.S.A , Attention: Contracts
Administration.
Posted Aug 8, 2011 18:41 UTC (Mon)
by elanthis (guest, #6227)
[Link]
Quite a few proprietary licenses are source licenses. Full source licenses. With relatively permissive terms controlling what you can do with the source. (Obviously giving the source away or reselling it is out, which is hugely restrictive compared to FOSS.) This is particularly common in the middlware and tools market and in the games market (which is mostly about middleware and tools).
Posted Aug 4, 2011 10:02 UTC (Thu)
by emk (subscriber, #1128)
[Link]
We caught the GPL violation before distributing 100 copies, fixed it, reported ourselves to the FSF, and begged for mercy. They were entirely reasonable about the situation, and asked us to make the newly-fixed version of our software available to the people who had received the previous version. So in the real world, accidental GPL violations can usually be resolved easily, especially when they're as minor as the Emacs situation.
Posted Aug 4, 2011 15:53 UTC (Thu)
by debacle (subscriber, #7114)
[Link] (1 responses)
Posted Aug 5, 2011 3:38 UTC (Fri)
by elanthis (guest, #6227)
[Link]
If you're going to use proprietary code, at least try to use proprietary code written by competent, helpful people. :)
Posted Aug 4, 2011 17:24 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (2 responses)
It is fairly common for programs to be written by programs based on some source of data. For example, if you embed a list of information (phone area codes or something that changes only slowly) into a C header does a GPL program then have to include the list used to feed into it and the trivial script that transformed it into a header? Any future changes would as likely be made by just patching the header as regenerating it. Is it that bison was used instead of a one off perl script that makes it different?
Or try this: XBM images are C headers, so do they require the 'original' image? Must the software used to translate between that original format and XBM be included? Where does the line between sanity and reductio ad absurdum lie when lawyers are involved?
Posted Aug 5, 2011 0:10 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (1 responses)
If not, I doubt he would have bothered to respond to the complaint by distributing the BISON source and a program that automates the hand-edits.
I think people understand the idea that sometimes source code was originally generated from some other input file, but is nonetheless the source code -- the preferred form for making changes -- after that.
We haven't seen much controversy over preferred form, but I assume if there ever is any, the methods that the alleged copyright infringer uses himself to modify the code would figure strongly into deciding the issue.
Posted Aug 13, 2011 13:19 UTC (Sat)
by JanC_ (guest, #34940)
[Link]
Posted Aug 4, 2011 20:55 UTC (Thu)
by ndk (subscriber, #43509)
[Link]
Assuming that this does indeed refer (only) to the linked post (and not to some comment made later in that thread - which I did not read any further), I can't find corroborating evidence for your statement. To quote from that post:
"Anyway, even though the publication seems to me to be in bad taste and
So it's inaccurate to say that he said (or even implied) that "the issue should have been out-of-bounds."
Posted Aug 11, 2011 2:58 UTC (Thu)
by Hausvib6 (guest, #70606)
[Link] (1 responses)
Like FSF, I'm not violating GPLv3 because it's my own creation but all redistributors are GPLv3 violators.
I think this will greatly encourage the adoption of copyleft license by developers given the possible incentive when they "forget" to include some files.
Posted Aug 11, 2011 3:03 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
1. Create useful software. It's FLOSS and MIT/X11.
If you're the copyright holder and you gave the software to other people then estoppal will typically protect them from you. If someone else holds the copyright over part of it, then the situation's the same as above - whenever you distribute software you're taking the word of the person you got it from that they have the legal right to provide it to you under the claimed license. There's nothing special about the GPL here.
Posted Aug 11, 2011 8:19 UTC (Thu)
by slashdot (guest, #22014)
[Link]
Perhaps it's time to audit distros, looking for C code that came out of specialized preprocessors that are not included and that winds up linked with GPL code.
The "preferred form" issue
The "preferred form" issue
Perhaps it's time to audit distros, looking for C code that came out of specialized preprocessors that are not included and that winds up linked with GPL code.
Of course that wouldn't have spotted this problem, which is elisp code which came out of a specialized preprocessor and was not linked with anything, but *is* itself licensed under the GPL.
The "preferred form" issue
$ grep "preferred form" debian-l-index | wc -l
1232338473763 lines
$ :D
Emacs and the GPL
Emacs and the GPL
Emacs and the GPL
Emacs and the GPL
> from the same download page which distributes
> the tarballs. (technically svn is at
> http://smarty-php.googlecode.com , but still
> arguably controlled by the person distributing
> the tarballs).
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
Emacs and the GPL
Companies are used to complying with a thick stack of legalese? - please
It's not a common myth, it's simple truth...
The fact that very few people can claim to understand the intricacies of the plethora of interactions of proprietary license schemes with all their cross references simply hides the contradictions and violations from the public view.
The proprietary model as I see it, is about creating an unsurmountable confused mess of interdependent obligations, instating a direct or indirect revenue stream and ignoring the convoluted obligations as long as that revenue stream is satisfactory. Once that satisfaction falls below a threshold you start looking for violations, which are bound to exist, to increase that revenue be it by negotiation or litigation.
It's not a common myth, it's simple truth...
Take, for example, (part of) the JDK5 license (http://java.sun.com/j2se/1.5.0/jdk-1_5_0-license.txt)
It's not a common myth, it's simple truth...
It's not a common myth, it's simple truth...
Emacs and the GPL
Cost of free and proprietary software
> There is a cost associated with using free software, and complying with the license is the biggest part of that cost. Proprietary licenses have their costs as well, of course, and those can be partially measured in dollars.
I would like to add, that complying with proprietary licenses is a also a big part of the cost on that side. In many cases, it is even more difficult than with free licenses. Think about licenses that make it hard to change the hardware, or licenses that force you to enjoy long, very boring phone calls etc.
Cost of free and proprietary software
Preferred form
My impression from the story is that the BISON source is in fact the preferred form for making most changes to this code, and the original author's method for making changes was to change the BISON source, compile it to elisp, then hand-edit the elisp.
Preferred form
Preferred form
Emacs and the GPL
ill-advised, I would not want to have mailing list or archives limited
to a closed circle."
Emacs and the GPL
1. Create a useful software. Don't worry, it's FLOSS and of course, GPLv3.
2. "Forget" to include some file, like in Emacs case.
3. Wait for people redistributing my software.
4. Ask them to settle for some amount of money.
Emacs and the GPL
2. "Forget" that some of the code in it was copied out of the leaked Windows 2000 source
3. Ask Microsoft for a cut of the proceeds
Emacs and the GPL