HenchmenResources writes "Late Wednesday a posting from Linus Torvalds appered on the the Linux Kernel Mailing List. In it Linus states that the Linux Kernel will remain under the GPLv2. Types Linus,"The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the
actual License itself.""
This discussion has been archived.
No new comments can be posted.
GPLv3 hasn't even been released yet. The public discussion on what it will be
like only started a few days ago. And yet Linus seems to be categorically certain
that he won't even consider using that license? There must be a lot of bad
feelings between him and the FSF (not that I couldn't understand this from
some of the recent events, but I always thought Linus was a very
diplomatic and friendly character who would not be easily offended).
What is that thing about developers having to turn over their private keys?
I don't think anything that stupid is even considered for GPLv3.
I wish there would be a rational and friendly discussion. Is that too much?
Have we come thus far?
Linux is licensed under GPL v2. In order to move to GPL v3, v4, v99 etc, EVERY SINGLE CONTRIBUTOR must accept this. Practically impossible.
Yeah but that is not the reason Linus is giving. He doesn't like it (and he mentions that bizarre private key issue as a reason for that), and so he doesn't even get to the point where he starts wondering whether it would be practically possible to change licenses. At least that's the way I read his post.
The article you linked to didn't say that Linus has no problem with DRM in the kernel. It said that he has no problem with people using the kernel for whatever purpose they like, which is a vastly different viewpoint.
It sounds like his gripe with the GPLv3 is that it is imposing restrictions on what modifications or contributions can be made, which is not the same agnostic view as in previous versions.
The idealist (RMS) and the engineer (Linus) are definitely at a point of contention on this issue...it'll be interesting to see what happens.
Nope! That's why copyright problems are so much more of a concern for the Linux kernel than they are for, say, HURD (because for HURD the copyright has to be assigned to the Free Software Foundation).
It's also why the Linux kernel is much more popular among developers than HURD (because people and companies can contribute to it and still keep their copyright).
No, my statement is true: Philosophy does not yield code. People yield code. I was replying to the statement that the Linux kernel is more popular with both individuals and companies because it is more flexible (from a copyright standpoint) than HURD. This is the same reason why *BSD is popular with some people and companies -- they're not bound to the more restrictive GPL.
No, your statement is not true. Your statement said:
"Which is why HURD will never see the light of day in any substantial fashion. Philosophy doesn't yield code."
If you simply want to argue over the semantics of whether or not philosophy yields code or people yield code, read no further; I have nothing to say to you. The point of this post realtes to substance, not semantics. (And before you stop reading, ask yourself this: what is philosophy without people?)
Your second statement is clearly a generalization you're drawing from your first, and in incorrect one, at that. As GP alluded to, the GNU in GNU/Linux is all the utilities you use on the command line, up to and including the command line itself, and is under the copyright of the FSF. I haven't done recent SLOC counts on GNU vs. Linux, but I would be surprised if they weren't at least comparable - I'd expect that GNU actually has produced substantially more source code (that is used all the time by all manner of users and developers) than the Linux kernel itself these days. Back in 2002 [dwheeler.com], RedHat 7.1 was studied and though the kernel was the largest single body of source (~2.5 million lines), there are GNU programs all over that quickly outstrip the kernel in sheer volume of source: gcc alone is huge (~900k lines), but emacs (~600k lines) and glibc (~600k lines) are both quite large as well. Those are only three GNU programs, the directory of FSF software [fsf.org] contains (as an estimate) hundreds, including the Hurd itself.
Indeed, philosophy is a manner of viewing of the world and is expressed not by some abstract theoretical paper you write, but in how you choose to live and contribute your work to others. In this sense, philosophy is very much responsible for yielding code - do you honestly think that without the philosophical buy-in of its contributors, free software would be anything today?
> People yield code. I was replying to the statement that the Linux kernel is more popular > with both individuals and companies because it is more flexible (from a copyright > standpoint) than HURD.
No.
Linux is more popular than HURD because at certain critical points in history it was "working" and "ready" for definitions of "working" and "ready" that could not really be applied to HURD at the time. Basically, Linux was in the right place at the right time. HURD never showed up to the party, and there was a licensing lawsuit connected with BSD at a particularly critical point in time which left it just a little behind in just the wrong ways at just the wrong time, allowing Linux to get "ahead" in terms of mindshare and popularity in the developer community. Consequently, there was a several-month time window, at a particularly important time in history (right about when a lot of college undergrads were first getting net access) when if you wanted a freely-available, freely-modifiable, freely-redistributable operating system, Linux was _the_ obvious choice. That gave it a leg up, got a lot of people involved with improving it, and made it the leading and most popular free OS. Nothing has yet managed to unseat it from that position.
Just to be clear, I'm not saying that the FSF's policies haven't hampered HURD development. They likely have. What I'm saying is that that is not the key important reason why Linux is ahead of HURD (both in terms of popularity and development cycle). The key reason is because Linus had working, usably complete code at an important time when the FSF (in terms of a kernel) did not.
If the timing had worked out differently, the HURD might have been in the leading position, in spite of the FSF's (admittedly rather strict) copyright policies. It is notable that a number of the FSF's *other* projects, despite said policies, are leading implementations in their respective niches, because those projects were finished to the degree they needed to be and working to the degree they needed to be when they needed to be. Emacs for instance was there enough and working enough (for _most_ of the folks who wanted an Emacs, albeit not for Lucent) that XEmacs is just another, somewhat less popular alternative, rather than completely eclipsing Gnu Emacs as Linux has done to HURD.
Don't contributors assign copyright to some type of Linux foundation?
No. Linux kernel contributors retain their own copyright. This is frequently considered to be a good thing, as it means that no single group has copyright over everything, which means that no single group can change the license to e.g. BSD and start selling a proprietary version of Linux.
The FSF does require that for its code, but Linux and a lot of other projects don't. It's not always bad, though. While it's harder to change the license, you don't have to trust whoever you're assigning the license to to not sell out.
At least with the FSF model, it's not 100% trust based; at least last time I checked they do sign a contract with the assigner saying that they'll distribute the code under a free license or the copyright reverts, or something along those lines. I can't remember the exact wording.
It's one thing to assign copyright to FSF, quite another to assign it a random non-profit organization. FSF has some history and widespread recognition, and one can be reasonably confident that they'll survive and remain true to their vision.
On the other hand, if somebody set up a non-profit to create the nextest bestest portal application, there's a real chance that the non-profit org could go bankrupt, regardless of the sincerity of their intention. Or the org could undergo a leadership change and a change of philosophy. If you had assigned your code to them, it could easily wind up in a proprietary commercial application. The GPL would protect existing releases, but anybody who held all the copyrights could update and re-release under a proprietary license.
Even if the terms of assignation were written to preclude this, such provisions might not survive bankruptcy.
Discussion over GPLv3 has been going on for quite some time now even though the draft has just now emerged. He has mentioned a few things, one is that he has no problem with DRM in the kernel [linuxtoday.com], whereas GPLv3 is Anti-DRM [newsforge.com]. Also Linus opposed having his developers have to make their private keys available, which was stated in the article.
I think he's thought it though, and I think the decision makes sense. No one says you have to increment from GPLv2 to GPLv3, it is at your option. RMS make the license more restrictive, too restrictive, therefore Linus said no.
RMS make the license more restrictive, too restrictive...
The fundamental intent of the license hasn't changed. The only thing this does is close the loophole whereby vendors could technically release source code that runs on their device, but if anyone actually tried to exercise their rights under the GPL by modifying the code (i.e. the entire point of it being Free Software in the first place) the device would refuse to run the code because the checksum/key wouldn't match. The GPL v.3 just adds text explicitly saying that device makers must allow this, where it was only implied (i.e. without legal weight) before.
He misinterpreted part of the GPLv3. The private key section says that if private keys are required for the code to function (in other words, your program will only load signed code) than you must make available a means to generate the signed code. The theory here is that certain hardware devices (*cough*TiVo*cough*) use GPLed software, but make it impossible to actually modify and run that software on their hardware device. In order to allow people to make changes and actually use those changes, you have to make available any private keys required to make the code actually run.
So if Mr. Torvalds has a private key that he uses to sign code, he is under no obligation to release that key to the public assuming that an end user can build and run the code without requiring the private key. You only have to release your private key if a third-party build of the software will not run without being signed by that key.
Now, another common misinterpretation that came up at the GPLv3 launch was that this meant that if you had set up your system to require signed code that you would have to make your private key available. This isn't the case. The only requirement is that a third party must be able to build and run the system without your private key. If this requires them to generate their own private key, that's perfectly acceptable.
If a GPLv3ed program cannot run without a specific private key, that private key must be made available. That's all the license says. Developers are not required to disclose private keys that they use to sign code.
"If a GPLv3ed program cannot run without a specific private key, that private key must be made available. That's all the license says. Developers are not required to disclose private keys that they use to sign code."
This simple, clear statement should be at the beginning. I think if you argue about this in the future, you would help your case to lead with this, and then back it up afterwards.
The issue of private keys, DRM, code signing and the effect of GPL V3 has been in discussion for a long time. Linus has said he might in some circumstances sign binaries, in which case you would need the private key to regenerate the signed binary.
"And since I can imaging [sic] signing binaries myself, I don't feel that I can disallow anybody else doing so." Linus Torvalds, LKML April 2003
If our task is to discredit the FSF and mis-characterize the GPLv3 effort, it is important to blow off the spirit of the license, which is to protect freedom, users, and developers.
One great means of achieving this mis-characterization is to apply the old formula: "a text without a context is a pretext".
Nice try, but it wouldn't work. You don't have legal rights to Linus' key. Section 12 states that if you cannot legally meet the obligations of the license (in this case, giving out Linus' key), you cannot distribute the code at all.
Since you can't force Linus to give up his key (it's under his copyright, and there's no obligation for him to give it up under the GPLv3), you simply can't distribute your embedded device to anyone with the GPLv3ed software included. Doing so would be a violation of the GPLv3.
The only time that you would have to give up a key is if you distribute the code in such a way that a key is required for custom modifications to work. Trying to do so using a key you don't have rights to falls prey to Section 12, meaning you can't distribute the software at all.
by Anonymous Coward
on Thursday January 26 2006, @10:11AM (#14567373)
This comes as no great surprise. How could Linus convert it to v3, even if he wanted to? There are thousands of individual copyright holders to contact (not everyone released it under "any later version"). For some of them, that's going to require a seance and/or JLH, since they are dead now. I consider this a non-story, personally, we knew this was going to happen before v3 was even announced.
Clearly I can't speak for Linus. But I can float a couple of theories based on my own thoughts and the bits of the history that I know. Adn what is/. for if not wild and semi-random speculation on subjects about which we have no first hand knowledge! IIRC Linus has said that back when he started coding Linux that he was not aware of the *BSD project (Free only at that point I think but am not sure) and that if he had known of it he would have simply used that. Also, and I'm going to just disclaim the rest o
How can code released under the GPL be relicensed at all, even GPLv3? If it can be, why can't I take it and license it with a BSD-style or completely closed source license?
Either, one entity holds the copyrights, and are free to change the license. Or, the copyright holders have agreed upon submitting their code, to allow the thing to be released as "GPL v2 or later".
Which would be the dumbest thing to do, ever. Who's to say whoever is in charge of 'making' the GPL vXXX doesn't add in all sorts of nasty things that an original author might not like. What if they release it as a horribly restrictive license? What if they open it up to being as open as the BSD license? Who knows what some other group might change the license to in the future. Licensing your code under a license another group could change at a whim is dumb. Really, really dumb.
No, the copyright holders can give permission to re-release it as GPLv3 or Carl and Jabbas Artistic Hut Licence. The 'problem' with the Linux kernel, is that there are an extreme amount of copyright holders, so even if RedHat gave permission to re-release their code as GPLv3, that would not be anywhere near the complete kernel source code.
As the grandparent tried to put it, only the copyright holder can change the license on a piece of software. If I create a program that counts to 100 and then exits, I can release it under any license(s) I want. If I release it GPL v2 and someone says, "Hey, Stine, management wants us to avoid GPL. Can we get it under BSD?", I can decide to release it under BSD if I so choose. You cannot decide to release my code under any other license than I have explicitly said that you can. If you want it under a dif
If you are the copyright holder, you can re-release your code any time under any license you want. Now if every kernel contributor re-releases his code under GPLv3, then the whole kernel is re-released under GPLv3. Of course, the code you received under v2 would remain under v2; and if you have an old kernel containing code which isn't in the current one, and isn't relicensed, then you couldn't redistribute it under v3 either. Also I think GPLv2 and GPLv3 are not compatible, because e.g. the GPLv3 DRM stuff
How can code released under the GPL be relicensed at all, even GPLv3?
1) Because the GPL license can optionally include the statement that it's covered by the GPL and/or any later version.
2) Because a copyright holder can relicense, dual-license and in general put any conditions he or she wants on their copyrighted work, including multiple different sets of conditions (licenses).
What you are asking is akin to saying "If someone lends a book to me on a set of conditions, how can they be allowed to lend it to someone else on different ones?".
If it can be, why can't I take it and license it with a BSD-style or completely closed source license?
Here is the full text as it took me several times to get past the MySQL errors with too many connections:
Date Wed, 25 Jan 2006 17:39:16 -0500 (EST) From Linus Torvalds Subject Re: GPL V3 and Linux - Dead Copyright Holders
On Wed, 25 Jan 2006, Chase Venters wrote: > > This means that when the code went GPL v1 -> GPL v2, the transition was > permissible. Linux v1.0 shipped with the GPL v2. It did not ship with a > separate clause specifying that "You may only use *this* version of the GPL" > as it now does. (I haven't done any research to find out when this clause was > added, but it was after the transition to v2).
Bzzt. Look closer.
The Linux kernel has _always_ been under the GPL v2. Nothing else has ever been valid.
The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the actual License itself. It's part of the _explanatory_ text that talks about how to apply the license to your program, and it says that _if_ you want to accept any later versions of the GPL, you can state so in your source code. The Linux kernel has never stated that in general. Some authors have chosen to use the suggested FSF boilerplate (including the "any later version" language), but the kernel in general never has.
In other words: the _default_ license strategy is always just the particular version of the GPL that accompanies a project. If you want to license a program under _any_ later version of the GPL, you have to state so explicitly. Linux never did.
So: the extra blurb at the top of the COPYING file in the kernel source tree was added not to _change_ the license, but to _clarify_ these points so that there wouldn't be any confusion.
The Linux kernel is under the GPL version 2. Not anything else. Some individual files are licenceable under v3, but not the kernel in general.
And quite frankly, I don't see that changing. I think it's insane to require people to make their private signing keys available, for example. I wouldn't do it. So I don't think the GPL v3 conversion is going to happen for the kernel, since I personally don't want to convert any of my code.
> If a migration to v3 were to occur, the only potential hairball I see is if > someone objected on the grounds that they contributed code to a version of the > kernel Linus had marked as "GPLv2 Only". IANAL.
No. You think "v2 or later" is the default. It's not. The _default_ is to not allow conversion.
I think it's insane to require people to make their private signing keys available, for example.
I think Linus is mistaken on this point. Nowhere does the GPL v3 say anything about making private keys available. This was hashed over in the previous discussion [slashdot.org]. Now if he still doesn't like some of the terms of the GPL v3, then more power to him. Even then, as other posters have commented, it'd take a small miracle to find every last copyright holder and have them agree to the change in license.
OK thats just the kernel being talked about. What about the rest of GNU/Linux?? Will it move to GPLv3?
I'm primarily concerned with gcc, glibc and the likes. X has its own license that I'm OK with. The rest of the apps are not critical and easily replaceable. gcc glibc and the kernel are damn hard to replace... they exist alone. Others have competitors.
I dont want any of GPLv3 in my system just as I dont want any of SCO code in my system. Maybe the final GPLv3 will be more palatable than it is now.
OK, so it appears Linus has decided that Linux
will not be converted over to GPL v3. Lots of
people have given philosophical opinions about
this, but what if we step back and look at it
from a purely practical point of view? What
are the costs of converting to GPL v3, and what
benefits would it provide to the Linux maintainers
and users?
Possible benefits:
GPL v3 prohibits DRM. Does this really make a
difference with Linux? Linux doesn't have
DRM features
anyway, so what does it matter what the license
says? I suppose it might prohibit a few things
that could be done on top of Linux using DRM,
and that might be good, but it seems like a
minor effect, so at best this has a minor positive
effect in favor of a
cause which isn't directly related
to the central purpose of Linux.
Keeping up to date. Yes, I suppose there is
some small benefit in being on the latest version
of the GPL just to avoid being out of date, but
personally I reject the idea that everybody
ought to always be on the latest version of
everything. You should use what works.
Make Richard Stallman happy. Doesn't
seem like a major goal of Linux.
That's pretty much it as far as the positives
for Linux, as far as I can tell. Now, what
about the negatives?
Redefinition of "user". As I understand it,
GPL v3 says if you are using something over the
network, you're still a user, and if that software
is modified, it's no longer a private modification
and the source to the changes has to be made
available. This would appear to mean that if
someone is running a public
web server on a Linux system,
they will now have to make any of their
changes to Linux public. That's unlikely to
happen, but it could affect some sites in
that they wouldn't be able to upgrade and
bring their changes forward. Probably a minor
issue, though.
Copyrights. As others have said,
Linus doesn't hold the copyrights; the
contributors do. So it's a huge hassle to
get that all converted to GPL v3.
So what is the bottom line? Converting offers
basically no major advantage. GPL v2 is just
as good as GPL v3 for the purposes of Linux.
And, converting is a huge hassle. So, rather
than looking at why Linus isn't converting the
kernel over, why don't we ask this question:
why should it be converted over? There
doesn't seem to be any kind of compelling
advantage.
My guess is that the same thing is going to apply
to lots of other projects. Converting is a great
big hassle, and it doesn't offer any big advantage,
so people just won't bother.
If the code has already been released as GPL v.2 and it has already been dispersed into the Internet wilderness, then what is done, is done. However, new code and/or new versions of existing code can be licensed however the author of it wants. It is merely up to the kernel integrators to decide if they want to use it or not.
If the kernel project guys really do not want GPLv.3-released code in their product because they consider it to be virally too restrictive, then fine. That is their prerogative and they don't need to include it. However, if the author of some highly-desired code really wants v.3 and doesn't care if it lands in the official kernel source tree, then the contrapositive applies: they can't force him to change it, either.
Remember, the GPL in its various forms is not restrictive; it is permissive. It starts with the default copyright restrictions allowing no copying of the code. It then generously gives permission to copy and use it while only asking for a few small acts of good behaviour in return.
"Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work's output."
OK, I guess I see where the confusion comes from, but it still seems just like confusion. How on earth could this clause require Linus to release his private keys? There is no DRM in linux. No encryption or authorization codes are required to install and/or execute the work, and no decryption codes are necessary to access or unseal... you get the idea.
Linus clearly plans for the Linux kernel to support DRM in the future if hardware and future content seems to demand it. Has has no qualms about supporting DRM, as long as it's done "right". When and if DRM comes to the kernel, those provisions of the GPL could have serious consequences for Linux, perhaps even making it illegal to realistically use Linux on the DRM hardware it was designed to support.
The GPLv3 will be fundamentally incompatible with any program using the Trusted Computing, because all the necessary keys can never be revealed. I assume that is the point
Exactly.
And Linus's point is that that makes it fundamentally incompatible with other forms of code signing too. The whole "Trusted Computing" thing is just a logical extension of current code-signing practice, you can't ban one without affecting the other.
Example: You want your OS's auto-update mechanism to validate updates against your vendors' private key ? I do. That's how I trust it. Your OS is GPL v3 ? - then your vendor has to publish the keys. Bye bye trust.
I'm with you on this. I distruct Richard Stallman for the same reasons. I personally think he's gone off on a side road of his original mission. Originally, it was to provide a bunch of software that was open to all and protected by copyright. Now, it seems his mission is to attempt to destroy anything that isn't open to all and protected in the ways he wants to define it. The first is setting up a safe haven for intellectual ideas and the like. The second is waging a war. I don't want a war and have no time for it. I prefer to live and let live and have no problem with OSS and proprietary software coexisting. Stallman no longer wants to coexist so I've not supported his views for some time.
"Now, it seems his mission is to attempt to destroy anything that isn't open to all and protected in the ways he wants to define it."
I rather doubt that. I think he is trying to fight the creation of an environment where free software is either illegal to run or technically impossible to run. Both are quite possible. After all, what good is software with no hardware to run it on? Stallman is right to worry about that point.
Stallman has ALWAYS considered non-free software immoral. He is "leading by example," so to speak. The problem is the hardware side is more difficult to handle, since fab equipment for chips is not a simple or inexpensive proposition.
I don't like the GFDL because of its invariant sections (primarily) and so in that regard I disagree with the approach he and the FSF have taken, but on the whole they seem to be facing up to some very unplesant possibilities and trying to put roadblocks across their ever being implemented. I'm reminded of two Lord of the Rings quotes:
"It needs but one foe to breed a war, not two."
"Those without swords can still die upon them."
Stallman is doing exactly what he has always done - respond to the threats as they become apparent. His approach to patents is another step in the same direction.
To paraphrase a sig I saw somewhere: "it's only paranoia if they AREN'T actually out to get you." Like security, license writers should be paranoid about threats to their intent. It's just too expensive to try hashing things out in court.
I made the same decision Linus did on a project I run. I like what GPLv2 says, I don't want someone at MIT deciding, years after I wrote my code, what the terms of the license on my code are by granting additional rights or restrictions. My application happens to be one that runs on a server and presents users with a web interface. As you'll recall, there were originally thoughts that v3 would require modifications to such applications to be available.
I suggest that the main weakness of the GPL is the wording "(at your option) any later version". Whether this wording is part of the license or not, is a troubling grey area.
There's no grey area. It's recommended but optional, and linux doesn't use it.
This license is less free than others because of the new provisions. I predict that the new wording will drive more new projects to BSD style licensing.
heh. That depends on what you mean by free:
A) Free as in free to do what you like with. eg, GPLv2 is more "free" in this sense because businesses have more "freedom" to DRM or patent encumber software under this license.
B) GPLv3 has more restrictions in place to guarantee that software licensed under it is not encumbered by patents or DRM restrictions. Thus it guarantees that DRM and patent restrictions don't restrict people "freedom" to use the software.
BSD style is more free in terms of (A) and less free in terms of (B). For example I am "Free" to contribute secretly patented code to your BSD project and then take you to court for patent infringement when you distribute said software. Is that a freedom you intended to grant me or would you actually have preferred to use a more restrictive license after all?
As a user, you won't care. It *only* relates to software authors. A quick and dirty summary:-
- Public domain allows people to do anything they like with your code, including making minor mods and claiming it as all their own work, or making minor mods and selling the result as closed-source code.
- BSD allows reuse of your code or a modified version of your code, in anything (including commercial software), without releasing source, so long as they credit you. In other words you can't claim it as your own work.
- LGPL allows reuse of your code as a component part of a commercial software system - hence its alternative name of "library GPL". You don't need to release the code for anything that uses this code/library. However if you make changes to the LGPL code/library then you must release the changes. Again, credits are required.
- GPL goes a step further. If you use a GPL code/library component as part of your software, then you must also release *all* your software as GPL as well, otherwise you may not use that code/library component. Again, there's the requirement for releasing code and credits.
There's many other licenses, but you get the idea.
There's two different philosophies here that drive this.
The first is the Open Source philosophy (Linus and ESR are the drivers here). This says that if everyone works together, we can build something better than closed source software. But it doesn't invalidate the existence of closed source software - it acknowledges that this only works for mass-market software, so there will always be niches where closed-source is a better choice. Basically their drive is to help people do their jobs more efficiently.
The second is the Free Software philosophy (driven by RMS and the FSF group). This says that the very *existence* of closed-source software is immoral, and anyone using closed-source software (even in niches where no free equivalent exists) is guilty of immorality (RMS says that if no free software exists to do a job, then you should refuse to do that job). Software is therefore created as a moral imperative, rather than as a means to an end of carrying out some task (such as web browsing or word processing).
What v3 does he mean? (Score:3, Insightful)
What is that thing about developers having to turn over their private keys? I don't think anything that stupid is even considered for GPLv3.
I wish there would be a rational and friendly discussion. Is that too much? Have we come thus far?
Re:What v3 does he mean? (Score:5, Informative)
Parent
Re:What v3 does he mean? (Score:3, Insightful)
Yeah but that is not the reason Linus is giving. He doesn't like it (and he mentions that bizarre private key issue as a reason for that), and so he doesn't even get to the point where he starts wondering whether it would be practically possible to change licenses. At least that's the way I read his post.
Re:What v3 does he mean? (Score:5, Insightful)
It sounds like his gripe with the GPLv3 is that it is imposing restrictions on what modifications or contributions can be made, which is not the same agnostic view as in previous versions.
The idealist (RMS) and the engineer (Linus) are definitely at a point of contention on this issue...it'll be interesting to see what happens.
Parent
Re:What v3 does he mean? (Score:4, Funny)
Welcome to the wonderful world of GNU!
Parent
Re:What v3 does he mean? (Score:5, Informative)
It's also why the Linux kernel is much more popular among developers than HURD (because people and companies can contribute to it and still keep their copyright).
Parent
Which is why HURD will never see the light of day (Score:3, Insightful)
Re:Which is why HURD will never see the light of d (Score:5, Interesting)
Parent
Re:Which is why HURD will never see the light of d (Score:5, Interesting)
"Which is why HURD will never see the light of day in any substantial fashion. Philosophy doesn't yield code."
If you simply want to argue over the semantics of whether or not philosophy yields code or people yield code, read no further; I have nothing to say to you. The point of this post realtes to substance, not semantics. (And before you stop reading, ask yourself this: what is philosophy without people?) Your second statement is clearly a generalization you're drawing from your first, and in incorrect one, at that. As GP alluded to, the GNU in GNU/Linux is all the utilities you use on the command line, up to and including the command line itself, and is under the copyright of the FSF. I haven't done recent SLOC counts on GNU vs. Linux, but I would be surprised if they weren't at least comparable - I'd expect that GNU actually has produced substantially more source code (that is used all the time by all manner of users and developers) than the Linux kernel itself these days. Back in 2002 [dwheeler.com], RedHat 7.1 was studied and though the kernel was the largest single body of source (~2.5 million lines), there are GNU programs all over that quickly outstrip the kernel in sheer volume of source: gcc alone is huge (~900k lines), but emacs (~600k lines) and glibc (~600k lines) are both quite large as well. Those are only three GNU programs, the directory of FSF software [fsf.org] contains (as an estimate) hundreds, including the Hurd itself.
Indeed, philosophy is a manner of viewing of the world and is expressed not by some abstract theoretical paper you write, but in how you choose to live and contribute your work to others. In this sense, philosophy is very much responsible for yielding code - do you honestly think that without the philosophical buy-in of its contributors, free software would be anything today?
Parent
Re:Which is why HURD will never see the light of d (Score:5, Insightful)
> with both individuals and companies because it is more flexible (from a copyright
> standpoint) than HURD.
No.
Linux is more popular than HURD because at certain critical points in history it was "working" and "ready" for definitions of "working" and "ready" that could not really be applied to HURD at the time. Basically, Linux was in the right place at the right time. HURD never showed up to the party, and there was a licensing lawsuit connected with BSD at a particularly critical point in time which left it just a little behind in just the wrong ways at just the wrong time, allowing Linux to get "ahead" in terms of mindshare and popularity in the developer community. Consequently, there was a several-month time window, at a particularly important time in history (right about when a lot of college undergrads were first getting net access) when if you wanted a freely-available, freely-modifiable, freely-redistributable operating system, Linux was _the_ obvious choice. That gave it a leg up, got a lot of people involved with improving it, and made it the leading and most popular free OS. Nothing has yet managed to unseat it from that position.
Just to be clear, I'm not saying that the FSF's policies haven't hampered HURD development. They likely have. What I'm saying is that that is not the key important reason why Linux is ahead of HURD (both in terms of popularity and development cycle). The key reason is because Linus had working, usably complete code at an important time when the FSF (in terms of a kernel) did not.
If the timing had worked out differently, the HURD might have been in the leading position, in spite of the FSF's (admittedly rather strict) copyright policies. It is notable that a number of the FSF's *other* projects, despite said policies, are leading implementations in their respective niches, because those projects were finished to the degree they needed to be and working to the degree they needed to be when they needed to be. Emacs for instance was there enough and working enough (for _most_ of the folks who wanted an Emacs, albeit not for Lucent) that XEmacs is just another, somewhat less popular alternative, rather than completely eclipsing Gnu Emacs as Linux has done to HURD.
Parent
Re:What v3 does he mean? (Score:5, Informative)
Don't contributors assign copyright to some type of Linux foundation?
No. Linux kernel contributors retain their own copyright. This is frequently considered to be a good thing, as it means that no single group has copyright over everything, which means that no single group can change the license to e.g. BSD and start selling a proprietary version of Linux.
Parent
Re:What v3 does he mean? (Score:4, Interesting)
At least with the FSF model, it's not 100% trust based; at least last time I checked they do sign a contract with the assigner saying that they'll distribute the code under a free license or the copyright reverts, or something along those lines. I can't remember the exact wording.
Parent
Re:What v3 does he mean? (Score:5, Insightful)
On the other hand, if somebody set up a non-profit to create the nextest bestest portal application, there's a real chance that the non-profit org could go bankrupt, regardless of the sincerity of their intention. Or the org could undergo a leadership change and a change of philosophy. If you had assigned your code to them, it could easily wind up in a proprietary commercial application. The GPL would protect existing releases, but anybody who held all the copyrights could update and re-release under a proprietary license.
Even if the terms of assignation were written to preclude this, such provisions might not survive bankruptcy.
Parent
DRM, private keys (Score:5, Insightful)
I think he's thought it though, and I think the decision makes sense. No one says you have to increment from GPLv2 to GPLv3, it is at your option. RMS make the license more restrictive, too restrictive, therefore Linus said no.
Parent
Re:DRM, private keys (Score:5, Insightful)
Parent
Re:What v3 does he mean? (Score:5, Informative)
He misinterpreted part of the GPLv3. The private key section says that if private keys are required for the code to function (in other words, your program will only load signed code) than you must make available a means to generate the signed code. The theory here is that certain hardware devices (*cough*TiVo*cough*) use GPLed software, but make it impossible to actually modify and run that software on their hardware device. In order to allow people to make changes and actually use those changes, you have to make available any private keys required to make the code actually run.
So if Mr. Torvalds has a private key that he uses to sign code, he is under no obligation to release that key to the public assuming that an end user can build and run the code without requiring the private key. You only have to release your private key if a third-party build of the software will not run without being signed by that key.
Now, another common misinterpretation that came up at the GPLv3 launch was that this meant that if you had set up your system to require signed code that you would have to make your private key available. This isn't the case. The only requirement is that a third party must be able to build and run the system without your private key. If this requires them to generate their own private key, that's perfectly acceptable.
If a GPLv3ed program cannot run without a specific private key, that private key must be made available. That's all the license says. Developers are not required to disclose private keys that they use to sign code.
Parent
Re:What v3 does he mean? (Score:5, Insightful)
This simple, clear statement should be at the beginning. I think if you argue about this in the future, you would help your case to lead with this, and then back it up afterwards.
Parent
Read the LKML Archive. this has been discussed (Score:3, Informative)
The issue of private keys, DRM, code signing and the effect of GPL V3 has been in discussion for a long time. Linus has said he might in some circumstances sign binaries, in which case you would need the private key to regenerate the signed binary.
"And since I can imaging [sic] signing binaries myself, I don't feel that I can
disallow anybody else doing so."
Linus Torvalds, LKML April 2003
Re:What v3 does he mean? (Score:3, Funny)
One great means of achieving this mis-characterization is to apply the old formula: "a text without a context is a pretext".
Re:How to force disclosure of private keys (Score:4, Insightful)
Nice try, but it wouldn't work. You don't have legal rights to Linus' key. Section 12 states that if you cannot legally meet the obligations of the license (in this case, giving out Linus' key), you cannot distribute the code at all.
Since you can't force Linus to give up his key (it's under his copyright, and there's no obligation for him to give it up under the GPLv3), you simply can't distribute your embedded device to anyone with the GPLv3ed software included. Doing so would be a violation of the GPLv3.
The only time that you would have to give up a key is if you distribute the code in such a way that a key is required for custom modifications to work. Trying to do so using a key you don't have rights to falls prey to Section 12, meaning you can't distribute the software at all.
Parent
Don't see how this is a story. (Score:5, Insightful)
Re:Don't see how this is a story. (Score:3, Interesting)
IIRC Linus has said that back when he started coding Linux that he was not aware of the *BSD project (Free only at that point I think but am not sure) and that if he had known of it he would have simply used that. Also, and I'm going to just disclaim the rest o
Huh (Score:3, Insightful)
Well, this is how it goes: (Score:4, Interesting)
Parent
Re:Well, this is how it goes: (Score:3, Insightful)
Re:Well, this is how it goes: (Score:3, Informative)
Re:Well, this is how it goes: (Score:3, Informative)
If I create a program that counts to 100 and then exits, I can release it under any license(s) I want. If I release it GPL v2 and someone says, "Hey, Stine, management wants us to avoid GPL. Can we get it under BSD?", I can decide to release it under BSD if I so choose. You cannot decide to release my code under any other license than I have explicitly said that you can. If you want it under a dif
Re:Well, this is how it goes: (Score:3, Informative)
Re:Huh (Score:5, Informative)
1) Because the GPL license can optionally include the statement that it's covered by the GPL and/or any later version.
2) Because a copyright holder can relicense, dual-license and in general put any conditions he or she wants on their copyrighted work, including multiple different sets of conditions (licenses).
What you are asking is akin to saying "If someone lends a book to me on a set of conditions, how can they be allowed to lend it to someone else on different ones?".
If it can be, why can't I take it and license it with a BSD-style or completely closed source license?
Because you don't own the copyright.
Parent
Full Text; Lots of MySQL Errors (Score:3, Informative)
Date Wed, 25 Jan 2006 17:39:16 -0500 (EST)
From Linus Torvalds
Subject Re: GPL V3 and Linux - Dead Copyright Holders
On Wed, 25 Jan 2006, Chase Venters wrote:
>
> This means that when the code went GPL v1 -> GPL v2, the transition was
> permissible. Linux v1.0 shipped with the GPL v2. It did not ship with a
> separate clause specifying that "You may only use *this* version of the GPL"
> as it now does. (I haven't done any research to find out when this clause was
> added, but it was after the transition to v2).
Bzzt. Look closer.
The Linux kernel has _always_ been under the GPL v2. Nothing else has ever
been valid.
The "version 2 of the License, or (at your option) any later version"
language in the GPL copying file is not - and has never been - part of the
actual License itself. It's part of the _explanatory_ text that talks
about how to apply the license to your program, and it says that _if_ you
want to accept any later versions of the GPL, you can state so in your
source code.
The Linux kernel has never stated that in general. Some authors have
chosen to use the suggested FSF boilerplate (including the "any later
version" language), but the kernel in general never has.
In other words: the _default_ license strategy is always just the
particular version of the GPL that accompanies a project. If you want to
license a program under _any_ later version of the GPL, you have to state
so explicitly. Linux never did.
So: the extra blurb at the top of the COPYING file in the kernel source
tree was added not to _change_ the license, but to _clarify_ these points
so that there wouldn't be any confusion.
The Linux kernel is under the GPL version 2. Not anything else. Some
individual files are licenceable under v3, but not the kernel in general.
And quite frankly, I don't see that changing. I think it's insane to
require people to make their private signing keys available, for example.
I wouldn't do it. So I don't think the GPL v3 conversion is going to
happen for the kernel, since I personally don't want to convert any of my
code.
> If a migration to v3 were to occur, the only potential hairball I see is if
> someone objected on the grounds that they contributed code to a version of the
> kernel Linus had marked as "GPLv2 Only". IANAL.
No. You think "v2 or later" is the default. It's not. The _default_ is to
not allow conversion.
Conversion isn't going to happen.
Linus
Re:Full Text; Lots of MySQL Errors (Score:5, Informative)
I think Linus is mistaken on this point. Nowhere does the GPL v3 say anything about making private keys available. This was hashed over in the previous discussion [slashdot.org]. Now if he still doesn't like some of the terms of the GPL v3, then more power to him. Even then, as other posters have commented, it'd take a small miracle to find every last copyright holder and have them agree to the change in license.
Parent
I GNU it! (Score:4, Funny)
Nothing to see here, please move along.
Anyone else notice... (Score:5, Interesting)
http://lkml.org/lkml/2006/1/20/226 [lkml.org]
http://lkml.org/lkml/2004/10/23/186 [lkml.org]
Just the kernel? (Score:4, Interesting)
I'm primarily concerned with gcc, glibc and the likes. X has its own license that I'm OK with. The rest of the apps are not critical and easily replaceable. gcc glibc and the kernel are damn hard to replace... they exist alone. Others have competitors.
I dont want any of GPLv3 in my system just as I dont want any of SCO code in my system. Maybe the final GPLv3 will be more palatable than it is now.
cost vs. benefits (Score:4, Insightful)
OK, so it appears Linus has decided that Linux will not be converted over to GPL v3. Lots of people have given philosophical opinions about this, but what if we step back and look at it from a purely practical point of view? What are the costs of converting to GPL v3, and what benefits would it provide to the Linux maintainers and users?
Possible benefits:
That's pretty much it as far as the positives for Linux, as far as I can tell. Now, what about the negatives?
So what is the bottom line? Converting offers basically no major advantage. GPL v2 is just as good as GPL v3 for the purposes of Linux. And, converting is a huge hassle. So, rather than looking at why Linus isn't converting the kernel over, why don't we ask this question: why should it be converted over? There doesn't seem to be any kind of compelling advantage.
My guess is that the same thing is going to apply to lots of other projects. Converting is a great big hassle, and it doesn't offer any big advantage, so people just won't bother.
Up to the contributor, mostly (Score:5, Informative)
If the kernel project guys really do not want GPLv.3-released code in their product because they consider it to be virally too restrictive, then fine. That is their prerogative and they don't need to include it. However, if the author of some highly-desired code really wants v.3 and doesn't care if it lands in the official kernel source tree, then the contrapositive applies: they can't force him to change it, either.
Remember, the GPL in its various forms is not restrictive; it is permissive. It starts with the default copyright restrictions allowing no copying of the code. It then generously gives permission to copy and use it while only asking for a few small acts of good behaviour in return.
Re:I don't get it... (Score:5, Informative)
DRM clause I guess?
"Complete Corresponding Source Code also includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work's output."
http://gplv3.fsf.org/draft [fsf.org]
Parent
Re:I don't get it... (Score:4, Insightful)
Is Linus on crack?
Parent
Re:I don't get it... (Score:3, Insightful)
Linus clearly plans for the Linux kernel to support DRM in the future if hardware and future content seems to demand it. Has has no qualms about supporting DRM, as long as it's done "right". When and if DRM comes to the kernel, those provisions of the GPL could have serious consequences for Linux, perhaps even making it illegal to realistically use Linux on the DRM hardware it was designed to support.
Re:Wasn't this already covered? (Score:4, Interesting)
Exactly.
And Linus's point is that that makes it fundamentally incompatible with other forms of code signing too. The whole "Trusted Computing" thing is just a logical extension of current code-signing practice, you can't ban one without affecting the other.
Example: You want your OS's auto-update mechanism to validate updates against your vendors' private key ? I do. That's how I trust it. Your OS is GPL v3 ? - then your vendor has to publish the keys. Bye bye trust.
Parent
Re:Linus does not trust Stallman (Score:3, Insightful)
I wasn't aware the FSF was a failure either.
Why on earth loathe the guy? I feel like I missed something.
Re:Linus does not trust Stallman (Score:3, Informative)
Re:Linus does not trust Stallman (Score:4, Insightful)
Parent
Re:Linus does not trust Stallman (Score:4, Insightful)
I rather doubt that. I think he is trying to fight the creation of an environment where free software is either illegal to run or technically impossible to run. Both are quite possible. After all, what good is software with no hardware to run it on? Stallman is right to worry about that point.
Stallman has ALWAYS considered non-free software immoral. He is "leading by example," so to speak. The problem is the hardware side is more difficult to handle, since fab equipment for chips is not a simple or inexpensive proposition.
I don't like the GFDL because of its invariant sections (primarily) and so in that regard I disagree with the approach he and the FSF have taken, but on the whole they seem to be facing up to some very unplesant possibilities and trying to put roadblocks across their ever being implemented. I'm reminded of two Lord of the Rings quotes:
"It needs but one foe to breed a war, not two."
"Those without swords can still die upon them."
Stallman is doing exactly what he has always done - respond to the threats as they become apparent. His approach to patents is another step in the same direction.
To paraphrase a sig I saw somewhere: "it's only paranoia if they AREN'T actually out to get you." Like security, license writers should be paranoid about threats to their intent. It's just too expensive to try hashing things out in court.
Parent
Why trust anyone? (Score:4, Interesting)
Parent
Re:GPL weakness: "at your option any other version (Score:3, Informative)
There's no grey area. It's recommended but optional, and linux doesn't use it.
Re:Linus is wrong (Score:3, Funny)
To quote the key section:
If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
That just gave me an idea on how Microsoft and others could destroy Linux and other OSS...
Step 1: Take over FSF
Step 2: Turn GPL into a more BSD like license
Step 3: ???
Step 4: Profit!
And I think we all know what could and would happen for Step 3.
Re:Maybe Linus doesn't LIKE what GPL3 requires? (Score:5, Insightful)
heh. That depends on what you mean by free:
A) Free as in free to do what you like with. eg, GPLv2 is more "free" in this sense because businesses have more "freedom" to DRM or patent encumber software under this license.
B) GPLv3 has more restrictions in place to guarantee that software licensed under it is not encumbered by patents or DRM restrictions. Thus it guarantees that DRM and patent restrictions don't restrict people "freedom" to use the software.
BSD style is more free in terms of (A) and less free in terms of (B). For example I am "Free" to contribute secretly patented code to your BSD project and then take you to court for patent infringement when you distribute said software. Is that a freedom you intended to grant me or would you actually have preferred to use a more restrictive license after all?
Parent
Re:Not sure I understand (Score:5, Interesting)
- Public domain allows people to do anything they like with your code, including making minor mods and claiming it as all their own work, or making minor mods and selling the result as closed-source code.
- BSD allows reuse of your code or a modified version of your code, in anything (including commercial software), without releasing source, so long as they credit you. In other words you can't claim it as your own work.
- LGPL allows reuse of your code as a component part of a commercial software system - hence its alternative name of "library GPL". You don't need to release the code for anything that uses this code/library. However if you make changes to the LGPL code/library then you must release the changes. Again, credits are required.
- GPL goes a step further. If you use a GPL code/library component as part of your software, then you must also release *all* your software as GPL as well, otherwise you may not use that code/library component. Again, there's the requirement for releasing code and credits.
There's many other licenses, but you get the idea.
There's two different philosophies here that drive this.
The first is the Open Source philosophy (Linus and ESR are the drivers here). This says that if everyone works together, we can build something better than closed source software. But it doesn't invalidate the existence of closed source software - it acknowledges that this only works for mass-market software, so there will always be niches where closed-source is a better choice. Basically their drive is to help people do their jobs more efficiently.
The second is the Free Software philosophy (driven by RMS and the FSF group). This says that the very *existence* of closed-source software is immoral, and anyone using closed-source software (even in niches where no free equivalent exists) is guilty of immorality (RMS says that if no free software exists to do a job, then you should refuse to do that job). Software is therefore created as a moral imperative, rather than as a means to an end of carrying out some task (such as web browsing or word processing).
Grab.
Parent
Re:Not sure I understand (Score:5, Informative)
That's simply not true, and amounts to a gross misrepresentation of RMS' position.
What he says is: "If you value freedom, you will resist the temptation to use a program that takes away your freedom, whatever technical advantages it may have." [linuxdevcenter.com]
Which is a different thing altogether.
Parent