Nobody is discussing the reason for the copyright-assignment requirement. I only know about it because I was caught in the issue that it means to prevent nearly 20 years ago.
The issue is that in many places (for example New York State), work done by a professional employee actually belongs to your employer. A developer can write code, contribute it where they want, and license it as they wish. But the code is actually owned by their employer. Which means that if there is a future problem, the employer can assert their copyright interest and people who thought that they had the right to use that code, suddenly don't.
Because developers themselves are seldom aware of such rules, the FSF took the ultra-safe approach of requiring employers to sign off. That way they are absolutely sure that there will never be a problem.
However other open source projects have found that, in practice, problems are rare. And when there is a problem, the employers usually will agree to the license.
AFAIK (one of the) the main reason for the copyright requirements is so that the GNU project can update the license, when a new version of the GPL is released, fixing loopholes or other issues in older versions. I am weary of dropping the copyright assignment, because issues like Tivoization could always pop up without anyone anticipating it, and even have contributors actively resisting the updates to fix these issues.
(Edit: What I also came to think of is that GCC recently positioned itself in opposition to the FSF because of the "Stallman-Controversy". Is this a kind of retaliation on their part?)
Copyright assignment is about enforceability, not updating the license. It's much easier to maintain copyright registrations, and to prosecute an infringement case, when you control all the copyrights.
Anyhow, we don't have to guess why they want it:
> Under US copyright law, which is the law under which most free software programs have historically been first published, there are very substantial procedural advantages to registration of copyright. And despite the broad right of distribution conveyed by the GPL, enforcement of copyright is generally not possible for distributors: only the copyright holder or someone having assignment of the copyright can enforce the license. If there are multiple authors of a copyrighted work, successful enforcement depends on having the cooperation of all authors.
> In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer. That way we can be sure that all the code in FSF projects is free code, whose freedom we can most effectively protect, and therefore on which other developers can completely rely.
> Under US copyright law, which is the law under which most free software programs have historically been first published,
They are published with a worldwide public licence; I'm not even sure how one can publish something such as that under any specific law.
One drafts a public licence, and different parts of it are enforceable to different degrees in different jurisdictions.
It is of course quite possible for the licence to be gnostic of the country of the acceptee, and apply differing provisions in different cases, but I would feel such would strongly go against F.S.F. philosophies.
Can't you enforce a license too? A license is a contract and if code is released in breach of that license than should be enforceable as well.
Is the issue that a license breach is a legally weaker case than copyright infringement?
There could be all kinds of secondary motivations, including that ability. But most GPL'd software includes the "or later" provision, which means it's relatively easy for the FSF to update the license of projects, especially if they stipulate that contributions must be licensed thusly. Note that with or without assignment, the FSF could never rescind the license on previously released software, except perhaps for infringers (because of the termination clause). So assignment doesn't actually provide much value on that score except as it relates to enforcement.
The GPL already includes a clause stating "or any later version" so GNU software can happily update the GPL version. Linux specifically has an exception to this. It is the dodgiest part of the whole GPL in my opinion and gives the Free Software Foundation a lot of power and makes it impossible to fork or replace the established organisation if it goes awry.
Actually, the GPL itself does not contain that clause. The FSF encourages you to release software as "GPL 3 or later", but if you don't explicitly state that (by using their recommended license notice, or otherwise) then your work is only licensed under that exact version of the GPL.
One noteworthy case is that Linus did not release the kernel as "GPL 2 or later" and as such it is still GPL 2, and incompatible with GPL 3 licensed code.
Of course (almost?) all GNU and FSF projects, like GCC, include the "or later" clause.
This is a classic case of somewhat-unintended consequences. When the GPL was first published, authors assumed developers would actually read it, and provided the recommended notice as a customizable template. Instead, developers just blindly copypasted, because "who's got time to read, amirite?". And then somebody actually woke up to the "or later" clause when the tivoization debate happened, and started accusing this and that of nefarious intent.
The problem appears to come when someone doesn't have the right to license it under (any) GPL in the first place because their employer owns all code they write.
Yes, but I can’t put GPL on someone else code. Whoever owns the code has to do it. And when I write code for hire, I have no right to the code, the legal person who hired me does.
So, how would I put a GPL license on code that I wrote for somebody else without their permission?
> I can’t put GPL on someone else code. Whoever owns the code has to do it.
Perhaps a nitpick, but this doesn't seem to take account of derivative works like forks. If Alice releases libalice under a permissive licence, Bob can develop a fork of libalice and release that fork under the GPL.
When writing GPL'ed code for your employer your employer must obviously be (made) aware that that code is going to be licensed under the GPL. Therefore, as the copyright holder -- they have already given permission for that license to be used or they must do so.
Nope, sorry, it's not that straightforward at all: Under American labour laws (in many, but perhaps not all jurisdictions), your employer owns the copyright to whatever you write even on your own time. So they might not even have known, at the time, that you were writing something in the first place. But if you do so and release it without notifying them, and they later find out you wrote it while in their employ, they might claim that "Hey, that's _ours,_ and we sure never authorised releasing that under <<whatever>> license!"
I think you might be missing context for the thread? Or maybe I'm inferring context that isn't there.
I thought we were discussing the "no copyright assignment" scenario.
> But if you do so and release it without notifying them
That's them not doing due diligence as far as I can tell. The employee would also be in breach of contract, possibly even committing a crime.
Employees can do all sort of illegal acts while in the employ of someone else... and when that happens you prosecute them (if it's egregious enough).
I suppose it may mean that an upstream project may be harmed quite badly if this goes on for long enough...
... but that's no different for any open source project. Or even closed source: Maybe an employee is working for two companies and 'reusing' code in an unauthorized way.
> I think you might be missing context for the thread? Or maybe I'm inferring context that isn't there.
I don't think I was, and I think you were.
> I thought we were discussing the "no copyright assignment" scenario.
Yup, exactly. Not that it makes much of a difference: To release something under any license, even without assigning any copyright, you need to have the copyright. (Or similar rights granted by a license, but in the end those too have to stem from someone actually having the right to license the thing they're licensing -- i.e. copyright.)
> > But if you do so and release it without notifying them
> That's them not doing due diligence as far as I can tell.
Not if you wrote and released it after you were already employed, now is it?
> The employee would also be in breach of contract, possibly even committing a crime.
Yes, exactly. Are you saying that can never happen, or what? That's exactly what I was pointing out.
> Employees can do all sort of illegal acts while in the employ of someone else... and when that happens you prosecute them (if it's egregious enough).
Sure. But if you're a FOSS project that they've contributed code to, with or without copyright assignment, that doesn't help you. You've still got to rip it out.
Sigh... I must have been unclear in my GP comment. So I'll go back to your GGP and try another tack:
> > > When writing GPL'ed code for your employer your employer must obviously be (made) aware that that code is going to be licensed under the GPL. Therefore, as the copyright holder -- they have already given permission for that license to be used or they must do so.
But if you write code and release it under the GPL there's nothing to say that you necessarily are doing it "for your employer". People could well assume that since they wrote something on their own machine and their own time, it has nothing to do with their job -- and then be in for a nasty surprise when their employer has a different opinion on that. The employer may well have had no idea at the time that someone was writing and releasing code, so they have neither already given permission for it to be licensed thus, nor do they have to.
> Sure. But if you're a FOSS project that they've contributed code to, with or without copyright assignment, that doesn't help you. You've still got to rip it out.
That was kind of my point, at least. Anyone can fake a copyright assignment form if they really want to, so we're not better off asking for it?
> That was kind of my point, at least. Anyone can fake a copyright assignment form if they really want to, so we're not better off asking for it?
Dunno fersure, but probably yes, after all: If you're the project and have a signed statement, at least that shows that you're not just blithely grabbing whatever you can but are actually doing your best (WTF else could you do?[1]) to ascertain that you are in the clear. If the statement the contributor signed is false, that's on them, not you.
___
[1]: What you could do is perhaps have the statement include an explicit bit about "I don't have an employment contract that assigns this copyright to any employer / I have permission from my employer to sign away this copyright on their behalf; see attachment 2B". Dunno if these assignment docs already have that. If not, perhaps they should.
The original author contributes the code under "or any later version". So the project maintainer (or anyone) can then use a newer version of the GPL if they want (but not some other unrelated version).
> That’s the part I’m stuck on. How would I do that on code I do not own, because I wrote it for hire?
Well anyone can write a letter that says "I hereby grant you a license to use this code under these terms...", but if they don't hold the copyright on it then the letter is meaningless (or maybe fraudulent). So in court you would have to prove that that person's copyright is actually valid, and if the code was written by someone who was employed and their employer didn't sign a disclaimer of work-for-hire ownership claims, then that could be disputed.
If you want to enforce the copyright against other people, as the FSF did, then that's bad. If you just want to avoid getting sued yourself, then it's probably not really a problem, because the employer would have to positively prove that they held the copyright to be able to enforce it. That said, some projects that don't require copyright assignment do still require a disclaimer of work-for-hire claims in their CLA.
You don't own the copyright so you can't license it under any licenses. So your original contribution was unlicensed and therefore the owner of the copyright can declare all use by anyone as infringement on their IPRs.
Doesn't this work out a bit like MongoDB, where Amazon forked a version released before they replaced the GPL with their own license? Meaning the freedoms of the GPL will be withheld, no?
Yes it's very similar, the scope is just vastly different. If you have the "or later" GPL clause in your license then any new version of the GPL is retroactively a valid licensing option for your code, even if it's vastly different or actually removes freedoms. If they wanted the FSF could release GPLv4 tomorrow that just says all code licensed under it is public domain, and instantly all code with the "or later" clause could be treated as public domain.
I figured that's why the GPL includes the language that says "GPL {x} or at your option a later version". That way, if you want to go to GPL {x+1}, the license already allows it.
Yup. But, remember, that's only if the original licensor actually executes that option, by explicitly stating so. If they says[1] "...under GPL version X", period, then that's it.
> (Edit: What I also came to think of is that GCC recently positioned itself in opposition to the FSF because of the "Stallman-Controversy". Is this a kind of retaliation on their part?)
More like a necessity to keep the project alive. Half of the top contributors threatened to leave when FSF tried to coup the steering committee.
> What I also came to think of is that GCC recently positioned itself in opposition to the FSF because of the "Stallman-Controversy". Is this a kind of retaliation on their part?
"Random acts of rms" aren't a new problem for the GCC developers, and resulted in the egcs split, have caused ongoing pain with people trying to improve the ability of GCC to integrate with IDEs, and of course there's the whole debacle where the Clang developers offered their work to the FSF but Stallman missed the email and found it a decade later...
However, several of the lead developers for C++ (at least) announced they were no longer going to be assigning their code ownership to the FSF in the wake of the recent FSF calls around rms, which has put the GCC project in the position where the have the choices to:
1. Hope the FSF change their mind and prioritise free software ahead of the Cult of Richard.
2. Commit to shipping a sub-par and increasingly irrelevant free software compiler.
3. Drop the CLA requirement.
In the absence of any change on the first point, the third option looks like the best way to ensure that there is still a high-quality, GPL complier available.
Apple and the LLVM developers were contributing to GCC, interacting with the GCC Community and in contact with the GCC Steering Committee. They knew that GCC was lead by the GCC Steering Committee, not RMS. The fact that they supposedly sent one email to RMS, did not follow up with RMS, and did not try to contact any other leadership in the GCC Project is convenient.
You're getting it wrong. He sent mail to the GCC mailing list.
And even if he had sent it to RMS, how would the failure be described as Lattner's choice to "not follow up with RMS"? How could it be accurately described as anything other than the opposite: RMS not following up with Lattner?
Many that contribute due not want such an update to the work they own without reviewing the new licence to see if they agree.
Another solution which other projects use is a requirement that it be licensed to that project, and that project alone as permissive, which has no greater risk than assigning copyright to that project, the project can now relicense the code as it sees fit, but one continue to owns once work and one is free to license it to others how one sees fit, including not at all.
People might argue that it's a stretch (and there'd be some rationale to the argument, although it's ultimately wrong), but LLVM would be aptly considered a split, and it's a split that has had a huge impact.
Lattner begins working on LLVM, a code generator. He and his advisor publish a paper "Architecture for a Next-Generation GCC" <https://llvm.org/pubs/2003-05-01-GCCSummit2003.html>. When he considers this work sufficiently mature, Lattner attempts to donate it to the FSF and get it into mainline GCC, but he gets rebuffed. Apple, who has taken an interest and is his employer by that point, really wants LLVM to be a thing, though, so two years later, they announce Clang and eventually turn out an entire compiler toolchain. It transforms from the original LLVM per se into what people mean when they say "LLVM" today: the work at llvm.org—which, again, all started from what was expected to be a replacement for GCC's code generator.
I'm not sure I understand this idea. Whether you assign the rights to FSF or not, the situation is not different. (For the project) If the employer owns the rights, the copyright assignment is illegal and void - the employee never had the right to do it. It's a bigger hassle for the employee who lied, but gcc would be in the same situation.
"That way they are absolutely sure that there will never be a problem." just doesn't seem correct in that case.
> If the employer owns the rights, the copyright assignment is illegal and void - the employee never had the right to do it
Is that actually true though?
Suppose Alice has a full-time job with HyperSuperMegaSoft. Alice writes a patch to IndependentSoftwareFoundation's FooBolCompiler. When Alice submits the patch to IndependentSoftwareFoundation, she warrants to IndependentSoftwareFoundation that she has the right to do so. Years later, HyperSuperMegaSoft decides to sue IndependentSoftwareFoundation for including Alice's patch in their FooBolCompiler, because they claim Alice never got proper internal approval (under HyperSuperMegaSoft's internal policies and procedures) to submit the patch. Is a court going to invalidate Alice's agreement with IndependentSoftwareFoundation because Alice didn't follow the right internal procedures with her employer? Or will the court decide that IndependentSoftwareFoundation shouldn't be punished for Alice's mistake, that HyperSuperMegaSoft is bound by Alice's actions as their employee even if they didn't approve of them, that IndependentSoftwareFoundation has the right to use the software under the agreement, and that HyperSuperMegaSoft can't successfully sue IndependentSoftwareFoundation (or FooBolCompiler's end-users)–they may still be able to successfully sue Alice for violating her employment contract (although that probably is far less an attractive proposition to HyperSuperMegaSoft than suing IndependentSoftwareFoundation is.)
IANAL so I don't know what the right answer is. (The right answer probably depends on the jurisdiction.) But I get the impression some people assume that HyperSuperMegaSoft would automatically win against IndependentSoftwareFoundation, possibly without having good justification for that assumption.
> invalidate Alice's agreement with IndependentSoftwareFoundation because Alice didn't follow the right internal procedures with her employer?
Internal procedures are not the law. The contacts are. If the contract says her software belongs to the company, then it does. (Unless the country law says otherwise of course)
In the same way I can't legally sell you a copy of Windows license that I totally promise I've got an agreement with MS about. It's not a license I have rights to.
Suppose Alice has signed two contracts, one with her employer assigning them copyright in whatever she develops, and another with IndependentSoftwareFoundation assigning them copyright in something particular she develops. Why automatically assume the former contract legally trumps the later?
Also, employees can act as agents for their employers. Suppose Alice falsely warrants to IndependentSoftwareFoundation that she has her employer's approval to submit the code in question. If an employee makes an unauthorised agreement with IndependentSoftwareFoundation, I don't think a court will necessarily automatically invalidate that agreement just because the employee wasn't properly authorised. It depends on the circumstances.
It is like the case of the employee who buys an expensive dinner on the corporate credit card, and then the employer rejects the expense claim as violating policy. The employer can't refuse to pay the credit card company, or the restaurant, because the employee violated policy. The most the employer can do is fire the employee and sue them for damages. The employee entered into a contract with the restaurant on behalf of their employer, and the employer is bound by the contract even if the employee wasn't authorised to enter into it.
> In the same way I can't legally sell you a copy of Windows license that I totally promise I've got an agreement with MS about. It's not a license I have rights to.
Different situation in a couple of ways. Firstly, you didn't have anything to do with developing Windows. Suppose a Windows developer writes some code and puts it in Windows (under their Microsoft employee copyright assignment) then puts the same code in some open source project (under some other copyright assignment they sign without Microsoft's knowledge or consent). That's the scenario I'm talking about here which is rather different from the scenario you are talking about.
Secondly, Microsoft Windows is famous and if some random person (with no apparent association with Microsoft) tries to sell you a license to it you have good reason to suspect the license is invalid. Some random piece of code a developer writes isn't famous and so someone who receives it doesn't have the same grounds for suspecting it. Courts tend to have more sympathy for people who make reasonable good faith assumptions than for people who assume things that a reasonable person should know are unlikely to be true.
As I said, I'm not a lawyer and I'm not claiming any particular answer here is necessarily the right one. I think it likely depends on the jurisdiction and the specific details of each particular case. I just don't think it is as clearcut as some other people (including yourself) seem to think it is.
What the court decides with regards to damages and similar issues is a bit fuzzy of course.
But the original claim was "That way they are absolutely sure that there will never be a problem." - and for that one, it's obviously not true - it's going to be a problem in the situation I described. It may be a mistake with a good faith assumption, and there may be agreements because it's a trivial amount of code. But it's not going to be "haha, that person did a little bit of fraud, let's ignore it".
> What the court decides with regards to damages and similar issues is a bit fuzzy of course.
It isn't just fuzzy what the court will decide with regards to damages – I think it is also (at least sometimes) going to be fuzzy with respect to what the court will decide as to the substance of the dispute.
> But the original claim was "That way they are absolutely sure that there will never be a problem." - and for that one, it's obviously not true
You can never be absolutely sure there isn't going to be a problem. But you can't be sure there is going to be one either.
> But it's not going to be "haha, that person did a little bit of fraud, let's ignore it".
There isn't necessarily any fraud involved here. The employee may have a good faith (even if mistaken) belief that they are allowed to submit the code to the open source project. The open source project may have a good faith and reasonable belief that they are legally allowed to receive it. In that scenario, neither party is committing any fraud. And if the employer later decides they don't agree with what happened, there is no guarantee the employer will necessarily always win a case against the open source project.
> Suppose Alice has signed two contracts, one with her employer assigning them copyright in whatever she develops, and another with IndependentSoftwareFoundation assigning them copyright in something particular she develops. Why automatically assume the former contract legally trumps the later?
The legal system probably will (and I gotta admit it seems reasonable to me too), because she received consideration for the former contract.
You have to keep in mind that, legally speaking, consideration doesn't have to be monetary. Just because no money changed hands in her contract with IndependentSoftwareFoundation doesn't mean there was no consideration involved.
But there is no a priori assumption that there was any consideration, whereas with the employment contract there is quite obviously, as standard, quite significant remuneration.
So, sorry, but I think anyone will have a hard time arguing against "How could you think you had that left to give away to Party X, when you already took / are taking the money for selling it to Party Y?"
In common law systems, if there is a contract there is consideration. Without consideration (which doesn't necessarily have to be monetary), there cannot be a contract (although you could have some other form of legal agreement, such as a deed or promissory estoppel.)
So, when I presented a hypothetical involving two contradictory contracts, both contracts (presuming a common law legal system) necessarily have consideration, or else you are denying one of the premises of the hypothetical.
It isn't hypothetical at all. The FSF's standard copyright assignment contract includes consideration on both sides – the contributor's consideration is assignment of copyright, the FSF's consideration is a non-exclusive license to said copyright. It has to include consideration on both sides or else it wouldn't be a legally valid contract. (You can still have a legal agreement without any consideration, but then it has to be a deed not a contract; people often prefer contracts to deeds because in many jurisdictions deeds have more stringent formality requirements.)
Another possible consideration the project could offer Alice would be the intangible benefit of having her code included in the project. Those intangible benefits include the benefits to Alice's reputation (she can truthfully say "I wrote part of X"), and also the maintenance benefits of upstreaming code.
Legally, consideration doesn't have to monetary. It can be something intangible, such as a copyright license, reputational benefits, the maintenance benefits of upstreaming, etc. All that's really necessary for consideration to exist is each side has to give something to the other, but usually the legal standards for what counts as consideration are pretty low.
A) rather weird definition of "consideration". One would have thought this means something that can be accepted in lieu of what is given up, i.e. can at least somehow plausibly be claimed to be of equivalent value. But "a non-exclusive license to said copyright" is a strict sub-set of said copyright, so it can only ever be worth less. That's as much "consideration" as, say, "from now on you'll work for me sixteen hours out of every twenty-four. As consideration, I'll let you have the other eight off." Uh, I owned all of my time so far, and now you come out of the blue and want to make me your slave. How is you not suddenly taking a small part of my life "consideration" for taking most of it?
B)ut still: If she does that while already being employed, then she has already signed away those rights to her employer (in [most jurisdictions of] the USA). So she just simply no longer possesses those rights to sign away to any project, whether for consideration or not. Because as an employee, she almost certainly already got consideration (salary) for them. The monthly (or is it still weekly / biweekly over there?) paycheck is just such a humongously obvious proof and reminder of this.
The idea is that discovery of the true rightsholder is a natural byproduct of the copyright assignment process. With the formal process in place, it's much less susceptible to the risk of accidentally accepting code that exists as a work of corporate authorship than it would be if people just start sending in patches and you apply them.
By far the most important reason to require copyright assignment is to retain the ability to change the license at will.
You don't need copyright assignment for the case you mention: you can require that an officer of the employer make the contribution, or that the contribution be in the name of the employer.
IANAL but an employee generally does not have to just contribute work related code. The company has to OK it either for specific contributions or as a blanket policy, but it's opt in.
Then there is a secondary question on whether you contribute the code under a specific license (say Apache 2.0 GPL, etc.) or whether you assign the copyright.
In the former case the code can only be used in accordance with that specific license, in the latter case the code can be re-licensed by the copyright holder.
In either case the company could claim that the employee did not have the right to contribute the code, but (AFAIK) that is independent of a copyright grant vs license grant.
On a radiant note, I wonder what would happen if one used the Free Art License or Creative Commons ShareAlike for code? They're nice and simple licenses, and programming is an art.
Creative Commons explicitly warn against using Creative Commons licenses for software:
> We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available
> Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. Many software licenses also address patent rights, which are important to software but may not be applicable to other copyrightable works. Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software. Existing software licenses were designed specifically for use with software and offer a similar set of rights to the Creative Commons licenses.
It is worth mentioning, that people are unaware that often the code they create after work, in their own spare time is actually owned by their employer.
I think this should be illegal and if employer claims ownership of your time outside of working hours, they should be required to pay accordingly, perhaps with out of office extra rates.
Unfortunately there is not much a poor employee can do against a multi billion company that avoids tax and has more money to spend on lawyers than some smaller countries could...
The question is whether the stuff to be assigned (or not) belongs to the individuals or their employers. An assignment from someone who isn't actually entitled to assign away something (because they don't own it in the first place) is useless.
This is a good thing for the health of the GNU ecosystem, and I hope other GNU projects adopt this practice.
Related story: a couple of years ago, the current maintainer of an Emacs package reached out to me. Apparently the FSF wanted to make it part of the official Emacs distribution, and wanted me to assign my copyright to them. I was happy to do so, BUT: the code was written more than 20 years ago when I was at university, which (according to the FSF) meant I needed to get a copyright release from the university, in a country I no longer lived in and that I had not interacted with for literal decades. This seemed like far too much trouble at that point, so I gave up, and the package never became part of Emacs.
Copyright tends to run from the death of the author for a period (in the US is 70 years after death). As for where it's assigned to an institution, it'll still have a long time to run - decades!
Copyright is either the death of the author plus a period, or a length of time for a non-human entity such as a university or limited liability company.
I really hope other GNU projects, in particular Emacs, follow suit, though I doubt it will happen.
In my experience it is a massive hassle to get the copyright disclaimer from my employers. I'm currently on hold from contributing to Emacs because my paperwork is working its way through the legal bureuacracy of my new employer. Also, I have former coworkers from previous companies who were enthusiastic about Emacs, but unwilling to go through the trouble of getting the paperwork to contribute.
I think getting this paperwork through is probably more difficult in my industry, than in others -- I do R&D at a large pharmaceutical.
Still, I think the copyright disclaimer is one of the biggest factors that is limiting the number and diversity of Emacs contributors. I also think it's unnecessary, as Linux does not have this requirement, and it has successfully enforced the GPL, for example on router manufacturers.
The only GNU project I directly contributed code to was GNU nano. I was probably only willing to do so because it did not require anything like a CLA. But, if this didn't need any bureaucracy, I'd be glad to do so. I personally trust the FSF. Every new version of the GPL came after players tried to circumvent it so, having new updated versions of the GPL prevents players from abusing the right they have when new (legal) holes are discovered. AFAICS, the only institution I'd trust to assign my copyrights to is the FSF. They have proved time and time again to not sacrifice freedom and privacy in the name of profit or convenience.
I am currently sitting on quite a few library improvements in Guile, so many that I forgot most of them but they mostly have to do with XML parsing, that were never upstreamed.
The reason for this is that the process for upstreaming it was significantly more involved that writing it, and also that they require my name and address for it and would intend to publish my name publicly.
Wine also has the requirement for publishing names of all contributors, which the project claims is about “trust”. Even if I were to trust Wine with my name, which I more or less would, I do not trust everyone who sees my name in that public file with it.
> the process for upstreaming it was significantly more involved that writing it
It's not very different from the way things work today, where many projects insist on doing everything through GitHub, and if you aren't on there, then it's a massive PITA. It truly is the Facebook of the programming world, down to how oblivious everyone inside the gates are about anything outside of it. ("What do you mean you can't RSVP because we're using Facebook to do that? Isn't everybody using Facebook?")
I think the FSF is starting to realize that Stallman is not forever, and FSF ethics aren't forever. Having the FSF have exclusive rights to change license terms with "or newer" terms and to hold copyrights to projects is a bad idea as the founders of the FSF are getting older.
I trust the FSF, but I have no idea who the FSF will be in another 20 years.
> They seem to presuppose wise benevolence on the part of whoever controls the license.
I don't have a big problem with the and newer term. Let's imagine three possible scenarios. Note: Copyright assignment is different from an "and newer" clause and it's not the subject of this comment.
1. The new license is more restrictive, e.g. the FSF went full evil, GPL became an "All Rights Reserved" proprietary license. Outcome: everyone will just keep using the current version without an upgrade.
2. The new license is more pessimistic, e.g. the FSF went full pessimistic, GPL became a BSD or a public domain license. Commentary: Doing so will not create direct harms to the existing users. Since the software remains free, I'll simply keep using it. And speaking as a developer, in the very unlikely scenario that the FSF decided to end copyleft, chances are, I'd likely to agree. However, a dogmatic copyleft advocate may point out that it's a potential vulnerability.
3. The new license is similar, e.g. GPLv2 to GPLv3. This is the intended outcome.
There are some reasonable objections, but I don't see it as a big threat, so I have no problem with it.
Some might say that, but it's never been true; it's always been fine to make changes to a GPL program for personal use, without even telling anyone you did, much less tracking down the original author to give the changes to them.
The spirit of GPLv2 is "I give you this source code, if you give it, or a modified version of it, to anyone, you have to (perhaps also) give it to them in a form they can actually use.".
What if the license is more restrictive and large important GPL projects decide to go adopt it and start demanding licenses to use code that everyone contributed for free over the past 10 years?
You can just use the last version of the software released under whatever license revision you prefer. They can't take it away from you! You could also get together with some friends and start a fork based on that version.
For what its worth, the GPL (both 2 and 3) says this:
> The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
> Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
(The GPLv3 goes on to support some stuff about naming a "proxy" to approve new versions in addition to the FSF.)
I'm no lawyer, but I imagine that would prevent glaringly-evil GPLv4 from being upgradable-to.
Calling v3 "similar in spirit" seems like a stretch. I suppose that's literally true, but what they changed was significant enough that it drove a lot of projects away.
v3 prevented people from using patent agreements and hardware restrictions as additional restrictions on top of copyright law. They did drove away people who consider such additional restrictions to be beyond the scope of what a copyright license should be able to address. Linus for example have explained in depth how he consider the restrictions of patents and DRM to be bad and counterproductive to the community, but that he doesn't think a copyright license is the right place to address them.
If a copyright license is the right or wrong place to address restrictions outside copyright law is an interesting discussion to have, but "similar in spirit" seems to match pretty well. I for one do not care if the legal restrictions sit under regular copyright law, software patent law, or Digital Millennium Copyright Act subsection DRM. They are pretty much similar in spirit.
The FUD was much bigger than the actual changes, IMO. I think that everything that v3 banned (using patents or code signing to prevent users from exercising their GPL rights) is something that v2 would also have banned had it been considered at the time.
That comparison makes no sense to me. I found one person making this claim on Twitter and Gentoo bug tracker (plus a couple posts in different languages reciting his quoted claim).
The part about being able to link AGPLv3 code, I'm not sure what is supposed to emphasis. Care to expand?
How is the AGPL a EULA? It's basically just the GPL with the definition of "distribution" tweaked to include interfacing with the specific program over a network.
Interfacing to a program over a network is not an act of copying, thus not controlled by copyright. Therefore, attempting to control such usage falls out of the category of copyright licenses (which the GPL is) and into the realm of EULAs (think "you may use this software with at most two network users" - same story).
I used to think the AGPL was an EULA based on an interpretation biased by how people think the AGPL works. Upon looking into this more closely, I've realized this is most likely not the correct interpretation.
Instead, my current opinion is that the AGPL is just a terrible copyright license that is almost impossible to comply with (most AGPLed projects without copyright assignment violate their own license - if you think this doesn't make sense, what I mean is every contributor violates every other contributor's copyright), while not actually protecting against proprietary SaaSification in any legally enforceable way. I could go into more details, but honestly I've told this story one time too many, so I'll just encourage people to read clause 13, word for word, carefully, and think about what it actually means, not what the FSF has convinced everyone it means.
But without that bit, how do you avoid getting into a license incompatibility quagmire? You can't relicense a large OSS project without tracking down every individual contributor, which is frequently virtually impossible.
If it was merely someone impersonating the FSF, it wouldn't have legal weight. It might cause some confusion for (at most) a few days, but nothing more.
This decision came from the GCC Steering Committee, which has nothing to do with the FSF.
The history of GCC includes a dark period in which version control wasn't public, and the project was dumping release tarballs on the GNU ftp server. Then, Cygnus Solutions started the Experimental GNU Compiler Suite (EGCS), a fork with a much more open development model, capable of attracting contributions from the whole Linux and embedded industry. Within a few years, many Linux distros had switched to EGCS, including Red Hat.
If I remember correctly, talks of reconciliation started after Red Hat acquired Cygnus: other distros were worried that their competitor had gained too much control over a critical component of the OS. Eventually, the GNU developers and the EGCS contributors agreed to merge back under the GNU flag, but keeping EGCS's open development model.
Nowadays, the GCC project is still hosted on the Red Hat-owned Sourceware servers, and its governance body is a technical board of contributors with various industry affiliations: https://gcc.gnu.org/steering.html
TL;DR: the FSF and the GNU project no longer have much influence on GCC's direction.
Not that simple: EGCS was deliberately structured so that Cygnus would not control it; it involved many GCC developers who didn't work for them. The original EGCS steering committee had a non-Cygnus majority. From the very beginning, it was structured in such a way that it could become the official GCC once reality set in. This had nothing to do with Cygnus being acquired.
There wasn't a working Linux libstdc++ from the FSF that anyone could build until EGCS fixed it; no Linux distros that supported C++ ever used an FSF version. They had to use weird hacks built by HJ Lu.
I have vague memories of this time period. It seemed like GCC had stagnated and development wasn't being done in public. Many of the same gripes about extensibility and velocity that spawned the creation of clang/llvm.
The fight that led to EGCS had nothing to do with licensing. It had to do with a broken development process that the release manager wasn't willing to change. About two years of backlogged bugfixes for C++ were in some state of acceptance, but things were such a mess that releases weren't really possible: people got email saying that the bug would be fixed in the next major release of g++ but it never happened. EGCS kept the same licensing policies and also kept copyright assignment in place. Some developers wanted a clean break with the FSF, but most just wanted to get GCC fixed. It was a delicate dance to keep RMS from getting pissed off and trying to shut it down; one selling point that kept him calmer was that doing it the EGCS way kept Cygnus from just owning everything and taking over.
I made no statements about licensing. It was all about updates and developer velocity. Lots of folks wanted to get patches into GCC and the GCC devs at the time were camping on the submission queue. The EGCS fork was a way around that, but a balkanized compiler is kinda like a poison pill, as soon as someone uses a feature in one and not the other, it bifurcates a codebase.
Think of what would have happened if some distros took alternate tooling paths? What about popular tools? We have to have both toolchains on our systems.
It is clear from how things turned out that EGCS wasn't about ownership or splitting the ecosystem. If one were to do this now, you would constantly rebase against upstream while you sort out the politics.
Clang/LLVM was both about implementation architecture and licensing, but had GCC been more modular, it might not have existed as well.
2.7.2 the current for a while then you could manually update to some iffy 2.9.5 release? I never did much c++ in the 90s. 2.7.x was generally fine for c on hpux/Solaris/digital/Linux and maybe os/x?
I am quite certain that when the generations that made this happen are gone, computer world will be back at business as usual like it was in the shareware days.
Doubt it. So many projects these days are made up of multiple corporations and community contributions that I believe open source has basically won out it a lot of places. Things might not be libre like Stallman wanted but open source is here to stay.
Yet most of these run on open source code. That there are thousands of independent actors exploiting, and developing, these tools is one of the reasons open source has been so successful.
Open source has existed since forever on tapes and cards exchanged between university students, programming listings on computer clubs magazines for home microcomputers, source code delivered on the professional version of development tools,...
Nothing new really, unless you want to be pendantic on the real meaning of "open source" as defined by Open Source Initiative.
At the end of the day it won't matter, because those developers have bills to pay so eventually idealism gets replaced with real life.
Shareware is a type of proprietary software which is initially shared by the owner for trial use at little or no cost with usually limited functionality or incomplete documentation but which can be upgraded upon payment.
I don’t trust the FSF anymore, and I think that’s the reason gcc won’t require copyright assignment: they too realize FSF is now tightly coupled to enabling abusive behavior
The whole idea of a foundation is that it shouldn't matter that the founders age and pass away, isn't it?
And "who the FSF will be in another 20 years" is down to its statutes. Presumably the board has a duty to follow those, including (s)electing successors for themselves who also will do so.
>I trust the FSF, but I have no idea who the FSF will be in another 20 years.
The FSF has proven itself to be a cult incapable of moving on from or existing without RMS, so the simple fact is that, like all cults, it will die when he does. Luckily, the FSF does not embody Free Software, and the greater movement doesn't need either to survive.
With the copyright assigned the owner of said copyright can release the code under any license of their choosing.
Some dual license open source projects do this, the organization requires the copyright assignment and hence they can release the code under an open source license and their own closed license. License changes here are perfectly OK (legally at least).
Interesting cases are those without a copyright grant. Now you allow the group to only produce copies and releases in accordance to that specific license. License changes now are questionable. Can you relicense Apache 2.0 as AGPL? BSD as Apache 2.0? (Without owning the copyright, my guess in both cases is no.)
Given three plus decades of FOSS experience, are the fears of permissive licenses like MIT and BSD (that companies will take, fork, and not give back in a meaningful way which will kill open source) considered to be well-founded? Could Linux not be as pervasive and important as it is today had it been released under a BSD license?
You're talking about a completely different thing here though than the article is about, and obviously we can only speculate.
Linus' opinion always was: "I give you source code, you give me your changes back, we're even."[1] That's his summary of GPLv2 and I think such an attitude is reasonable, and it might have certainly aided the Linux kernel development over time (almost sure of it).
He disliked the GPLv3 exactly because of that. Because in his opinion it's (paraphrased) "I give you the source code, and now I dictate to you how you are allowed to use it." (see same link).
Whether a BSD/MIT license hurts or helps a project is pure speculation. More permissive licenses might make code reuse more attractive, and be considered "more free" regarding code reuse. As to what code contributions you miss out on? Hard to judge. There definitely are companies building products utilizing FreeBSD / OpenBSD without committing all their changes back (or none to begin with).
Pick the right license for your project. You don't care and are happy if someone uses it? Use a permissive license (MIT/ISC). You want to develop the product, improve on it, and want the changes back? Use something like GPLv2. You deeply care about your code running on open devices? Use GPLv3.
There's no "one obvious right way" as far as I am concerned.
GPL doesn't require upstreaming, only that it's available. Lots of hardware companies don't want their code in the mainline kernel and make no effort to make it fit in. There are huge masses of Linux kernel code out there that can't be upstreamed because the kernel developers wouldn't touch it with a ten-foot pole.
> GPL doesn't require upstreaming, only that it's available.
While the GPL doesn't require upstreaming, it does require that derivative works that are distributed to users must make sources available. If those sources are available, then users or project maintainers can choose to upstream those changes if they want to.
Apple, Sony, Nintendo etc don't make those source changes available despite distributing derivative works to users, so users and project maintainers can't upstream changes even if they wanted to.
The poster is making the distinction between working to merge your changes upstream and just dumping your changes on an unsuspecting world.
The latter occurs decently often in the Linux Kernel world, and if there isn't much desire for the changes they can technically exist but never get merged.
Whereas there are other drivers where the only one that cares about them is the company that uses them, but their developers have worked to get it actually upstreamed and help maintain it.
Clang/LLVM was created by apple, and Netflix upstream's to FreeBSD...but google and microsoft to linux? And no don't tell me Microsoft works on linux, they try to integrate it into the windows "ecosystem".
The LLVM project started in 2000 at the University of Illinois at Urbana–Champaign, under the direction of Vikram Adve and Chris Lattner. LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages. LLVM was released under the University of Illinois/NCSA Open Source License, a permissive free software licence. In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systems. LLVM is an integral part of Apple's latest development tools for macOS and iOS.
Apple chose to develop a new compiler front end from scratch, supporting C, Objective-C and C++. This "clang" project was open-sourced in July 2007.
It was created, but now it is good enough for their Objective-C/Swift/MSL purposes, to the point everyone's wondering why clang is so behind in C++20 support.
Apple is perfectly willing to maintain, say, Swift and LLVM as Free projects; but they also have a proprietary fork with extra bits exclusive to their own hardware. For example, their proprietary GPU drivers compile shaders with it. LLVM being permissively licensed and owned by them means they have no reason to release those bits.
This is not a hypothetical problem; it causes real harm to downstream users of LLVM. Rust has to support the current version of Apple's LLVM fork as well as the LLVM they ship with specifically just so you can compile watchOS apps, since that platform requires a proprietary bitcode format Apple never documented and only supports in their proprietary fork.
Had Apple stuck with GCC they wouldn't have the legal ability to do this. Even if they had used GPL on LLVM, that license alone means that any contributions they take would also bind Apple to the same license. That's why people are extremely apprehensive about CLAs, because they're basically one-sided. The project vendor is free to sell exceptions or maintain proprietary forks, but you still have to comply with GPL.
Even if Apple had basd their watchOS toolchain on GCC, and had published the source code for it, it is quite likely that their fork would have remained separate to upstream: upstream might not care about watchOS support, and Apple's fork might be based on an old version of GCC. In that case, Rust would still have to support two versions.
> proprietary bitcode format Apple never documented and only supports in their proprietary fork
IIRC, the bitcode format isn't proprietary—it's part of the open-source LLVM. The only issue is that it's not a stable format, so they need to use Apple's LLVM version and not an earlier or later open-source one.
>Rust has to support the current version of Apple's LLVM fork as well as the LLVM they ship with specifically just so you can compile watchOS apps, since that platform requires a proprietary bitcode format Apple never documented and only supports in their proprietary fork.
I'm not sure I follow. Apple's LLVM fork could open source and Rust would still have to support two LLVMs if the WatchOS code wasn't upstreamed. Apple has no responsibility to upstream code on the GPL, nor do the LLVM maintainers. Given that Apple's bitcode would be proprietary / undocumented (GPL doesn't require you to document your code), it would take a dedicated individual to make sure the two projects are in sync. If Apple isn't doing that now, I'm not convinced they would do it under GPL.
Rust has it's own (Free) LLVM fork, too. If the watchOS/iOS Bitcode format were Free, they could merge that into their own LLVM instead of having to support two slightly-different compiler backends.
The GPL would legally require Apple to publish source code for all LLVM forks they make, if they accepted third-party contributions under GPL terms. It doesn't require them to upstream it anywhere, you just have to let someone else do it.
As Apple own it anyway, what difference would releasing it as gpl make?
They could still do as they like, as it’s theirs. Do they accept significant code from the community?
This is why I find the “use agpl” claims about projects run by a company disingenuous- they’re using the licence restriction to prevent competition while they have the freedom to offer “enterprise” editions however they wish.
Apple licenses their software as Apache 2 so a CLA isn't necessary, everyone is free to make proprietary forks.
Companies that want to release software as GPL but also sell exceptions or make forks either cannot accept third-party contributions (as then they'd be bound by the contributor's derivative copyright interest in the code) or have to require contributors sign CLAs.
Projects with distributed copyright interest and a copyleft license governing all of that, like the Linux kernel, practically cannot relicense or sell exceptions. That's the power of the GPL: everyone has to contribute on a level playing field.
You’re missing the question I asked though. Does Apple accept significant code contributions from outside the project?
Because if they don’t, the gpl wouldn’t help.
But regardless of that - I think this is the perfect example of the copyleft crowd not understanding the concept of compromise.
Apple creates something, releases it as open source but also maintains some private extensions, and the response is: well why didn’t you give it all to us?
I guess that depends on definitions of "pervasive and important" more than it does facts on the ground.
To my eyes, the number of open source drivers (near zero) available for Apple hardware, developed to run on their BSD-licensed kernel, pretty much provides all the evidence I need.
No, a BSD Linux would have long since disappeared behind the curtain of some tech giant or another, just like Mach did into NeXT/Apple.
Though binary blobs are a thing, albeit a somewhat controversial thing.
Assuming a BSD-licensed Linux is a fairly small step away from assuming that Linux didn't exist given the existence of various BSD Unix flavors. And most people I know feel fairly strongly that, in the absence of Linux, BSD Unix would have come to the forefront.
Why do they feel that way? It is debatable they would have finished, gotten the same press vs one guy who did it and without requiring changes back development might not have been able to keep up.
Linux largely won out over the BSDs for various reasons that may (or may not) have included the license. I personally think Linux would be roughly where it is even if it used a BSD license.
And in the absence of Linux entirely, most people I know consider that one of the BSDs would have been rallied around because there was just too much market demand for an open source *nix operating system.
Service providers were already using the BSDs in the dot-com buildup when Linux wasn't quite as far along.
For anyone interested, here's a debate between Bryan Cantrill and Steven J. Vaughan-Nichols I recorded last year on the topic "If Linux didn't exist, would we have had to invent it?"
There has been a lot of talk lately about big cloud companies using open source projects and forking them privately. I think the principles of the FSF are becoming more and more relevant, not less.
People considered the GPLv3 excessive. Now we see tivoization everywhere, and people cries because corporations are soooo evil. Well, maybe you should not use licences that let them do that. People who think the FSF is too idealistic are missing the point - the FSF is terribly realistic, it's the ones who don't care about software freedom who end up learning the hard way why the FSF exists.
Yes, they are well-founded as has been shown time and again. But the article is about copyright assignment, not changing the license. The debate around copyright assignment is whether there's any need/benefit to have a single entity 'own' all contributions vs. the individual contributors retaining ownership. There are a couple of big downsides to copyright assignment in that there's a longer term risk that a malicious actor will gain influence on a given project and change the terms going forward which has a tendency to drive potential contributors away. This has happened with various partially-open source (dual license, open core etc. types of projects) projects over the years.
BSD Unix predates Linux by 10-15 years. Personal computer versions were roughly feature comparable around 1992 (when I made my "should I install Linux or 386BSD" decision; Linux had shared libraries, 386BSD didn't).
A big advantage for Linux in the early 90s was better support for cheap hardware.
FreeBSD back then did not want to install on my PC. First problem was that I had an IDE CD-ROM and they only supported SCSI CD-ROM.
Second problem was that it would not install in the unpartitioned space on my DOS/Windows SCSI hard disk.
Linux supported IDE CD-ROM and could install on the same disk as DOS/Windows.
Result: I installed Linux, and have used Linux ever since then when I need a free Unix-like system.
According to their forums, there was no IDE support because nobody would seriously have IDE on a server. At the time you could make a reasonable case for that for hard disks, but not for CD-ROM (especially since IDE CD-ROMs were around $100 and SCSI CD-ROMs were around $400).
The disk sharing limit was because they didn't think you could reliable infer the cylinder/head/sector (CHS) to logical black address (LBA) mapping that the other operating system(s) on the disk used. (The standard PC partition map at the time specified everything using CHS addressing, but disk interfaced had moved on the LBA addressing. Someone had to make up a pretend geometry for the disk, and then everyone had to consistently use that mapping to convert between CHS and LBA).
In theory, you probably could find a legal partition setup with free space that was unsafe for another OS to use due to ambiguity of the mapping, but in practice that did not happen.
> Linux supported IDE CD-ROM and could install on the same disk as DOS/Windows.
Linux went beyond "could install on the same disk as DOS/Windows". Linux could install on the same filesystem as DOS/Windows. No need to repartition, no need for unpartitioned space. If you later decided Linux was not to your liking, you could simply erase your Linux directory.
Result: I installed Linux on my C: partition, choosing a distribution which came with UMSDOS support. Some time later, I noticed that I rarely booted into DOS/Windows anymore, so I moved everything from the D: partition to the C: partition, erased the D: partition, and reinstalled Linux on that free space (using ext2 instead of UMSDOS). I have used Linux ever since then.
There was also the lawsuit around BSD [1] which was only settled in 1994. I remember that uncertainty about the legal status of BSD lingered for a few years after that. I think Linux picked up a lot of steam from users and developers who wanted a unix on their PCs and were scared to touch BSD.
One thing I noticed is that early BSD developers almost all moved on to work on proprietary derivatives like SunOS, BSDi, NetApp, NeXT/MacOS, etc. Yet early Linux developers have kept contributing to Linux for decades, possibly because their expertise can't really be proprietized.
Because the GPL works for non cloud software and does not work for cloud software. You would have to change the license rule from “in order to redistribute code based on a derived work from the covered work” to something like “in order to run code based on a derived work” which would be pretty broad. Maybe couldn’t keep you own kernel version on your own laptop without sharing the code with any people you do business with. And even then, Google and Aamazon can probably just rewrite / reverse engineer back to the stable interfaces people are using. So humanity will not really benefit in the long run from the wonders that they are developing.
This may help contributors, but makes difficult to change the license in the future. I guess this the main reason why FSF requires copyright assignment to them. Now that this is no longer needed, I really hope that the world will not need anything newer than GPLv3.
> makes difficult to change the license in the future
Copyright assignment is certainly a flexible way of doing that. But, if all you want is to upgrade GPL, it's completely unnecessary. As most GNU projects are licensed under the "with newer" clause, everyone, including GNU, can redistribute it under a new license unilaterally, without a copyright assignment - which, I suspect, makes a good argument to stop the copyright assignment requirement.
Another important argument for copyright assignment is to allow centralized GPL enforcement. If a bad faith actor appears, the project can make the strongest legal defense. In my opinion the whole system works to enable this, e.g. the FSF also requires you to get the copyright disclaimer from your employers, otherwise the strength of the legal defense will be weaker.
Unfortunately, for multiple reasons, a huge enforcement action is an extremely rare occurrence (the last, and possibly the only one, was the Cisco WRT54G case), and allegedly, some projects like the Linux kernel are even against active enforcements due to conflict of interest, thus, although I support active GPL enforcement in principle, based on the historical records I cannot say copyright assignment is all that useful (although I wish it would be). Moreover, the license enforcement model by the Software Freedom Conservatory showed centralized enforcement without copyright assignment appears practical [0] - all of these, I suspect, also make a good argument to stop the copyright assignment requirement.
>The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
>Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
>If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
>Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
This was addressed on the mailing list: changing to future versions of the GPL will still be possible, due to the "or any later version" wording. It's only changing to a non-GPL license that will now be impossible.
Isn't the "or any later version" clause super dangerous? What if a party somehow takes over the FSF and publishes a GPLv4 which is completely permissive? This seems like a time bomb. Am I misunderstanding something?
It's a real risk. You have to weigh that up against the possibility of someone finding a loophole in the GPLv3 (similar to what TiVO did with GPLv2, where they granted you a copyright license but used code signing to stop you actually making changes to the code on your device) that's patched in GPLv4, and your GPLv3-only code is incompatible with the GPLv4 so anyone who wants to use it in GPLv4 projects has to rewrite their own replacement instead.
You can define a proxy since the GPL3. This is what we are doing at KDE so if a GPL4 appear, to apply to most KDE project you will need a vote of the KDE e.V. membership on it.
Off topic but reminds me, I wonder if copyright assignment or trademark assignment (if it applies) would have helped freenode. In the sense of helping it stay as it was, a friendly place for users and project maintainers.
I'm somewhat surprised to hear that many GNU projects have copyright-assignment policies in place. That seems to go against what I used to think the FSF was all about. But after watching videos of Linus on GPL v3, it seems that the FSF is all about exerting control, despite having "Freedom" in their name.
Given they use GPL-x-or-later licenses and are all the authority needed to designate something as GPL 4 or 3.1 or whatever, if they wanted to go evil to utilise their control they already could have.
It's not like they're opposed on principal to new license versions to benefit specific projects either, e.g. GFDL 1.3 has the "Wikipedia can relicense to Creative Commons" exception
The key difference to me is the “or later” part. So even if the FSF releases an evil version 3.1 or whatever, everyone could just continue to use version 3 instead. Whereas if the FSF owns all of the intellectual property, they can relicense it in its entirety to strictly 3.1.
If the evil version 3.1 is more restrictive than previous versions, then you are right to say people could just ignore it. However, if evil version 3.1 is more permissive, for an extreme example say they changed it to a verbatim copy of WTFPL, then there would be nothing stopping people from creating a proprietary fork of the project, the very thing copyleft was designed to prevent.
Would they be in breach of contract if they did so, or would some other legal recourse exist?
The licence explicitly says: "The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns."
A non-copyleft licence would not be similar in spirit.
I could certainly imagine some proprietary code loving coalition seeking to control the FSF after RMS's eventual demise, so that they could create a new, non-copyleft licence.
GPL 3 is aware of such concern: it says, "If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program", apparently trying to provide an alternative path to allow Linus Torvalds to accept only the versions he wants to accept.
There's nothing stopping the next release of an application that has historically been GPL 2 or later being released as GPL 3.1 only, however? They can't go back and take back the existing licenses to existing versions (the whole non-revocable term of the license) so other users can still give you those versions under those licenses even if the FSF decided they didn't want to themselves.
The following is crafted deliberately as something of a worst case scenario; I don't think it is even remotely likely.
So GCC is 3.1 or later. RMS dies and Google, Facebook etc get in control of the FSF: after all, they are major contributors and beneficiaries. While this is going down, fearing the badness around the corner, the GCC project continues work on GCC under 3.1 only (and attempts to stop it, unsuccessfully). The FSF releases 4.0 which is a long and wordy version of 3 clause BSD.
Google now forks the latest version of GCC before the project relicensed it. There are two versions continuing: Google GCC under GPL4+ and GCC GCC under GPL3.1. The community doesn't entirely know which branch to contribute to and amidst the mire all the new features of C++30 get added to a proprietary fork of Clang. In general, free software gets regarded as dusty and old and most development happens on compilers people bought.
I don't understand why your original comment was flagged. I went and watched one of the Q&A videos from Linus Torvalds you mentioned and it was very educational. Thanks for your comment, even though the HN comment cancellers hated it.
I think you're on the right track, they just view protecting the FSF as something that needs to happen regardless, and it can therefore be relied on. Then if there's a horrible flaw with a previous GPL, they can at least force their projects to the new version.
To anyone wondering, pretty sure "Linus talking about GPLv3" here refers to Linus at Debconf in 2014 https://youtu.be/5PmHRSeA2c8?t=2840(from there to 56:51 it's about open source licenses)
There are libertarians and anarchists who think that freedom is having no laws at all. But what happens when a huge chemical company starts dumping waste on your lawn? Who do you call? They are free to do what they want, aren't they?
Individual liberties can only go so far. If we want freedom as a society it is necessary to restrict individual freedom at the point that it begins to affect the freedoms and rights of others. In practice that means, unfortunately, governments, police and armies are necessary.
Permissive licences are idealistic. Copyleft/FSF-style licences are pragmatic.
I think your point is that copyleft creates extra value because those extending it are incentivized to contribute their extensions. But in the case of gcc as compared to llvm, permissive licensing looks to be at least as successful. An issue with copyleft that you need to commit to providing the source beforehand. If you are allowed to choose afterwards, you don’t need to ask in advance, and it’s easier to make the case that upstreaming your patches is in the organization’s best interest.
And yes I know copyleft only requires only providing code to your users, but in practice the organization assumes that means the distribution can’t be enforced.
But when they start dumping it on the common meadow behind your property, or the street in front of it, you can't do shit because you don't own those... And libertarians only believe in a legal system sufficient to protect property rights and nothing else. They should call themselves selfitarians, because what they're all about isn't "liberty", but selfishness.
The concern is that in a legal dispute, the FSF might not have legal standing (I.e. in a lawsuit) if the code had been contributed by and remained the property of someone else. And what if that person could not be found.
I wrote the blanket assignment back in 1989 or 1990. I still consider this a legitimate risk.
One could see this in action in the Hellwig vs VMWare court case (one of the few GPL court cases).
As a first step they had to show that Hellwig had made changes to code that VMWare uses that can be copyrighted. Especially difficult since every line in Linux is modified by a few different people. They failed at that and that ended the lawsuit if I remember correctly.
The copyright assignment policy dates from very early in GPL history, when it was broadly thought that in order to make copyleft work the FSF was going to have to sue entities that had misappropriated GPL software. Doing that is harder when you start from a position of having to prove that you even own the relevant copyright in the first place.
It turns out this didn't happen. People who want to use free software and to stay legal just... honored the license. People who didn't want to do so used other software. And the only people who actually were breaking the license turned out to be tiny fly-by-night operations in parts of the world where copyright litigation wasn't a very useful tool anyway.
The GPL has been regularly violated by huge multi-billion dollar corporations.
But the FSF has had a policy of favoring compliance and forgiveness over punishment, and they've aggressively avoided litigation-- instead preferring to negotiate for compliance with goodwill loss as the threat-- to the point of contributing to some splits in free software. E.g. this is a point of disagreement between SFC and FSF.
They don't disagree on the general ideology, at least on paper, but when it comes to enforcement actions SFC is much more prone to litigate than the FSF.
IIRC FSF has only sued once, conservancy has like 100x the rate of lawsuits per years-existed. :P
Compliance and forgiveness is probably the best policy anyway: courts will consider intentions. Companies that are sued for a violation and can tell the judge "look at the evidence: we have a history of doing the right thing and messed up in this one case" get a tiny slap and continue one. By having a reputation of make right and we won't sue companies have nothing to lose by making right. By having a history of suing they will win some cases, but many of them the total gained will be less than laywer fees because of all the companies that are able to say "we tried to make right but they rejected this reasonable offer".
Also, what if a company decides to ignore the GPL and pay up? The courts and law understand monetary damages. The FSF runs the risk of the judge deciding that the code is already out there, and the value the code is $X: therefore the infringer should reasonably buy a license for $X and doesn't have to give source code back. This would violate the spirit of the GPL, but would fit the letter of the law.
But the fact that the FSF hasn't in fact litigated isn't by itself a reason that preserving the clear ability to litigate isn't useful. We don't know how many cases an infringer was made more likely to come into compliance by the fact that work had clear ownership, particularly because the FSF has avoided litigation when they had other avenues open.
The FSF only needs some of the code to litigate though. It is better own everything, but that only is a factor after the case is done, if the FSF owns 20% of the code, then they get 20% of the total possible value of the infringement. (likely after lawyer fees, and class-action can apply)
It is easier if they own all the code, but it isn't required.
> It is easier if they own all the code, but it isn't required.
It's not that simple. For joint works any single author can grant rights to the entire work. Do you know what the caselaw is regarding joint works as applied to typical FOSS projects? I don't. But I suspect it's less than crystal clear (see, e.g., https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2999185) and therefore creates significant risk when attempting enforcement. Litigation is costly, and a wrinkle like this could potentially be exploited by an infringer to drag out an enforcement case for many years.
> For joint works any single author can grant rights to the entire work.
That doesn't sound right - why would anyone ever contribute to a joint work if the other author can sell it to a publisher on their own? Wouldn't they then just take all the royalties and leave you with nothing?
3) Joint authors in the business of commercializing their works (as opposed to accidental joint authors) would usually have a contract between themselves controlling licensing.
4) If it doesn't sound right, that's exactly my point. Copyright law is more complex than discussed on internet forums. Just because something doesn't make sense to a non-practitioner doesn't mean it's completely senseless to a practitioner. Corporate lawyers are often much more risk averse than law professors counseling FOSS advocacy organizations. But as mentioned by the previous SSRN paper I linked[1], joint authorship is typically considered to be detrimental and even fatal to the objectives of many FOSS licenses, which usually assume a model of distinct, serial contributions creating derivative (not joint) works.
The UK also has joint authorship. The test is slightly different, though I'm not sure how much of a difference it would make in the context of FOSS. See Elena Cooper, Joint Authorship in Comparative Perspective: Levy v. Rutley and Divergence Between the UK and USA, http://eprints.gla.ac.uk/100708/7/100708.pdf
To be clear, I'm not trying to say that all or even any FOSS works are or should be considered joint works. Just that the possibility could be a concern for lawyers contemplating enforcement. Certainly in other areas where you often see informal cooperation in the creation of collaborative works, such as in music, the issue absolutely does come back to bite people.
What about arguments like "the code the FSF owns isn't what I infringed?", or "the FSF doesn't own the code because this other developer wrote this bit and isn't a party to the suit; let me call them as a witness"?
I mean, it's true that you could still win a case having to win those arguments, but it's harder.
Defense in depth isn't just a computer security technique. Any lawyer will tell you that the easiest argument to win is one that can't be brought in the first place.
> Also, what if a company decides to ignore the GPL and pay up? The courts and law understand monetary damages. The FSF runs the risk of the judge deciding that the code is already out there, and the value the code is $X: therefore the infringer should reasonably buy a license for $X and doesn't have to give source code back. This would violate the spirit of the GPL, but would fit the letter of the law.
IANAL but I don't think it works that way. They could pay up $X for damages and even get their license revoked. They still don't buy a license to perpetually violate the GPL.
Perhaps. I wouldn't be surprised if their license was revoked. I wouldn't be surprised if the courts assigned a value to the license and told the FSF to accept that.
There isn't much case law here. It will probably end up in appeals for years. In the end it doesn't really benefit anyone to take their chances in court.
right. courts have a lot of power which they will use if they decide someone is being unreasonable. I'm not making a prediction of what the courts will do. There isn't enough case law to be sure (and nobody really wants to chance it so there probably never will be)
Isn't there any case law for license violations in general? For the purpose of this discussion this is just yet an other license violation, not necessarily tied to the GPL.
Paying damages for copyright infringement doesn't entitle one to infringe in the same way paying restitution or damages for auto theft doesn't entitle one to keep the car.
Also statutory damages for willful infringement are very high As much as 150k per work which again still doesn't grant you a license.
This seems to imply copyright assignment to the FSF is _required_ for GNU projects? I wonder what RMS's take is on a unilateral change like this in one of the highest profile GNU projects?
This may not be the FSF stance, but I can think of 3 reasons.
The main one is it is easier to change the license if you want to.
IANAL so I'll probably mess up these next two, which I believe are more theoretical than anything in regard to software. At least in the US.
It is possible for a copyright holder to revoke a license. so there could be an important contribution living in the code base and then one day the author could revoke the license and they would have to remove the code, and somehow prove their replacement was not infringing.
There is a concept of Joint Authorship. Where it could be possible for a contributor to claim joint copyright over the entire project, and then release it on their own under any license they want. I could be wrong, but I believe it has happened where book editors that didn't have an air tight contract, were able to claim joint copyright over a book they edited, and release their own versions with a different publisher.
"It is possible for a copyright holder to revoke a license. so there could be an important contribution living in the code base and then one day the author could revoke the license and they would have to remove the code, and somehow prove their replacement was not infringing."
I don't believe that is true. A license is a contract; there are only two ways to revoke a contract: if the contract is illegal or if the contract provides terms to let you revoke it. If you publish software under the GPL, there is no way to revoke the license.
You could stop supporting the contribution in the code base and release alternate versions under different licenses, but the versions in the code base under the GPL remain available under the original terms.
The third is specific laws having specific terms that supercede the contract, e.g. discharging contractually obligated repayments in personal bankruptcy
Nonexclusive licenses granted without consideration are by default revocable. Fortunately, GPLv3 section 2 explicitly states that it is irrevocable.
GPLv2 omits such language, so to make it irrevocable you are going to want to find consideration. You can probably whack it a few times with your promissory estoppel stick hard enough to get some consideration to bleed out of it.
That's probably good enough to get irrevocability.
This is a good example of how to not steer a FOSS project. Seriously, what was the steering committee thinking? I mean, I tend to agree with this decision, but do they honestly believe that just announcing such a big change without any public discussion beforehand is going to fly?
This doesn't change anything for anybody except the copyright holder (who, if you've signed a copyright assignment statement, is not you). They're allowing contributors to maintain copyright over code submitted to GNU projects, and if you want to assign copyright to the FSF, you still can. The COS (a form of CLA) still grants the FSF the right to redistribute the code under GPLv3, so it doesn't affect users, either. I don't really know what a public consultation would have done here.
Because almost always the employer owns their employees work product, you're going to end up with large swaths of GCC code having various megacorps being the exclusive copyright holder; potentially creating even more opportunities for Oracle v. Google like litigation over compliance minutia regarding code that is supposed to be freely available.
Well, this is a problem that FSF created. They tried to unilaterally appoint RMS to the steering committee and were forced to renege when most of GCC's top contributors threatened to walk away from the project.
If they didn't get rid of the copyright aggreement there would have just been a fork or those people would have gone to work on other projects.
> Well, this is a problem that FSF created. They tried to unilaterally appoint RMS to the steering committee and were forced to renege when most of GCC's top contributors threatened to walk away from the project.
Do you have a source for this? The story appears to be the opposite - RMS was on the steering committee list since 2012 and was removed earlier this year by the rest of the steering committee as a reaction to RMS being put back as a FSF board member. https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html
You cannot discuss things like this beforehand? You cannot do an RFD in the mailing list to gather feedback and questions? Even the announcement is sloppily written, because it sounds like gcc will now be licensed under GPLv3 exclusively (and not GPLv3+). This was later corrected in the thread, but confusion like this could have easily been avoided.
The most current version of the GPL is GPL v3.0. GCC specifically and somewhat controversially updated to GPLv3 when it was released. The version of the license that applies to GCC is GPL v3.0. There is no mythical GPL v3.1 or GPL v4.0.
The announcement specifically stated that GCC "will continue to be developed, distributed, and licensed under the GNU
General Public License v3.0." Until there is a revised license the "or later" is moot. One does not "continue" a policy that is a change in policy.
If this is the biggest complaint about the announcement, I think that the GCC SC did an excellent job.
The issue is that in many places (for example New York State), work done by a professional employee actually belongs to your employer. A developer can write code, contribute it where they want, and license it as they wish. But the code is actually owned by their employer. Which means that if there is a future problem, the employer can assert their copyright interest and people who thought that they had the right to use that code, suddenly don't.
Because developers themselves are seldom aware of such rules, the FSF took the ultra-safe approach of requiring employers to sign off. That way they are absolutely sure that there will never be a problem.
However other open source projects have found that, in practice, problems are rare. And when there is a problem, the employers usually will agree to the license.