If you don't look for something in a particular place, you won't find it there. This is so obvious that Heisenberg called it his Duh! Principle (little-known fact). The corollary of this principle is you won't know if something is in a particular place until you look for it there. This led Heisenberg to develop his Uncertainty Principle, and social studies has never been the same since.
The text in question is not part of the GPL itself; it is part of a section, outside the license, entitled "How to Apply These Terms to Your New Programs". As you point out, the FSF has had 15 years during which it could have published updated information about the ramifications of the recommended clause. This would not have required changing the license itself. I'm not objecting to the fact that the FSF didn't say anything about this in 1991; I'm objecting to their continued silence on the matter, right up until the point at which it became an issue with the next version of the license, over 15 years later.
I'm not objecting to the clarity of the language in the license itself. I'm objecting to the way in which the FSF recommends applying the license to a program, with no discussion of the pros and cons from a user's perspective.
The sort of analysis I'm talking about would point out that by including the "any later version" clause, a copyright holder at the very least transfers to the FSF the power to relicense his code, since the FSF can produce new versions of the GPL at its discretion. It could explain why this can be a desirable thing, and discuss the issues involved with licensing of large collaborative projects over time -- that code licensed with the "or later" clause can more easily be integrated with future GPL'd projects. There's a reciprocity aspect which could be mentioned. That all said, there are obviously still situations in which a reasonable licensor may wish to control the license on their software more carefully - the current MySQL case is evidence of this. An honest discussion of the issues would point this out.
Basically, the clause in question requires a fairly large degree of trust in the FSF from a user of the license. It would be in the FSF's own interests to explain why a user of the license should extend that trust to the FSF, rather than relying (in many cases) on the user's ignorance to simply use the recommended language. The latter approach undermines the very trust which the FSF should be courting.
You are criticising the FSF for using "tactics" that corporations and politicians also use. You do not have a cogent argument of why such tactics are inherently evil, since it's clear that they preserve choice for developers not restrict it
My argument is simple: instead of explaining the rather complex issues involved, they try to pull a fast one and recommend language that's primarily in the FSF's own interests, rather than the users of the license, without any comment on the matter. That's deceptive and self-serving, and does not conform to the otherwise high moral standards exhibited by the FSF.
So please be constructive, please point us to any another way to achieve this same goal, by using "tactics" which you find more appropriate.
I have already done so. I suggested that it would be better to provide an analysis of the issues involved, and allow users to make an informed choice. Hoping to trick users into doing what the FSF considers the right thing is a tactic that is beneath them.
I'm not missing the point of the clause, in fact I alluded to it specifically in my comment: that it acts as the next best thing to assigning copyright to the FSF.
In any case, the case you make is not very compelling. In the scenario you describe, you can't force a change of license on people who already have the software under the original license, so "you have effectively given away your code to the one discovering the loophole".
There are certainly complex issues to consider when trying to anticipate the future while dealing with the combined but separately "owned" intellectual effort of many people. However, the FSF's approach to the problem in this particular case was a cop-out at best -- simplistic, done in a way that grants maximum power to the FSF, without attempting to alert users of the license to the potential issues.
The real problem with this kind of behavior is that it reduces trust in the FSF, when it becomes apparent that the organization is taking actions that may be against the interests of many of the people who use the license. The FSF may think such tactics are to their benefit, but I think they'd do well not to copy the tactics of corporations and politicians, and rather be open and honest with the community that depends on their license.
"Nerds who'd work for the Nazis if they had the coolest technology," perhaps. We have to admit that there are people who really wouldn't care if genocide or slavery were going on in their backyard, so long as it didn't affect them yet.
Did you hear about those new Bake-a-Dude high-intensity, large capacity EM radiation ovens? I hear they can handle two thousand people simultaneously, and you can select whether you want to use anything from microwaves to gamma rays to do the toasting. Not only that, but you can control them with a web browser, wirelessly!
It's difficult to overstate how strong the ramifications of that "or any later version" clause are. For all intents and purposes, including that clause when you license your code is the next best thing to assigning copyright of your code to the FSF, since it allows them to re-license your code as they see fit.
Of course, the FSF likes you to assign copyright to them anyway, but failing that, they booby-trapped the license with language which most people have not been aware enough to question. Some true believers like to respond to that with "but I trust the FSF", but that's nonsense: how can you trust an organization that doesn't exist yet, i.e. the future FSF. What happens when Stallman dies, for example?
The fact that the FSF recommended this language is, to me, an example of overzealousness which the FSF should be ashamed of. We see these sorts of tactics used by politicians and legislators all the time. It's disappointing to see an organization like the FSF, which seems to be founded on some real principles rather than "let's see who can grab the most power", stoop to these levels to promote their agenda.
No doubt FSF members and fans would justify this language on a kind of "means justifies the ends" basis. But the problem is that the language in question represents a centralization of power with no real checks or balances. No moral organization should want such a thing.
-Native English speakers do write things like "So the answer is: No support for Linux".
Perhaps, but the context provided by the other slipups allow me to "condense fact from the vapor of nuance", to quote Stephenson from memory. To me, the overall evidence is pretty clear, and that colors my perception of some of the borderline cases in a way which I think is entirely reasonable. Complicating the analysis here is that some of the responses seem to have been written by a much more fluent author.
I agree wholeheartedly that they shouldn't be that sloppy, but man, have you picked up a copy of Time magazine recently
Time is for children (which was when I last read it), and for people who prefer colors to words.
or read a memo from the PHB?
Functional illiteracy is to be expected from the managerial class - after all, they have people to take care of such details for them. It's those people who generally make sure that the published output of a well-funded organization is better than the EU example.
Right after the quote mentioned in the other reply, there's "No possibilities to use the Table Of contents for positioning the streaming". "Possibilities" shouldn't be pluralized, and "positioning the streaming" is clumsy, as though translated via dictionary. I'm sure it makes sense in French, or something.
Then there's the repetition of "The live streaming media service of the Council of the European Union", e.g. in the #2 question & answer, which by normal English convention would use an anaphoric referent to avoid the repetition. The final sentence of the #2 answer, "So the answer is: No support for Linux", is beyond casual, it's simply sloppy, and I suspect that phrasing was most likely used because the author couldn't figure out how to provide a definitive response that integrated well with the rest of the text.
To be fair, the third and fourth Q&A are decent. In #5, the use of the word "streamings" is jarring.
#6 says "The users have the choice between...". You can't tell me that's not the work of a non-native speaker translating an idiom from his native language. There are multiple things wrong with that: if you're going to write such a sentence in English, you'd usually just write "Users have the choice between...". However, this construction is not consistent with the question, which says "What kind of player do I need". The response should begin more like "You need..." or "You have a choice between...". Even without that issue, "The users" include the readers of the FAQ, and it isn't normal to refer to the reader in such a stilted third-person way.
I could go on. In general, I find it hard to believe a native English speaker could read that FAQ and not notice any issues (even if they don't know the grammatical terms to describe the issues). Are you a native English speaker? Or are you an author of the FAQ?;)
I concur with the OP, that's some pretty bad English on that site, including the FAQ page. It doesn't look at all native or casual. Perhaps it's the EU's way of getting revenge on England for not adopting the Euro and suffering along with the rest of Europe...;)
You have the freedom to do whatever you want with Debian software, but that doesn't mean that Debian's developers should be implicated in that process.
I agree.
I just want Ubuntu to be more clear about the fact that they are NOT Debian and that they are NOT a completely free distribution.
That's reasonable.
Re the "Debian family", we're arguing about a term without a definition. To me, if a distro is based on Debian (rather than just, say, supporting apt-get as Fedora does) then there's grounds for considering it part of the Debian family. That's a technical or lineage-oriented definition. Of course, if you define the Debian family as those distros that adhere to the Debian Social Contract, then I imagine you cut the family down significantly. Perhaps Linspire and Ubuntu can be considered black sheep members of the family. That's not such a bad analogy: black sheep members of real families have often done something which the rest of the family disapproves of, like violate some religious rule. Sound familiar?
My issue, and what I think distinguishes Ubuntu from most other Debian derivatives, is that they expect the Debian developers to change the way they package their software so that it will meet the needs of Ubuntu. If Ubuntu wants a certain feature that Debian doesn't have; they go to Debian and twist their arms, buy out their developers, and whine and complain about what a bunch of stubborn pigs the Debian people are until they get their way.
You've given me one example of this, light on detail. If the situation more generally is really as bad as you say, then you have a point. OTOH, I could imagine situations in which it might be in Debian's interests to make changes, even if it seems like a pain to the developers. In the long run, the work that's gone into Ubuntu is likely to benefit Debian, and better compatibility between the two could work both ways. Perhaps another way to deal with Ubuntu demands would be to figure out what Ubuntu can do for Debian, and explicitly ask for that in return. That would make for a more balanced negotiation, and might force Ubuntu to moderate their demands.
As for buying out developers, that's an interesting subject. The implication of your objections in this area is that ideally, Debian developers should be employed (paid) doing something that has nothing to do with Debian, so that there won't be any conflicts of interest. As soon as you have developers being paid to work on something that's related to what they're doing for Debian, there are going to be conflicts of interest, unless they're being paid out of Debian funds. So the question becomes, is having developers funded to work on Debian-related things worth the costs in terms of whatever conflicts of interest might arise? I haven't seen real evidence to argue otherwise. Spats between developers are going to happen no matter what the issues are. If there's a real systemic problem, then it's at least as much Debian's problem to deal with in terms of the general issue of how its developers support themselves, and how it relates to derivative distributions, as it is Ubuntu's.
So Jousselin Mouette says, in effect, "trust me" with no details in an argument that's obviously quite contentious, and I should just take him at his word? It's interesting that he chose not to use his own words to characterize the situation. Perhaps if I knew him personally, I could just accept this at face value, but otherwise, as I said, I'll reserve judgement until I see some facts. The free software community is filled with people whose idealism sometimes gets in the way of their ability to perceive reality, and the personal disagreements often outweigh any rational arguments, too.
And honestly, why should Debian care about people who will use proprietary drivers over free ones just so they can "bring the bling"?
Here and elsewhere, you're overgeneralizing from a specific case. Luckily, you are not Debian. I use proprietary Nvidia drivers, on some of my Debian machines - that's my choice, and my right as a user of free software. Should I assume I'm therefore not welcome in the Debian community or even the broader "family" originally mentioned? You obviously have strong convictions, but not everyone shares those exact convictions - even some other Debian users.
My point, BTW, is not about "proselytizing to the masses", but rather that wider distribution of Debian software will be in Debian's interest in the long run, even if it's through derivative distros like Ubuntu. That doesn't mean Debian needs to change what it's doing, except for some members of the Debian community in one area: their tolerance for other people who are using Debian software in ways that free software allows it to be used. Your position is the one which seems against the goals of free software, to me.
Saying Ubuntu and Debian are not the same thing is not the same as saying they're not in the same family. I was mainly objecting to the latter claim, which seems unnecessarily divisive.
As for the point about Gnome, you're quoting someone from Novell who's fighting to avoid losing Suse developers to Ubuntu. I'll reserve judgement until I see some facts. In the meantime, it seems to me that the person paying someone's salary does have some say over what they do with their time. I'll also observe that I'd rather see someone like Shuttleworth involved with a Debian derivative than to see a company like Microsoft involved, the way it is with Novell and Suse.
If Debian had no derivative distros geared towards end users, that would be a bad thing for Debian. I don't think you could ask for a much better end-user distro than Ubuntu, except in a fantasy world, despite Shuttleworth's various personal quirks etc. So yes, I think Ubuntu is an unmitigated boon for Debian. It would be a more unmitigated boon for its community if people on both sides didn't treat the difference as a divisive one, though.
What is your goal in trying to create a division between Debian and Ubuntu? Are you really so committed to "free software" that you can't see the benefit in providing a system geared towards non-nerd users, which in order to fulfill its mission, relies on a few "blobs"?
I'm a Debian user (on my desktop, laptop, servers and handheld), and have no personal interest in Ubuntu. However, I think that the existence of Ubuntu is an unmitigated boon for the Debian community, the Linux community, and the world in general. I really don't see the point in allowing some perfect notion of free software get in the way of providing a good, usable collection of free software to ordinary users. As the saying goes, "the perfect is the enemy of the good".
Please consider moderating your perspective, in the interests of furthering the cause of free software.
Within New Zealand, the Kiwis (New Zealanders) think that "kiwi" means a native flightless bird. But outside New Zealand, the only thing named "kiwi" that anyone ever sees is the fruit. So just as it's necessary, inside New Zealand, to qualify the fruit's name and call it "kiwifruit", so is it necessary, outside New Zealand where no-one ever sees the birds, to qualify the bird's name to avoid confusing it with the fruit.
Slashdot Mirror
If you don't look for something in a particular place, you won't find it there. This is so obvious that Heisenberg called it his Duh! Principle (little-known fact). The corollary of this principle is you won't know if something is in a particular place until you look for it there. This led Heisenberg to develop his Uncertainty Principle, and social studies has never been the same since.
Congratulations on so subtly eliciting a Pavlovian response from the moderators!
The text in question is not part of the GPL itself; it is part of a section, outside the license, entitled "How to Apply These Terms to Your New Programs". As you point out, the FSF has had 15 years during which it could have published updated information about the ramifications of the recommended clause. This would not have required changing the license itself. I'm not objecting to the fact that the FSF didn't say anything about this in 1991; I'm objecting to their continued silence on the matter, right up until the point at which it became an issue with the next version of the license, over 15 years later.
I'm not objecting to the clarity of the language in the license itself. I'm objecting to the way in which the FSF recommends applying the license to a program, with no discussion of the pros and cons from a user's perspective.
The sort of analysis I'm talking about would point out that by including the "any later version" clause, a copyright holder at the very least transfers to the FSF the power to relicense his code, since the FSF can produce new versions of the GPL at its discretion. It could explain why this can be a desirable thing, and discuss the issues involved with licensing of large collaborative projects over time -- that code licensed with the "or later" clause can more easily be integrated with future GPL'd projects. There's a reciprocity aspect which could be mentioned. That all said, there are obviously still situations in which a reasonable licensor may wish to control the license on their software more carefully - the current MySQL case is evidence of this. An honest discussion of the issues would point this out.
Basically, the clause in question requires a fairly large degree of trust in the FSF from a user of the license. It would be in the FSF's own interests to explain why a user of the license should extend that trust to the FSF, rather than relying (in many cases) on the user's ignorance to simply use the recommended language. The latter approach undermines the very trust which the FSF should be courting.
My argument is simple: instead of explaining the rather complex issues involved, they try to pull a fast one and recommend language that's primarily in the FSF's own interests, rather than the users of the license, without any comment on the matter. That's deceptive and self-serving, and does not conform to the otherwise high moral standards exhibited by the FSF.
I have already done so. I suggested that it would be better to provide an analysis of the issues involved, and allow users to make an informed choice. Hoping to trick users into doing what the FSF considers the right thing is a tactic that is beneath them.A wry comment on the truth of the GP's observation, and it gets modded flamebait. Pearls before swine, I tell you.
I'm not missing the point of the clause, in fact I alluded to it specifically in my comment: that it acts as the next best thing to assigning copyright to the FSF.
In any case, the case you make is not very compelling. In the scenario you describe, you can't force a change of license on people who already have the software under the original license, so "you have effectively given away your code to the one discovering the loophole".
There are certainly complex issues to consider when trying to anticipate the future while dealing with the combined but separately "owned" intellectual effort of many people. However, the FSF's approach to the problem in this particular case was a cop-out at best -- simplistic, done in a way that grants maximum power to the FSF, without attempting to alert users of the license to the potential issues.
The real problem with this kind of behavior is that it reduces trust in the FSF, when it becomes apparent that the organization is taking actions that may be against the interests of many of the people who use the license. The FSF may think such tactics are to their benefit, but I think they'd do well not to copy the tactics of corporations and politicians, and rather be open and honest with the community that depends on their license.
I like your honesty! You have my vote!
I'm laughing right along with you.
It's difficult to overstate how strong the ramifications of that "or any later version" clause are. For all intents and purposes, including that clause when you license your code is the next best thing to assigning copyright of your code to the FSF, since it allows them to re-license your code as they see fit.
Of course, the FSF likes you to assign copyright to them anyway, but failing that, they booby-trapped the license with language which most people have not been aware enough to question. Some true believers like to respond to that with "but I trust the FSF", but that's nonsense: how can you trust an organization that doesn't exist yet, i.e. the future FSF. What happens when Stallman dies, for example?
The fact that the FSF recommended this language is, to me, an example of overzealousness which the FSF should be ashamed of. We see these sorts of tactics used by politicians and legislators all the time. It's disappointing to see an organization like the FSF, which seems to be founded on some real principles rather than "let's see who can grab the most power", stoop to these levels to promote their agenda.
No doubt FSF members and fans would justify this language on a kind of "means justifies the ends" basis. But the problem is that the language in question represents a centralization of power with no real checks or balances. No moral organization should want such a thing.
Perhaps, but the context provided by the other slipups allow me to "condense fact from the vapor of nuance", to quote Stephenson from memory. To me, the overall evidence is pretty clear, and that colors my perception of some of the borderline cases in a way which I think is entirely reasonable. Complicating the analysis here is that some of the responses seem to have been written by a much more fluent author.
Time is for children (which was when I last read it), and for people who prefer colors to words.
Functional illiteracy is to be expected from the managerial class - after all, they have people to take care of such details for them. It's those people who generally make sure that the published output of a well-funded organization is better than the EU example.
Right after the quote mentioned in the other reply, there's "No possibilities to use the Table Of contents for positioning the streaming". "Possibilities" shouldn't be pluralized, and "positioning the streaming" is clumsy, as though translated via dictionary. I'm sure it makes sense in French, or something.
Then there's the repetition of "The live streaming media service of the Council of the European Union", e.g. in the #2 question & answer, which by normal English convention would use an anaphoric referent to avoid the repetition. The final sentence of the #2 answer, "So the answer is: No support for Linux", is beyond casual, it's simply sloppy, and I suspect that phrasing was most likely used because the author couldn't figure out how to provide a definitive response that integrated well with the rest of the text.
To be fair, the third and fourth Q&A are decent. In #5, the use of the word "streamings" is jarring.
#6 says "The users have the choice between...". You can't tell me that's not the work of a non-native speaker translating an idiom from his native language. There are multiple things wrong with that: if you're going to write such a sentence in English, you'd usually just write "Users have the choice between...". However, this construction is not consistent with the question, which says "What kind of player do I need". The response should begin more like "You need..." or "You have a choice between...". Even without that issue, "The users" include the readers of the FAQ, and it isn't normal to refer to the reader in such a stilted third-person way.
I could go on. In general, I find it hard to believe a native English speaker could read that FAQ and not notice any issues (even if they don't know the grammatical terms to describe the issues). Are you a native English speaker? Or are you an author of the FAQ?
I concur with the OP, that's some pretty bad English on that site, including the FAQ page. It doesn't look at all native or casual. Perhaps it's the EU's way of getting revenge on England for not adopting the Euro and suffering along with the rest of Europe... ;)
Yeah, and I bet he's not even trisexual!
The bar is pretty low when "wisest" is a synonym for not being stupid.
I agree.
That's reasonable.
Re the "Debian family", we're arguing about a term without a definition. To me, if a distro is based on Debian (rather than just, say, supporting apt-get as Fedora does) then there's grounds for considering it part of the Debian family. That's a technical or lineage-oriented definition. Of course, if you define the Debian family as those distros that adhere to the Debian Social Contract, then I imagine you cut the family down significantly. Perhaps Linspire and Ubuntu can be considered black sheep members of the family. That's not such a bad analogy: black sheep members of real families have often done something which the rest of the family disapproves of, like violate some religious rule. Sound familiar?
You've given me one example of this, light on detail. If the situation more generally is really as bad as you say, then you have a point. OTOH, I could imagine situations in which it might be in Debian's interests to make changes, even if it seems like a pain to the developers. In the long run, the work that's gone into Ubuntu is likely to benefit Debian, and better compatibility between the two could work both ways. Perhaps another way to deal with Ubuntu demands would be to figure out what Ubuntu can do for Debian, and explicitly ask for that in return. That would make for a more balanced negotiation, and might force Ubuntu to moderate their demands.
As for buying out developers, that's an interesting subject. The implication of your objections in this area is that ideally, Debian developers should be employed (paid) doing something that has nothing to do with Debian, so that there won't be any conflicts of interest. As soon as you have developers being paid to work on something that's related to what they're doing for Debian, there are going to be conflicts of interest, unless they're being paid out of Debian funds. So the question becomes, is having developers funded to work on Debian-related things worth the costs in terms of whatever conflicts of interest might arise? I haven't seen real evidence to argue otherwise. Spats between developers are going to happen no matter what the issues are. If there's a real systemic problem, then it's at least as much Debian's problem to deal with in terms of the general issue of how its developers support themselves, and how it relates to derivative distributions, as it is Ubuntu's.
So Jousselin Mouette says, in effect, "trust me" with no details in an argument that's obviously quite contentious, and I should just take him at his word? It's interesting that he chose not to use his own words to characterize the situation. Perhaps if I knew him personally, I could just accept this at face value, but otherwise, as I said, I'll reserve judgement until I see some facts. The free software community is filled with people whose idealism sometimes gets in the way of their ability to perceive reality, and the personal disagreements often outweigh any rational arguments, too.
Here and elsewhere, you're overgeneralizing from a specific case. Luckily, you are not Debian. I use proprietary Nvidia drivers, on some of my Debian machines - that's my choice, and my right as a user of free software. Should I assume I'm therefore not welcome in the Debian community or even the broader "family" originally mentioned? You obviously have strong convictions, but not everyone shares those exact convictions - even some other Debian users.
My point, BTW, is not about "proselytizing to the masses", but rather that wider distribution of Debian software will be in Debian's interest in the long run, even if it's through derivative distros like Ubuntu. That doesn't mean Debian needs to change what it's doing, except for some members of the Debian community in one area: their tolerance for other people who are using Debian software in ways that free software allows it to be used. Your position is the one which seems against the goals of free software, to me.
Saying Ubuntu and Debian are not the same thing is not the same as saying they're not in the same family. I was mainly objecting to the latter claim, which seems unnecessarily divisive.
As for the point about Gnome, you're quoting someone from Novell who's fighting to avoid losing Suse developers to Ubuntu. I'll reserve judgement until I see some facts. In the meantime, it seems to me that the person paying someone's salary does have some say over what they do with their time. I'll also observe that I'd rather see someone like Shuttleworth involved with a Debian derivative than to see a company like Microsoft involved, the way it is with Novell and Suse.
If Debian had no derivative distros geared towards end users, that would be a bad thing for Debian. I don't think you could ask for a much better end-user distro than Ubuntu, except in a fantasy world, despite Shuttleworth's various personal quirks etc. So yes, I think Ubuntu is an unmitigated boon for Debian. It would be a more unmitigated boon for its community if people on both sides didn't treat the difference as a divisive one, though.
What is your goal in trying to create a division between Debian and Ubuntu? Are you really so committed to "free software" that you can't see the benefit in providing a system geared towards non-nerd users, which in order to fulfill its mission, relies on a few "blobs"?
I'm a Debian user (on my desktop, laptop, servers and handheld), and have no personal interest in Ubuntu. However, I think that the existence of Ubuntu is an unmitigated boon for the Debian community, the Linux community, and the world in general. I really don't see the point in allowing some perfect notion of free software get in the way of providing a good, usable collection of free software to ordinary users. As the saying goes, "the perfect is the enemy of the good".
Please consider moderating your perspective, in the interests of furthering the cause of free software.
Within New Zealand, the Kiwis (New Zealanders) think that "kiwi" means a native flightless bird. But outside New Zealand, the only thing named "kiwi" that anyone ever sees is the fruit. So just as it's necessary, inside New Zealand, to qualify the fruit's name and call it "kiwifruit", so is it necessary, outside New Zealand where no-one ever sees the birds, to qualify the bird's name to avoid confusing it with the fruit.
You're close. Scientists have determined that a solar flare occurs every time Jack Bauer scratches his ass.
By the XXIInd century, there'll be nothing but Walmart!
Y'know, that name never made sense to me. If Firefox is Iceweasel, shouldn't Thunderbird be, say, Raindove?
'ave a Pan-Galactic Gargle Blaster, it'll fix yer right up.
A huge number of them are already available. Google is your friend.