Why Should I Sign Copyrights To The FSF?
Honza Jirousek asks: "The issue of signing copyright for patches to GNU software or even whole new GPL-ed programs to the FSF came up several times in various dicussions, last time in recent cphack threads and in this Wired article on the same topic. Some indicate this may even be a requirement for accepting larger patches for some GNU programs, such as emacs. I never managed to find more specific information on that. Can someone explain this practice and point to more information? I understand the positive effects of this (FSF being better positioned to defend the copyleft, possibility to change the licence to newer versions of GPL etc), but I can also see an interesting side-effect - in some cases it effectively puts the FSF in the privileged position of sole copyright holder, who can re-license the code. This is similar to special provisions of 'original author' in licences such as NPL, often criticized exactly for this. Or am I getting it wrong? Contrast this to programs such as Linux kernel, where the copyright is so distributed, that re-licensing will never be possible." (Read on...)
Pay particular mention to the mention of section 17 U.S.C. 205e of the U.S. Copyright Laws. What does it actually do to the protections offered by the GPL and should we be worried?
>mean, IANAL, but my understanding is that the
>copyright owner has the authority to license
>their work for redistribution. However, Linux
>doesn't appear to have a copyright owner. As a
>result, if the GPL collapsed legally and needed
>to be rewritten, then Linux is dead. Why? Because
>NOBODY has the authority to redistribute the
>kernel.
The GPL covers this eventuality, because it's version 2 "or future versions". The FSF could come out with a new version of the GPL that addressed whatever problem the license might have, and there you go.
Strangely enough, if the FSF got taken over it could come out with a new GPL that allows proprietary use, and kill it anyway, so really what are people losing by signing over the copyright? It's not like they're giving them more power than they already have: they can't.
That said, from an administrative standpoint requiring signing over the contract cripples GPL programs because the spur of the moment aspect of a lot of development is outright KILLED by it. If you have to fill out the equivalent of tax forms to get your contribution accepted, screw it.
This is why GNU languished for years and Linux took off immediately. Idealism gives us our frame of reference, but pragmatism is what works.
Rob
I see two reasons. One, the FSF is probably better armed when it comes to kicking the snot out of someone when copyright is infringed.
The second, which applies especially well to huge projects with hundreds of authors, is that the lead maintainers/authors don't need to do the whole 'who wrote what' game everytime there is a question of copyright and/or license exception. If I, as the PM of something as huge as Xfree or emacs, would not want to have to deal with even one disgruntled submitter of code six months after the fact. One of the lead assumptions in the second is that the FSF is merely a 'puppet' for the authors, and would abide by their decisions in the matters of copyright.
Well, I lied. I can think of a third. Orphan programs. Stuff abandoned by the copyright holder but still maintained by others, that needs an updated license (eg, a hole has been found in the 1.0 GPL it was released under). If I can't find all of the authors, I can't say 'This, and all later revs, are GPL v3.2'. I can't make an exception for the greater good and grant a conditionless license. (remember Corel?)
.sig: Now legally binding!
Whether or not assignment is required depends on the project. For most officially FSF sponsored projects such as Emacs, gcc, etc, the copyright is held by the FSF and each contributor is required to assign their copyright to the FSF. Additionally, contributors may be required to receive a copyright disclaimer from their employer if they work in the software field and have an employment agreement that specifies everything they do is owned by the employer.
The rationale seems to be two fold:
1. Following these rigid procedures ensures that there is "clear title" to the code, and that it is properly licensed under the GPL. Who knows what hidden licensing bombs might lurk in the Linux kernel code.
2. If the FSF owns the code, they will have standing in court to pursue violators of the GPL. If the code infringed were owned by someone else, the FSF might not be able to go after the bad guys.
I've always been very down on copyright assignment because I think it is antithetical to the GNU believe that "software should not have owners". It seems highly ironic to me that the FSF is very demanding that they do in fact own the code.
OTOH, recently I've come across two practical cases where assignment has helped:
1. The case of someone trying to rescind the GPL as we have all read about here. The retroactive element is an interesting one, but not really that important. With FSF copyright we know that all future releases will be free software.
2. It simplifies relicensing. One of my projects recently merged with another one and the FSF agreed to switch licensing terms from the LGPL to the libstdc++ license (GPL + exceptions). This would have been very difficult to do with individual copyrights held by contributors.
Well, I'm the author of a utility that was recently accepted as GNU software. At the time when I was swapping emails with RMS and a great guy named Jonas Oberg, I asked about just this type of stuff.
I was told that if I chose, I could assign the copyright for the entire program to GNU, or I could retain the copyright myself. Not knowing what I was doing at the time, I chose to keep the copyright since I felt that would be safer.
As it turns out, I think the main difference between assigning the copyright to GNU and not doing it is if there is a dispute, or if company X is using your GPL'd source code in some way that is contrary to what the GPL says, if the code's copyright is held by the FSF, they'll stand up for it and litigate, whereas if the individual keeps the copyright, GNU may not have a stake enough to through their weight against the company.
Frankly, if there's anybody on earth that I TRUST to hold the copyright and make sure that the GPL is enforced, it's Stallman and the FSF.
As for signing over patches, I think it's possible that the FSF has gotten burned in the past on submissions being written by people at their jobs, incorporating the patches, and then finding out later that the employee didn't have the write to submit that code under the GPL since it was written on the company's time and hence property of the company.
Signing over patches and explicitly authorizing them for the FSF is a procedural thing to make sure that the free software we use remains pure of other types of non-free code, and presents as small of a profile as possible to litigious lawyers who might want to take someone to court over possible misappropriations of source code.
I think it makes sense to even require this of people. Why else would you be writing software for the FSF if it wasn't going to be GPL'd? If that's the case, why wouldn't you want someone larger than yourself to be able to back and protect the code? The only problem with this I could see would be if you didn't trust the FSF. If that's the case, I'd wonder what your reasons for that are, but I won't disagree with your personal feelings about the FSF.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
I feel a need to correct a legal assumption thats being made here.
There are some good arguments for FSF owning copyright to works they destribute. (Although I too am struck by the irony and potential hypocracy-- thats aother point, see below.)
BUT you do not need to give up your ownership of Copyrights to give Copyrights to another. There is a concept under Copyrigtht law calls "joint copyright." This leaves your rights intact escept for the fact that it gives the joint tennent equal rights to modify,license, destribute, etc. I can't see a good argument why this would not qork for FSFs stated aims. Can anyone suggest one?
Also, its worth nothing that book publishers can and DO proetct their books, even though they don't own the copyrights outright. The contracts they have with the authors take care of granting them the right to pursue infringers. Although I dopn't know the details of those arrangments, they can and do exist.
On that second subject I promised to touch on. It is ironic, and perhapse hypocritical to some degree, that the FSF could not exist as it is without Copyrights. If FSF REALLY believed in 100% free, no restrictions software, they would not license but rather put the software into the public domain.
Instead, Stahlman developed the GPL as a way of attempting to bribe/cooerce others into the same release rules fro their software as hee wanted for his own.
Is requiring subscription to a poltiical agenda really any less intrusive then requiring cash payment?
Something to think about.
Yes, as the sole copyright owner, the FSF can relicense should they choose to do so. However, as you have a copy of the software under the GPL, you still have the rights to make derived works.
However, should a third party begin using the Linux kernel illegally, it would be interesting to see how it could be enforced. First of all, the author of the specific code would need to file the suit. Now, this might be a random programmer somewhere, without the legal staff of the FSF.
Also, it is questionable if the GPL would work. I mean, IANAL, but my understanding is that the copyright owner has the authority to license their work for redistribution. However, Linux doesn't appear to have a copyright owner. As a result, if the GPL collapsed legally and needed to be rewritten, then Linux is dead. Why? Because NOBODY has the authority to redistribute the kernel.
Without a single owner, it couldn't be placed under a new license that could be upheld. Furthermore, a single GPL license for Linux may not be reasonable. Why? Each section is owned by a different individual. It would appear, to me, that they would all have to have their copy of the GPL included, and you should, theoretically, need to agree to dozens of separate GPLs with different parties to redistribute the GPL.
This is a potential nightmare. Again, it all comes down to, do we do things the "Right Way" FSF style whoses body of lawyers and Ph.Ds have done their best to work within the legal regime. Of the "hacker way" of daying "damn the man" even if it means that the GPL'd code base is worthless because we haven't done it correctly.
For example, say there is code in the Linux kernel written by someone under the employ of Microsoft. They didn't aquire a release from Microsoft to license their code under the GPL. Microsoft wants to shut down Linux, and files a lawsuit against Redhat, Caldera, S.U.S.E., the owners of various FTP sites with Linux, etc. Why can they do this? Because they own some code within the kernel that is being illegal distributed.
The Linux way leaves us open to blackmail or destruction by ANY malicious company whose employee didn't double check his contract and wrote kernel code. The FSF way guarantees that the code will always be free, although if the FSF went renegade, we would need to fork it under the GPL. If the FSF has the authority to revoke the license (we don't know what the courts would say) and they chose to do so, there is nothing that we can do, as FSF code is everywhere, so we'd be screwed. Worrying about the FSF turning on free software is absurd, because if they did so, we're dead regardless of if we turn the code over or not.
Now, I can think of two recent slashdot articles demonstrating the pros and cons.
BeOS, a well liked company, took code accidentally into a closed module. The code wasn't really used, but it was there. Bruce Perens, as the copyright owner, was able to issue them a writ allowing it. If the FSF owned it, they would have probably demanded that BeOS open that module... what would be better? I don't know. The former built up good will, the latter would result in more open code.
The other example is the nVidia mess. Much like the example of a company building a derived work from GNU Readline (I think I have the right name), the FSF might have been able to demand that they open the module or face a lawsuit. Instead, the individual developer accepted the answer of: "we'll fix it in a few weeks by removing your code" instead of demanding that they open the module.
I would suggest that in nVidia's case, the latter would have been better. The reason is that I am fundamentally opposed to groups writing closed code to interface with the Linux kernel. They are using a technicality in Linus's interpretation of the GPL to avoid contributing back while using the GPL code to sell hardware.
Why is this different? Be is writing a closed source OS that tries to be friendly to the free software community that made a mistake, and is moving the code out of all CDs. nVidia is trying to profit off the free software community by using Linux to sell hardware without giving back.
I WISH that the FSF owned the code in question.
Alex
That said, I support doing copyright assignments to the FSF because it allows me to do the job I want to do. When I program for GNU, I don't want to deal with lawsuits, liability insurrance, and license agreements. Canada has a screwed up enough legal system without me trying to understand what happens in the USA (Much less the rest of the world). When the FSF takes over ownership of my program, I no longer need to worry about this. I also like the fact that the FSF can choose to change/modify the licensing as appropriate.
I'm also not without protection. Specifically two things: The GPL ensures that if the FSF does get corrupted, I am free to fork and continue (taking on the legal burden myself, or with whatever organization with which I choose to associate). I am also protected by specific provisions in the assignment form:
(d) FSF agrees to grant back to Developer, and does hereby grant, non-exclusive, royalty-free and non-cancellable rights to use the Works (i.e., Developer's changes and/or enhancements, not the Program that they enhance), as Developer sees fit; this grant back does not limit FSF's rights and public rights acquired through this agreement.
4. FSF agrees that all distribution of the Works, or of any work "based on the Works", or the Program as enhanced by the Works, that takes place under the control of FSF or its agents or successors, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to FSF or to anyone else for any permitted use of the work they apply to, or to communicate with FSF or its agents or assignees in any way either when redistribution is performed or on any other occasion.
5. FSF agrees that any program "based on the Works" offered to the public by FSF or its agents or assignees shall be offered in the form of machine-readable source code, in addition to any other forms of FSF's choosing. However, FSF is free to choose at its convenience the media of distribution for machine-readable source code and may charge a fee of its choosing for copies.
The full text if you're interested can be found at the GCC site's contributing section. If there are cases where there are "extraordinary circumstances", the FSF is sometimes willing to do up special assignment forms to help. RMS normally just deals with those, however.
If you're interested in seeing the information given to maintainers of GNU packages, take a look at Information for Maintainers of GNU software on the GNU site, specifically the section on Copyrights.
(disclaimer: I program for GNU, I don't represent, work for, etc - My opinion only...)