login
Search
Here's an idea that just occurred to me, after all the discussions about motivations, tit-for-tat, authors' wishes and all. If GPLv3 were to have a clause that permitted combination/linking with code under GPLv2, this wouldn't be enough for GPLv3 projects to use Linux code, and it wouldn't be enough for Linux code to use GPLv3 projects. That's because GPLv2 would still demand all code to be licensed under GPLv2, and GPLv3 wouldn't permit this. However, if GPLv3 had a permission to combine/link with code under GPLv2, *and* Linux (and any other projects interested in mutual compatibility) introduced an additional permission to combine/link with code under GPLv3 (or even GPLv3+, constrained by some condition if you will), then: - the kernel Linux could use code from GPLv3 projects - GPLv3 projects could use code from Linux - each copyright holder would still get to enforce the terms s/he chose for his/her own code Does this sound like something that would make sense for your community, so as to maintain/increase cooperation between authors who love GPLv2 and those who love defense for freedom, while respecting each author's not-always-compatible wishes? In other words, does it even make sense for the FSF to consider introducing such a provision in GPLv3, that AFAICT, by itself, would have no effect whatsoever, since an additional permission would be needed for the GPLv2 side? If you were to permit compatibility with GPLv3+ (rather than GPLv3), would you constrain it? Would something like: as long as the later version grants each licensee the same permissions as GPLv2, except for constraining permissions that would enable one licensee to deny other licensees the exercise of the permissions granted by both licenses do, subject to translation to proper legalese (if that's at all possible)? Do you know of any other communities that are like-minded with you, that are sticking with GPLv2, that I could poll about interest in such a provision in ...
... except for that pesky "no added restrictions" part, but hey, who ... because it's For The Benefit Of User Freedoms!!! No. Permission denied. And I don't know of any suckers who would buy that and hadn't been already hooked by FSF peddlers already. If somebody wants to dual-license their code, they can do it just fine. If somebody wants to dual-license *others* code, they can go and play with themselves until they reach RMS-level clarity of vision. -
Respecting the wishes of the author of that code. Are you suggesting they should not be respected? Anyone who's not happy about it can still take that portion out, unless you accept changes that make this nearly impossible, which I suppose you wouldn't given how strongly you feel about this. Without this provision, you wouldn't be able to use the code in the Exactly ;-) Two-way cooperation. I'm told that's good. I was told this was even desirable. I can see that one-way cooperation could be perceived as unfair, even But see, nobody would be adding restrictions to *your* code. You'd only be enabling mutual cooperation with projects whose authors weren't happy about restrictions some licensees could impose on others It is either way. Do you deny that tivoization also benefits one This is not about dual licensing at all, and this is not about others code. This is a decision you would have to make in order to enable cooperation between projects. If you don't want to make this decision, that's fine. Nobody can be forced to cooperate. This works in both directions. Don't try to frame those who want to respect and defend users' freedoms as uncooperative. This is *your* decision, and your decision alone. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
Oh, right. "Anyone who doesn't like proprietary code in the tree Replace GPLv3 with proprietary in your argument and look in archives. ... but not the other way round. So in effect we get a change of kernel license, GPLv3 people *do* *not* get any license changes on their projects. Liar. I'm sorry, but I do _not_ believe that you are honestly clueless about GPL to that extent, especially given your claims of participation of v3 development. What you are saying is "but your code will be still available under GPLv2". Yes, it will. So it will be if e.g. SCO pulls it into proprietary codebase. And you know damn well that this _is_ against the intentions of the license. Besides, changes to code should be available under the same license. The first change in v3 project You know, we have another wanker here starting another thread from hell - one about allowing stable driver ABI, to make the life of proprietary modules more convenient. The funny thing is, it's _also_ said to be for the benefit of users. I.e. it's basically an equivalent It's not an opinion. It's a lack of permission to distribute GPLv2 code Ah. Got it. Nice spin. "Your license doesn't allow to put your code under the license we want, you are mean and uncooperative! Giiiimmeeee!!! Or be condemned as a Bad Person and an Enemy of Freedom" -
Well, you do have proprietary code in Linux, and it's definitely not easy to take it all out, so, point. However, the difference that you appear to be missing is that when you get code under GPLv3, or under this hypothetical combination of GPLv2 and GPLv3 code, everyone who received the combination could still do everything the GPL says they could do: run the code for any purpose, study it, adapt it, modify it and distribute it, with or without modifications, under the same conditions, to the recipient, without imposing any further restrictions. The only thing that changes is that, for GPLv2, there's a possibility that some licensees might be able to get away not permitting other licensees to do the things the license you chose permits them to do, using tricks that have been invented or that became matter of new laws since GPLv2 was published. But this doesn't mean GPLv2 unambiguously permits this behavior; that you want it to doesn't make it so for all contributors. Just like you have the right to veto any additional permissions on Linux, so can other contributors. And unambiguous permission to tivoize is an additional permission, just like permission to combine code with GPLv3 is an additional permission. Heck, even the requirement to provide source code under GPLv1 and GPLv2 is a clarification along the same lines of the new provisions of GPLv3. Denying access to the source code is a restriction on the exercise of the rights granted by the license. So it's implied. But since some people might not see it that way, it's spelled out in full. Same deal with patents in GPLv2, and all the other new provisions with GPLv3. What makes them incompatible is not that they impose new restrictions (they really don't), it's that they remove any doubts GPLv3 people *do* get license changes too. This can be accomplished with additional permissions on both licenses with the current GPLv3 draft. I'm proposing that this backward compatibility could be a built-in feature of ...
My god, you really have come totally unhinged in your attempt to reconcile two incompatible ideas. Ouch. The reason the GPLv2 ecosystem is so strong is that you can take any code under GPLv2 and combine it with any other code under GPLv2 and the result is GPLv2. All you have to check is that the original code is either GPLv2 or a licence that allows conversion to GPLv2, that's it. None of this "Projects" nonsense. Who says what code is a "project" and if it has any special relationships with other "projects" that allow code sharing above and beyond their standard licence terms. Suddenly using other GPLv2 code becomes fraught with "which path did I obtain this licence down" games and either a big fat pile of paperwork or plain not being able to be clear about the licencing of of the code. It's not about projects, it's about the code. Gah. You're not going to make a happy, happy merging code sharing world by fragmenting the licence landscape even more. Bron. -
The reason I mentioned projects was because each project has its policies, around the interests of its own community. Each project can thus make a decision about its own policies, just like Linux has made its own decisions. It was not my intent to suggest that developers in certain projects (communities, groups, however you want to name that) should grant permissions for cooperation with other specific projects, even though this is certainly something that can be done under copyright law. So don't read too much into "project", think of it as "policy in a particular community of developers", and note that the terms I suggested didn't make any reference whatsoever to projects, but rather I don't see how this could possibly be come up as a consequence of my suggestion. In fact, it is my understanding that the path is not relevant, what matters is the terms under which the copyright holders are willing to license their code. That someone might be able to enforce stricter terms upon a combined work is just a consequence of the "most restrictive license" rule, not of the path the code I take it that removing barriers to cooperation in GPLv3 by default is undesirable. Well, then, what can I say? I tried. :-( -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
preferably that you give up. Thanks. --- ~Randy -
There, that right there, wouldn't it again require a 'nod' from all those who have contributed to the kernel (because at the time they did, the license was GPLv2 without any additions)? -jb -- Tact is the art of making a point without making an enemy. -
That's my understanding, yes, but IANAL. Similarly, any GPLv2 and GPLv3 projects that wish to cooperate with each other could introduce mutual additional permissions in the way I suggested, even if neither GPLv2 nor GPLv3 themselves make such provisions. This is a decision that copyright holders can make, in very much the same way that they can make their decisions as to permitting relicensing under newer versions of the GPL, or even older versions of the GPL. BTW, I should probably have made clear that, as usual, I was speaking my own mind, not speaking on behalf of FSFLA or Red Hat, with whom I'm associated, and certainly not on behalf of FSF, with whom I'm not associated. Just in case this wasn't clear yet ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
On 21/06/07, Alexandre Oliva <aoliva@redhat.com> wrote: If you don't speak for the FSF then adverticing the fact that you are a FSF board member seems a little odd. I also fail to see (or at least wonder at) how a board member of the FSF can state that he's not Same thing for the RedHat bit here, along with posting from a @redhat.com email addr. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -
Do you assume I speak for the GNU project and for University of Campinas as well, just because my signature implies that I am somehow What's odd is your assuming that I'm an FSF board member. Especially when there's a URL just next to it that explains what FSFLA is, and how it's not the FSF, but rather one of four members of the network of Yeah, it's really hard to clarify broken assumptions and jumping to Why would this convey the impression that I'm speaking on behalf of Red Hat, tell me. It doesn't even say I'm president, CEO, PR manager, press contact or any such thing... If I posted from my ISP e-mail address, would you assume I was speaking for the ISP? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
My point was that your signature does indicate your affiliation with a lot of different organizations/companies, so unless you explicitly state that you are not speaking on behalf of them it's easy to assume Quoting from that web page: "FSF Latin America is a sister organization of Free Software Foundation (FSF)" So when your signature states that you are a "FSF Latin America Board Member" and FSFLA is a "sister organization of Free Software Foundation (FSF)" that, at least to me, implies some association with No, it does not, but it's easy to mistake a post by someone posting from a company email and including that company in their signature for Of course not. The @redhat.com email is just one more thing, that added together with the signature could lead people to believe you are speaking on their behalf. You were the one who brought up the " I should probably have made clear that, as usual, I was speaking my own mind, not speaking on behalf of ..." bit. I'm simply replying to you that indeed it is not clear for whom you speak with all that info in your signature and the email address you post from. Especially the FSF association seems likely given that most of your emails seem heavily influenced by the FSF cool aid. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -
And then, I did that a number of times in the other recent long thread, whenever I made statements that could be construed as FSF's opinion. Now, this time I missed it, added the clarification just in How does that make me an FSF Board Member, as you claimed at first? Yes, I'm a co-founder of an independent organization that, for sharing the same goals as other FSFs, was welcomed into the global network of FSFes. That we have the same goals does not imply I'm in any way associated with the FSF. Your faulty assumption and your attempts to paper over Indeed, compiler engineers are often the bearers of company's voices. Understood. Thanks for doing that so nicely. I'm glad it's clear now. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
this is standard dual-licensing, not special just becouse both licenses are GPL versions and for people who don't like one or the other of the two licenses this will not be acceptable becouse it would allow someone else to take their work, modify it a bit, and release the result only under the license that they don't like GPL+exceptions is the same thing, you are releasing it under multiple licenses, GPL, GPL + 1st exception, GPL + 2nd exception, GPL + 1st and 2nd exception, etc one of the big problems that people don't realize is that if it takes GPLv3+ exception to be compatible with the apache license it's technicaly not legal to later strip that exception off becouse the result isn't compatible with the apache license, even if the GPL license says that you can. after the code has passed through a couple hands it will be hard for someone receiving the code to know this. I expect a lot of flamage, and bad blood, and possibly a little legal action between opensource projects over the next several years as people realize their code is being hijacked this way. David Lang -
No, seriously, it's not, it's quite different. If you dual-license your code between GPLv2 and GPLv3, I could combine your code with code under GPLv3, distribute it, and if anyone tivoized your code, I might be able to enforce the anti-tivoization provisions against the tivoizer. With a mere permission to combine, I can only enforce these provisions over my own code. I see that, for tivoization, the end result is very much the same as an all-GPL, although the tivoizer still has the option of removing the GPLv3 code and hoping GPLv2's implicit anti-tivoization provisions are not enforced. This would be just undoing the additional cooperation that this additional permission would have provided. However, for other GPLv3 defenses, it would make a difference. For example, on the patent licenses that are implicit in GPLv2 and Which is precisely why I suggested this approach of permission to combine, rather than as dual licensing. Because then nobody could do For the record, it doesn't, GPLv3 is going to be compatible with the apache 2.0 license, no additional exceptions needed. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
What does "my own code" mean when we're talking about derivative works and code in the codebase influencing the design of later code? Code from one module gets copied into another. Code in one module influences the design of code in the kernel. New files are added with pieces from multiple other files. Are you seriously suggesting that the Linux kernel source contain code with various different licenses with an obligation for those who work on the source too keep track of which licenses apply to bits of code when they work on them? That seems impossible as a practical matter. All the kernel code not being available under the same license is a short term problem. Over time, the code will get so combined and interwoven that the intersection of all permitted licenses would soon apply to effectively the entire kernel. This would be no different from adopting GPLv3. Unless, that is, GPLv3 makes itself compatible with GPlv2. In which case it would be no different from doing nothing at all. (Except for all the pain it would cause as people diligently try to figure out what licenses apply to their code and try not to borrow code from parts of the kernel that have a different license from the parts they are working on.) DS -
It already does. All the way from permissive Free Software licenses If you don't keep things clearly separate, yes. I was honestly thinking more along the lines of ZFS as a separate driver than about your bringing GPLv3 code into the core of the kernel. But then, it would be your call either way. This option of mutual cooperation wouldn't work for either party if you're not willing to cooperate, and that's what I believe makes it fair. Now, if you guys can't recognize a goodwill gesture when you see one, and prefer to live in the paranoid beliefs that "those evil FSFers are trying to force me into a situation in which they'll then be able to steal my code", that's really up to you. Don't try to shift the blame of your decisions onto the FSF. One thing is missing the spirit of the GPL and using it to serve a different purpose, without realizing it doesn't provide you with exactly what you want (tivoization, for example); another completely different is to try to put it as FSF's fault that clarifications and amendments are desirable to ensure the ability for authors to enforce Hey, but that was precisely what I was suggesting! Except that it wasn't with GPLv2 alone, because this doesn't work. Each copyleft license insists that it be *the* license. So, in order to be able to combine two copyleft licenses, you need mutual compatibility provisions in both. Which is what I was proposing. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
It's this simple, those who chose the GPLv2 for Linux and their contributions to it don't want people to create derivative works of their works that can't be Tivoized. They see this as a feature, and it's the reason they're not willing to adopt GPLv3. (They want people who receive derivative works of their programs to get all the GPLv2 rights, not just some of them.) I don't see any compromise that means that people don't get all the rights to Linux that the GPLv2 grants as working. DS -
Untrue. Many of us think (and the lawyers are unsure) that it is covered by GPLv2 anyway. Some drivers actually make this clear in their comments about intepretation -
I didn't mean to speak for every single contributor to Linux. I apologize if I gave that impression. Lawyers are almost always unsure of things that aren't well-settled. It's practically a job requirement. However, I think that view is so incredibly bizarre that I can't imagine anyone taking it seriously. Not even the FSF agrees with it, and they have taken insanely expansive views of the scope of the GPL. If the GPLv2 says you can't Tivoize, then Linus is violating the GPL by withholding the keys he uses to sign the Linux kernel source release. No rational argument would defend one point and not the other (unless you add crazy ad-hocery with no support in law or common sense). If you are one of those people, please be consistent and condemn Linus' refusal to release his signing keys and thus "Tivoizing" the Linux kernel. Don't even try to make some kind of counter-argument about signatures that are or aren't functional. Functionality would *exempt* things from copyright coverage, not subject them to it. (And Linus' signature *is* functional. People use it to decide whether or not to run the code. It serves no other purpose than that. Some people will only run kernel code signed by Linus, and my not having his signing key means that my changes can't be run on machines controlled by those people.) DS -
Do you agree that if there's any single contributor who thinks it can't be tivoized, and he manages his opinion to prevail in court against a copyright holder, then it can't? That this is the same privilege to veto additional permissions that Al Viro has just claimed? http://lkml.org/lkml/2007/6/13/293 http://lkml.org/lkml/2007/6/13/354 http://lkml.org/lkml/2007/6/14/117 http://lkml.org/lkml/2007/6/14/432 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
You know, I'm rapidly losing any respect for your integrity. The only "privelege" claimed is that of not relicensing one's contributions. _You_ are perfectly welcome to allow distribution of your code under whatever license you happen to like. So is anybody else (provided that they separate their code from that of other contributors). I cannot do that to your code. Neither can Linus. If Alan sues some company for doing things violating in his opinion his copyright on some of his code *and* wins it, then it's likely to simplify later cases of that kind, provided that situation is similar enough to make the legal arguments used in the first case apply in the later one. If Joe Random Wanker takes your code (in gcc, kernel, whatever) and starts distributing it in violation of conditions set in your copyright *and* you sue him *and* win (which is bloody likely), then further cases of that kind get somewhat easier to win. Not much, actually, since there's already a whole lot of precedents already. What really gets me is that you know it. And you know that just about everyone here knows it. Yet you keep playing with rather pathetic attempts of innuendo and misdirection, when it's bloody obvious that you won't even get a PR win out of the entire mess you've been sustaining for about a week already (seriously, count postings in these threads). The first law of holes: when you are in one, stop digging... -
I'm not sure Alexandre realizes it, but by his carrying on and on and on with his really poorly reasoned arguments (I may disagree with Eben's positions, but he's a much more reasonable debator and advocate for the FSF's positions), Mr. Oliva, Latin America Board Member and Free Software Evangelist, has probably made it made it much more *unlikely* that the Linux kernel will ever go GPLv3. About a week and half ago, Linus was saying he was a pragmatist and if there was a good enough reason (such as if Solaris adopting GPLv3 and there being aufficiently interesting technology that it would be worth the code exchange), there was a chance that he might be for it. But Alexandre has been so annoying and so obtuse, that people's positions have hardened to the point where I doubt kernel developers would be willing to go for at this point. Something that went from being Indeed. Another law of negotiations --- don't goad people into hardening their positions; it helps neither you nor your interests. - Ted -
That always depends which side you really support, whether you want to force someone to wedge themselves in an undefendable corner and so on.. Alan -
Well yes, I'm assuming that the goal is successfully concluded negotiations. If in fact the idea is to force people to wedge themselves into an undefensible corner so that you can blame the failed negotiations on *them*, when it was really *you* who had no interest in reaching a mutually agreeable compromise, then of course that could be a valid tactic. That's a bit of an advanced technique, though; and some might call it a tad slimeball thing to do. Happens all the time in political and labor discussions, though! I hope that wasn't want Alexandre was trying to do, although at times where one could wonder if he was really sent by Tivo to make sure the kernel would stay GPLv2. :-) - Ted -
I guess this means you don't believe what I claimed all the way from the beginning about what I was trying to accomplish. Not surprising, really. Please believe me. I know I'm a terrible negotiator. I know I get people to harden their positions. Why on earth would I, knowing about these shortcomings of mine, get into this debate if my goal were to convince you guys, who'd pretty much all made up your minds months ago, to change anything? This would be utterly stupid. Do you think I'm *that* stupid? Not just a terrible negotiator, but also a stupid liar? :-) I know what I was trying to accomplish. I can even show evidence of that, which you may very well disbelieve. When one of the FSF execs, worriedly wrote to me after reading about a discussion I was allegedly having with Linus on behalf of the FSF http://digg.com/linux_unix/Linus_Torvalds_to_the_FSF_I_m_damn_fed_up, he asked me what I was trying to achieve. On the same day, June 14, I responded that I'd repeatedly made it clear (but apparently never clear enough) that I didn't speak for the FSF, and not even for FSFLA, and that what I was trying to achieve was: - set the record straight on my opinion as to whether GPLv3 changes the spirit of the GPL (it doesn't, not even in the case of Tivoization, as argued in http://fsfla.org/svnwiki/blogs/lxo/draft/gplv3-snowwhite - dispell myths as to other apparent new obligations that people seem to perceive in GPLv3, that were either already present in GPLv2 or that are necessary to better abide by the spirit of the GPL encoded in the preamble - offer evidence that whatever perceived losses the Linux (kernel) community might suffer from switching to GPLv3 would be from non-contributors who are not really willing to abide by the spirit of the GPL chosen by the Linux authors, and that it would rather be more beneficial for Linux because it would push the exploiters away while making room for more actual contributors Now, since I ...
That was a given from the start. The spin that there was any chance whatsoever it could possibly happen was just that. Even if Linus could possibly consider this, others have made it pretty clear that this was never an option for them, and Linus' explosion at my first one-liner intervention on GPLv3 isn't exactly a sign of being considering something reasonably. So, no, as I've repeatedly stated, I wasn't here to convince anyone to adopt GPLv3. I know you won't believe me. I don't care. I was here to dispell the lies that were being spread about GPLv3, the spirit and the goals of the GPL, as far as I understood them. I knew from the start that it was an uphill battle, and that I wouldn't be able to convince those who distrusted the FSF so much that they would listen to anything that resembled an FSF discourse with an extremely high rejection level. This was all expected. I wasn't here to convince them. I knew I wouldn't. I was here to set the record straight on the spirit of the GPL, not towards the most vocal opponents, but for others who hadn't formed an opinion, prejudiced or not. I was here to inform about GPLv3, not to push it. That I was perceived as pushing it is not surprising at all. The perception of "being forced" whenever something resembling the FSF ideology comes up is so strong here that some people just stop listening, stop thinking rationally (limbic system take-over?), or even get into outright name calling. No surprise here. I knew this was hostile territory, and I came prepared for this. I feel I have accomplished my goal: I've informed a lot of people about the GPL, about GPLv3, about Free Software and even about the FSFes. Whether they make a decision for GPLv3, GPLv2, or more liberal Free Software licenses, is up to them. Now, people who'd only been exposed to the prevailing views in this list can take something different into account, and make more-informed decisions. Thanks for listening. o-o -- Alexandre Oliva ...
News flash: almost no one except for you cares about the "spirit of the GPL", and it was not on that basis that people decided that the So the fact that you keep talk about the general case, when in fact the concern was about the specific case of the Linux kernel, certainly DID make it seem like that you were pushing it. THE GENERAL CASE IS OUT OF SCOPE FOR THIS MAILING LIST. And no, it's not a perception of "being forced", it's was a matter of consuming huge amounts of bandwidth on a topic which was out-of-scope for this mailing list. And the only topic which was in scope (whether or not GPLv3 was appropriat for the Linux kernel development Great. So can we please END this thread? Thank you. - Ted -
Just because someone has a different opinion than you or the FSF does not make what they say a lie. Is that particularly difficult to understand? It is exactly this kind of nonsense that makes people not Well what the spirit is, is certainly debateable, and it seems there probably won't ever be a consensus on that. The thoughts in the head of Any organization that claims anyone that doesn't agree with its view of thw world and its interpretation of some written text is "confused" will be treated like all other religigous fanatics, and not listened too. Intelligent people know better than to listen to such groups. Some of us really can think for ourselves and don't have to be spoonfed I think I know exactly as much about the GPL now as I did two weeks ago. Repeating the same arguments to people again and again when they consider the argument invalid isn't going to change their minds. -- Len Sorensen -
As a general statement, yours is absolutely correct. However, the situation at hand is quite different AFAICT. It's about people repeatedly making statements that misconstrued the intent of a third party, even after having been drawn attention to this. AFAICT, both elements needed to characterize lying are present: deviation from the truth, and intent to instill the incorrect statements on others as if they were true. Now, it might be that those making such statements hadn't fully realized what they were writing on was on others' intentions, rather than objective facts or their own opinions, and that they didn't realize they were misrepresenting those intentions before I brought this up here. In this case, if they confirm it, I'll be delighted to If you misunderstand what 'the spirit of a legal text' as something other than the intent of whoever wrote that document, then yes, it is debatable. You may want to take up the alleged inaccuracy to Wikipedia: http://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law When one obeys the letter of the law but not the spirit, he is obeying the literal interpretation of the words (the "letter") of the law, but not the intent of those who wrote the law. Conversely, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ when one obeys the spirit of the law but not the letter, he is doing what the authors of the law intended, though not adhering to the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I suppose it thus follows that people will then take this perception further and selectively ignore portions of texts written by these parties. And then become frustrated and complain when their conclusions don't match those that are evidently encoded in the portions that were ignored by them. And then complain when they're misunderstanding the text, or when they're characterized as confused, or however else their selective attention and its misleading Ignoring facts that don't fit your ideology, or that support an ideology ...
Interesting scenario, it seems to comply with GPLv2 on the surface. If that kernel doesn't actually allow access and wipes the source partition to use it as swap on first boot, then no machine is actually capable of reading the source. So it isn't really machine readable. Another gripe is that encrypted media are not customarily used for software interchange. So that's 2 (minor) strikes where this method of distribution doesn't seem to match the language of section 3a. You also cannot interpret the encrypted partition as source code because a bit further down in section 3, it defines source code as, "The source code for a work means the preferred form of the work for making modifications to it." So now we get to section 6. The recipient receives a license to copy, distribute or modify. You may not impose further restrictions on these rights granted herein. You could argue that they do not restrict copying, distribution and modification of the sources in general, only of the specific copy they distribute. However here we go back to section 2 which states that their modified copy is a derived work which must be licensed under the GPLv2, so that would make it specific enough that recipients have in fact been granted the right to copy, distribute and modify the copy of the source of that corresponds to the distributed binaries, which is restricted because of the encryption which prevents the user to copy, Not a really interesting question if the method of distribution violates the letter of the GPLv2, is it? They get sued for copyright infringement because they are not in compliance with section 3 and the sources are released as a result. Jan -
Granted, that was just adding insult to the injury ;-) Assume the sources are kept in the encrypted disk. Or that the sources are shipped in an encrypted CD, that only the machine itself That the whole disk is encrypted is "just a technical detail". And it's not the media that's encrypted, it's the data in it. Surely both hard disks and CDs are media customarily used for software interchange. And there is often compressed and encrypted data and The encrypted partition is not the source code. It contains the source code. Very much like the computer, or the disk, or the boot partition, is not the GPLed program, it contains the GPLed program. That it's encrypted, signed, or hardware-protected, have all been claimed as reasons why they're outside the scope of the GPL and can be "We don't oppose that you do any of these things, once you get the source code. We just make it difficult (hopefully impossible) that I don't think a copyright lawsuit can be generally expected to obtain this result. A court can stop the distributor from distributing in an infringing manner, but I don't think a court could force the distributing party to shell out source code. The distributing party might not even *have* source code in the first place. And even if she had, she might have no right to distribute it. Or she might not want to, and then a court *might* require them to do so, but that would be quite unusual. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
Actually, they could even claim you don't need the source code to make modifications. The license even says the source code is the most convenient form to make modifications, not the only form. Now, that the others suck rocks is not their fault, is it? ;-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
GPLv2 section 3.
The source code for a work means the preferred form of the work for
making modifications to it.
I believe this states that the source code has to be in the preferred
form for making modifications and not some other form that sucks rocks.
As far as your argument that making it difficult or impossible to obtain
the source code could be in compliance. I don't see how (intentionally)
making something difficult could not be interpreted as a restriction so
it still violates section 6 of the GPLv2.
And yes, I do realize that you intentionally tried to come up with your
example to somehow bring tivoization to the source code. However
although the GPLv2 doesn't address the freedom to use (and specifically
does not grants the user a right to run a modified version of the
program on some specific piece of hardware), it does (try) to address
the recipients rights to copy, distribute and modify.
Jan
-
Yes, but in the scenario I proposed, the source code *is* in the preferred form for making modifications, it just so happens to be behind a barrier you cannot trespass. This is not different from shipping binaries and sources in a CD inside a locked box that you can't open. You've received both, but how is the fact that you can't reach the source code (or the binaries) a violation of the GPL in this case? And, if it's not a violation, what is it that makes the case of shipping programs in a locked enclosure different from shipping them in a locked computing device? As for making modifications, I'd like to take this opportunity to withdraw, for purposes of interpretation, my earlier agreement that TiVo permits modification, even though it doesn't permit modification in place. I don't see any distinction in US copyright law between modification in place and modification by creating a separate work. This distinction makes sense for some cases of modification of software, but it doesn't make sense for other copyrightable works, such as sculptures, paintings, drawings, etc. When you modify a sculpture, you're modifying it in place, and this requires as much copyright permission as creating a modified copy of it. Both count as modification. And if TiVo creates artificial obstacles to your modifying the copy of GPLed programs that ships in its devices, then I believe it counts as a restriction on modification. I ought to be entitled to modify any bit in the executable and expect that to have the same effect as modifying that bit on that executable on any other computer. The fact that it stops working as a result of TiVo's design to prohibit modification, rather than by any other differences in the computer (e.g., the absence of the signature checks), just goes to show that there is intent to impose further restrictions on modification of the software. Saying that I can modify the sources and build another copy of the binary and then install that, but then it won't ...
Behind a barrier is not the preferred form for modification. Encrypted with I honestly don't see what relevance this could possibly have. Getting access to the source is a fundamental GPL right. The GPL is clear that you cannot Of course your nonsense view leads to nonsense results. What a surprise. By this argument, shipping a GPL'd work in ROM would violate the GPL because you cannot easily modify that particular copy. Burning a GPL'd work to CDROM would also be a violation. (See below for why your 'artificial' distinction Nope, sorry. If this were true, you ought to be entitled to modify a bit in the Linux kernel and have it have the same effect as modifying that Linux kernel on my desktop. Again, nonsense view leads to nonsense conclusions. The fix is to reject the nonsense view. There are no special GPL rights to Intent is not the issue. The GPL does not care whether you intended to comply or why you cannot comply, it just cares whether you do or don't comply. If modifying software in this way is a GPL right, then anything that prevents you from modifying software in this way is a GPL violation. If you can't distribute so as to give all GPL rights, you can't distribute at all. If the GPL says I can modify my distributed copy, then distributing on CDROM is a GPL violation. It doesn't matter what your intent is. If you can't distribute so as to honor all GPL rights, you can't distribute. It is mind-bogglingly obvious that any sort of "right to modify one It doesn't matter. The GPL does not distinguish between artificial restrictions and other restrictions. It doesn't permit *ANY* further restrictions on GPL rights. If you can't grant all the rights (whether due to artificial restrictions or other types of restrictions) you can't distribute at all. You are wasting an awful lot of time and effort analyzing things that have *NO* GPL consequence at all. DS -
Where does it state that there must not be a barrier? I see it saying Indeed, but why does it matter? In a CD is not the preferred form for making modifications either. In fact, in the CD, you can't modify it at all. What's *behind* encryption is the source code, along with the I've already explained that the inability to modify what's in the CD is not a restriction imposed by whoever recorded the bits in there as If your desktop is sufficiently similar, and the kernel binaries are 2. You may modify your copy or copies of the Program or any portion It doesn't state "you must distribute sources in modifyable media", it says "you may modify your copies, and the distributor must not have imposed restrictions on your exercise of this right" If you can't modify your copies because others get in the way, too bad. If you can't just because the distributor stops you, there's a Please read the license instead of assuming you know what it says. Let's just say I honestly hope you are right and I'm wrong. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
Behind a barrier is not on a medium customarily used for software On a CD is a preferred form for making modifications to it. You are assuming "it" means one particular copy of the source code when in fact "it" means It makes no difference who imposes the restriction. Read section 7 carefully. If *anything* imposes restrictions on the recipient's exercise of Because you have no way to get that software to run on my desktop, just as This is pretty clear that no copy is special. In any event, this is a grant No, read section 7. The GPL does not just prevent you from imposing further restrictions, it also prohibits you from distrbuting if *anything* imposes such restrictions. Otherwise, you could get around the GPL just by having You are now directly contradicting yourself. We agreed that if anything prevented your recipients from exercising your GPL rights, that means you cannot distribute. How you are saying so long as you don't stop them, you can distribute. In fact, the former view is correct and the latter is wrong, as GPL section 7 makes clear. If the right/ability to modify a particular copy is a GPL right, then you You are confusing a grant of license with an assurance of ability. Section 2 is a grant of permission. If we were to read "may modify your copy or copies of the Program or any portion of it" the way you suggest, that would mean that you must be able to modify every single copy of the program that is distributed to you. This would make distribution on CDROM a GPL violation, which you agree it isn't. So this I am, and you are. DS -
Are you per chance claiming that you've never heard of anyone It says the sources must accompany the binaries (check), must be machine-readable (check), and must be on a medium customarily used for software interchange (check). Where does it say you have to be able to access the sources? Or the This is actually not what section 7 says. If it were so, the GPL would forbid you from distributing any software whatsoever, because it might reach someone in the US who would then be forbidden by law from distributing it to someone in Cuba. It would forbid you from distributing cryptography software, or DVD descrambling software, because the software might reach someone in a country where their distribution is illegal. Or it would forbid you from distributing software that is covered by some patent in some distant country, just because the software might reach a person there who might then be stopped by the patent holder from distributing the software. But the GPL doesn't forbid any such things. The GPL stops you from distributing the software when you impose the restriction yourself, or when you are required by a third party to impose such a restriction. For example, when you accept a patent license that states you won't permit downstream users to distribute the software, then you become a party that impose restrictions. If you don't have the source or written offer needed to comply with the conditions of section 3, then you can't distribute the software. It's Aah, I misunderstood what you wrote. Yes, as long as you are entitled to stop me from modifying software on your desktop, then I'm not entitled to modify it. However, once I'm entitled to make an identical change to the identical software running on both your (or my) desktop and another nearly-identical computer, if they behaved exactly the same before the modification, I'm reasonably entitled to expect them to do behave exactly the same after the modification. If they don't, and I find out that it's ...
It isn't common. In fact, I can only think of *ONE* instance of this - that of the original Quake 1 "Demo" CD that, when given the proper unlock codes, Section 3 doesn't apply to this situation. However, other sections do. They are distributing in line with the distribution requirement, but not the "modification and copying" requirements. These are granted early in the license and covered by the "no further restrictions" clause. You have to be able to copy and modify the source code for it to comply with the GPL. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -
Let's hope courts see it this way. But then, why is it that I can't use hardware to stop someone from copying or modifying the source code, but I can use hardware to stop someone from copying or modifying the binary? Or is that not so? Remember, section 2 talks about modifying *your* *copies* of the Program, without any reference whatsoever as to whether they're in source or object form. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
I'm sure they will. Section 0 of the GPLv2 states what the license covers. As has been repeatedly stated, on a TiVO or similar device they can stop you from running a user-built binary. They cannot, and do not, stop you from accessing the copy on the disc. They don't even prevent modification of it. I can't argue with this. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. -
You can use the hardware to stop someone from copying or modifying some particular copy of the source code, so long as there is some copy of the source code they can copy and modify. You are equivocating between a particular copy and any copy at all. The GPL requires the source code to be provided in a customary way and be the preferred form for making modifications. It grants you the right to copy and distrbute the source code. One accessible copy and no copyright impediments should be all you need. The "further restriction" section solves the issue of various workarounds to this. Having access to the source code, being able to copy and modify it, being able to incorporate bits of the source code in other GPL projects -- these are all fundamental GPL rights. I do not see how anyone can get away with I agree. You have the legal GPL right to modify any copy of a GPL'd work, provided no technical or authorization obstacles stand in your way. If the source code is on CDROM, you cannot modify that particular copy even though you have the legal right to modify "the source code". You have the right to copy it to someplace where no obstacles prevent you from modifying it. The GPL grants you a right of access to the source code that is a genuine guaranteed ability. The GPL also grants you the right to modify the source code, but that is a legal right, not a guaranteed ability. The GPL does sometimes use the word "may" where it's not clear whether it means you have permission or you must be able to. The general rule of construction is that "may" means permission, unless there's some clear indication to the contrary. The "may"s in sections one and two are permisssion against a claim of copyright enfrocement. The "further restriction" clause is, at it states, only on the exercise of *rights* (which I think means those rights licensed to you under copyright law, namely the right of distribution and copying). DS -
Hey, why stop at these excuses to stop someone from modifying copies ... and modification and, depending on the jurisdiction, execution. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
Modification, yes. Execution, well, if the rules of a jurisdiction are insane, you will get insane results from almost any contract. Fortunately, the GPL makes it clear that execution is unrestricted for GPL'd works, but does not style this as a GPL right. One would hope that jurisidictions that have such strange rules would interpret the GPL to effect the same result under their laws as was intended under the laws the GPL was written with respect to, to the extent possible. Treating ordinary use as a copyright privilege leads to nonsensical results no matter what you do. For example, you get that I can drop copies of my poem from an airplane and then sue anyone who reads it. DS -
Possible consequence: Who was talking about reading? You can read programs as much as you can read poems. But since you (normally) can't run poems, copyright law doesn't talk about this, just like it doesn't distinguish source from object code of a poem. But software is different. So different that it's governed by a separate law in Brazil, which could be qualified as a subclass of copyright law. And this law states that running programs requires permission from the copyright holder. If you find that odd, you may have an idea of how ludicrous patents on software, business methods et al are. At least copyright regulation of execution saves us from a few abusive EULAs, created with the purpose of, let's see, regulating execution. And then, since it's already there, why not use it for other restrictions beneficial to the vendor that a copyright license couldn't establish? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
They are both ordinary use. It is crazy to treat the ordinary use of a work as a copyright privilege. If you do this, you get insane results. For example, coloring in the pages of a coloring book is, arguably, creating a derivative work. But you don't need a license to do this, because it's the ordinary use. My poem from airplanes example is just an example. You get analogously crazy You get lucicrous results from copyright laws if lawful physical possession (of a copy made with consent of the copyright holder) does not grant the right to ordinary use. You get the same ludicrous results with patents (imagine if I can buy a product from IBM whose ordinary use always violates an IBM patent and then IBM can sue me for it or if they use this to prevent So do I have to buy a program and then negotiate the right to run it Quite the reverse. If execution is a copyright right, then I might need to agree to a license or conract to get it. If execution is not a copyright Jurisdictions that treat ordinary use as a copyright right are simply insane. I am probably one of the stronger supporters of intellectual property rights (copyright and patent, not necessarily UCC and EULA issues) that you will find on this list, and I think that treating ordinary use as a right is simply insane. DS -
If you buy the program, then you become the copyright holder. I assume you meant buying a license. In this case, especially in the case of off-the-shelf non-Free Software, the license likely grants you permission to run the program, otherwise why would you pay for the Whoever gave you the copy you lawfully obtained is already subject to and/or able to offer a copyright license anyway. If the copyright holder wants to restrict your ability to run the software, whether copyright covers this case or not is absolutely irrelevant. And evidently some businesses have interests in restricting your ability to run software, not only to be able to sell you multiple licenses of non-Free Software, but also to turn Free Software into How do you reason about binary-only software fulfilling the goal of copyright? How does it deliver its part of the copyright deal with society if, even after it goes public domain, still nobody can create derived works from it because the source code remains unavailable? http://www.fsfla.org/?q=en/node/128#1 -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
I stand by my claim that any obstacle to obtaining and modifying any copy of the source code (and thus encumbering your ability to use it at all) would be a violation of both the letter and the spirit of the GPL. (As expressed in section 3.) Until someplace you can't actually access the software is customarily used for software interchange, ... But I fear that your interpretation of section 7 is mostly correct. This is a defect in the GPL. At least as I understood it, the intent was to force distributors to remove any code for which there was a patent claim that might threaten redistribution. Section 7 fails to do that. While you are granted rights under copyright, section 7 does not prevent people from using other laws (so long as they don't impose the restrictions or agree to them) to hamer your right to redistribute (or for those who receive a distribution from you to lawfully use the work). It is quite difficult to actually arrange this. You would need something like a third party to indemnify your customers without your having to agree to such indemnification. DS -
It's not intended to do that. The existence of a patent doesn't render the Software non-Free. The patent holder's threats or willingness to enforce it doesn't render the Software non-Free. It's accepting a restrictive license, voluntarily or by means of a court order, that does. And the GPL is not about anything but doing as much as a copyright license can do to make sure the covered Free Software remains Free for all its users. So, requesting licensees to not use their patents to deny other users' freedoms is something a copyright license can do. But since it can't affect patent holders that are not copyright licensees, or any other legal mechanisms that non-licensees could use to restrict users' freedoms, it remains silent about this, rather than forcing licensees to comply with laws or avoid risks that ... and without making you a party in this collusion. Basically, if you're involved in the process of denying users' freedoms, the GPL may have teeth for you. If you're not, and you're not a licensee of code present in that software, there's no way the GPL can stop you from imposing whatever restrictions that law permits you to impose, if you choose to do so. But the GPL won't impose restrictions on others just in case their downstream users might become your next target. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
That was explained in next paragraph where I said that preventing access sure sounds like a restriction on copying and modification, which is That doesn't really matter because the GPLv2 makes a distinction between source code and binary object code. For instance in section 1 where it says that you may copy and distribute the program's source code. In section 2 where it talks about modifications it at first doesn't seem to distinguish between source and binary, but it doesn't grant the right that the resulting modified program will actually work. And yes, you can still modify the kernel binary on the Tivo harddrive, it just won't boot with the standard bootloader. But there is an explicit no warranty clause in the GPLv2. Which I believe is a good thing. If the license tried to enforce usability, i.e. "continued functioning of the modified object code is in no case prevented or interfered with", then any time a new release of the program causes a regression for some users this would be a license And when you scribble in the margin of a book you are also modifying it, so what. I don't think you even need copyright permission, although you will probably get into trouble if the book was borrowed from a library. You can modify the source, recompile it, even binary patch the kernel on the Tivo's harddrive. None of that is restricted. What is restricted is the freedom to run the modified object code on Tivo's hardware. That right is not granted by the GPLv2, and fitness for any purpose is explicitly disclaimed in the NO WARRANTY section. ... skipped a whole bunch, you actually repeated yourself a couple of times but the same answer applied, GPLv2 does not grant the right to be able to run the (modified) program on their hardware, and none of the I'm assuming no written offer for access to the software is included. Source are inaccessible, restricted the recipients rights to copy, distribute and modify the source code, GPLv2 violation. otherwise, source is accessible ...
Yup. But will courts see this as a valid excuse for effectively denying users the ability to modify the copies of the GPLed programs they run on tivoized devices, even though the means to accomplish this are based on blocking the ability to run the modified executable, which happens to not require permission from the copyright holder in the US? Even more so when the modified binary provably works just fine on similar computers, and fails to work on the tivoizing device just because mechanisms were introduced to stop the user from modifying the behavior of the software that runs in the device? I.e., it fails because you changed it, rather than because you broke it. Couldn't this be understood by a court as an attempt to exploit a loophole in the letter of the license, rather than as an intentional permission to restrict the ability to run covered programs, an act that the license phrases as "not restricted" and "outside its scope" just because US copyright law doesn't demand permission from the copyright holder to run programs, which results in permission to run being outside the scope of a copyright license? Anyhow, I didn't mean to restart this debate, I just wanted (as stated above) to withdraw my earlier tentative agreement that "modification in place" was something that could be forbidden without infringing Maybe it's fair use, especially for a printed book, of which many Relevance was only to counter the argument that the right to "modify in place", as some put it, was not covered by the GPL, "because that's not how copyright law defines modification." I bought that argument at first, but then I referred back to US copyright law and not only failed to find supporting evidence for this argument, but actually found opposing evidence. So I brought it up to make sure my tentative agreement wouldn't be used in a court as an indication that the So, the same standards would apply to the binaries: if they were inaccessible, copyright holder could claim ...
I'm not sure my point was clear (not even to myself), so let me try to clarify with a slightly different scenario. Software vendor places Free Software program for sale on a web site. Customers pay a fee and are granted access to a web page from which they can download both binaries and sources. The web page encourages them to download the sources first, because, one hour after the download of the binary completes, the password that grants access to the web page and to the downloadable bits is revoked. Sloppy customer downloads only the binaries. Days later, they decide they want to hire someone else to modify the software for them. Then they realize they don't have the sources, and that they declined the opportunity to have them. So they can't reasonably modify the software, or distribute the software for another party to do it for them. They got themselves into this situation by declining the source download. The software distributor is not imposing a restriction, it's the copyright holder that is, through the license. Now, compare this with the case quoted above, in which the computer, on behalf of the customer, declines the source download. Clearly the license stops the user from distributing the software in these circumstances, and practical matters pretty much stop the user from modifying the software for any other purpose, but how is this different from the unquoted case above? Can one actually claim that the tivoizing vendor is imposing a further restriction, even though the restrictions actually stems from a decision made by the user (or rather by the computer acting on the user's behalf), and from the copyright holder? How could this be phrased as a further restriction, if the license already restricts distribution without source code, and concedes that not having the source code makes it nearly impossible to make modifications? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member ...
http://fsfla.org/svnwiki/blogs/lxo/2007-07-01-gplv3-tivo-and-linux.en -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
No, this thread was about additional permissions to combine with other licenses. I didn't suggest anything about relicensing whatsoever, that's all noise out of not understanding the suggestion. You objected to granting additional permissions. You have that right, per copyright law, and the other developers can then decide between not granting an additional permission or removing all the code you contributed such that they can. That's veto. Similarly, if someone proposed an additional unambiguous permission to tivoize under GPLv2, any developer who objected to it could veto it Yes. The only disagreement is that I'm talking "additional permission to combine" and you seem to keep understanding "relicensing", even though these are very different concepts, with significantly different consequences. What they have in common is that you can veto either one with your status as copyright holder, and that they would both permit some forms of cooperation. Permission to relicense would provide for one-way cooperation out of Linux. I'm not proposing this. That would be stupid. You've already decided about it. I respect that decision. I even understand why you made that decision. Relicensing would provide for two-way cooperation, but under terms that you don't consider acceptable. You've pretty much already decided not to do it. I respect that decision. I even understand why you made that decision. Permission to combine in both sides would provide for two-way cooperation in ways that enable each author to enforce the terms s/he chose for his/her own contributions. This would address many of the concerns raised about relicensing, and would increase the amount of contributions in kind you can get. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
And that constitutes the change of license. If you *really* do not understand that, I'd recommend asking FSF legal folks, especially since you have mentioned working on v3. And that, BTW, is far more serious detail than your affiliation (or lack thereof) with FSF. Don't forget to bring a copy of your posting that had started this thread when you talk to them. And really, stop digging. Please. YANAL. You are definitely not in position to offer any specific changes in v3. Are you seriously expecting an ACK on your handwaving, when conditions mentioned in your patch to license are not just vague as hell, but are 100% certain to be interpreted in conflicting ways as shown by the previous thread? What are you expecting, anyway? "You guys can link to v3 code if you read v2 as prohibiting tivoization, otherwise the code is withdrawn" != "some people think that v2 prohibits it, some do not". And somehow I doubt that this change of situation will make the latter happy. Besides, what you are suggesting is logistical nightmare. Somebody in v3 project changes borrowed v2 code. Result is pulled back into Linux. What is the license of that thing? v3 with additional permission? v2 with additional permission? What happens if code is then rewritten, with some pieces remaining from v3 changes? Oh, you want to deal only with entire modules? And then both sides need to be damn careful not to copy pieces across the module boundary? Suppose ZFS _is_ pulled into the tree via that mechanism. Just what will happen if some code is massaged a bit, found generically useful and lifted into a helper function? Do other filesystems (v2 ones) calling it suddenly get into patent violations? Just what makes you think that anybody would like that kind of "cooperation"? -
I stand corrected. I misread what you wrote as "relicensing under Or even kept outside, such that third parties can create a combined work and distribute that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
Wouldn't that defeat the entire purpose of the GPLv3? Couldn't I take any GPLv3 program, combine it with a few lines of Linux code, and Tivoize the result? The fundamental problem is this: Any proposed mutually compatible license must either permit or prohibit Tivoization. If it prohibits it, then it's no different from changing the kernel license to GPLv3. If it allows it, then it's no different from the GPLv2 and it would be suicide to the whole purpose of the GPLv3 for it to be compatible with it. DS -
No. This is not permission to relicense. This is permission to combine. Each author still gets to enforce the terms of her own code. So a tivoizer would have to take out the code licensed under the GPLv3, and use only the code that permits tivoization. Same as today, but without the possibility of cooperation for licensees who don't tivoize. Sorry if this wasn't obvious, it was for me. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
This makes no sense. We are not talking mere aggregation here, we are talking developmental convergence. If I wrote some code that was in the Linux kernel, how can I enforce the terms of my code (guaranteed write to I am baffled how this could possibly work. You understand that the GPLv2 specifically guarantees that any derivative work will be Tivoizable and the people who chose the GPLv2 specifically want it that way? If I chose the GPLv2 over the GPLv3 as a conscious choice, that means I want people to be able to Tivoize any derivative work made from my work that is distributed. DS -
In just the same way you'd enforce it today: with help from a lawyer Yes. And the GPLv2 code would remain that way. If GPLv3 had this provision I suggested, and you wanted to cooperate with some other project that offered GPLv3 drivers, then you could use them by adding the mutual-cooperation provision I suggested. Of course you're free to not want to cooperate with anyone else who This provision was not intended to prevent anyone from tivoizing your work or derived works thereof. It was only intended to enable you to use code from GPLv3 projects as long as these GPLv3 projects could also use your code. Mutual cooperation, as opposed to no cooperation whatsoever. I *think* lawyers would probably recommend you to keep code under different licenses in separate files, like you already do with code licensed under GPLv2-compatible licenses. I *think* that, with this pair of mutual cooperation provisions, you could even use code licensed under the Apache 2.0 license. And OpenSolaris drivers, if it's licensed under GPLv3. And you wouldn't be departing from your intent to enable people to tivoize your code, which you currently choose not to enforce even though GPLv2 might very well enable you to; you could keep on cooperating with people who understand GPLv2 doesn't permit tivoization, and you'd be able to establish mutual cooperation with people who choose a license that makes this point clear. It's not like anyone can safely tivoize devices with GPLv2 already, so refusing to cooperate with GPLv3 on these grounds buys you nothing. It is only a public statement of refusal to cooperate, with you are entitled to make, even if it comes off as silly because you chose a license that already contains the provisions for "complete corresponding source code" and "no further restrictions on the exercise of the rights granted by the license" that tivoizers fail to comply with. At which point one gets to wonder why you chose this license in the first place, if it doesn't ...
So you really didn't pay any attention to anything people told you?
Ok, here are the relevant parts from GPLv2,
The precise terms and conditions for copying, distribution and
modification follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0. ... Activities other than copying, distribution and modification
are not covered by this License; they are outside its scope. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6. ... You may not impose any further restrictions on the recipients'
exercise of the rights granted herein. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
11. ... THERE IS NO WARRANTY ... INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The license does not grant the right that you will be able to run the
software on any particular platform or whether it will even work at all.
You are only granted the rights to _COPY_, _DISTRIBUTE_, and _MODIFY_.
Only if the terms of your contributions are conflicting with the terms
of the GPLv2 and you are not willing to dual license your code. There is
no need to take out contributions because the GPLv2 does not prevent
tivoization.
Although you did license your code under the GPLv2 and as such gave the
permission to freely copy, distribute and modify, I think most kernel
developers will respect the wishes of the original author if he really
GPLv3 adds additional restrictions, which the original authors did not
want to impose on their licensee's otherwise they would have licensed
(or would re-license) their code as GPLv2+.
A mutual compatibility agreement (sublicense) would effectively
terminate any rights granted by the GPLv2,
4. You may not copy, modify, sublicense, or ...Yes. Particularly to what Alan Cox and his legal counsel told me. A single copyright holder able and willing to enforce the license against tivoization is enough. What part of this don't you It doesn't grant TiVo the right to distribute the program without corresponding source code. They fail to distribute the source code to the functional signature derived from the kernel binary. Kaboom! As for the right to run the program, I've also explained why in Brazilian copyright law this is a right granted by the license, because the license says that right is unrestricted. Says you (or perhaps you're just repeating what you heard and want to believe). But what did your lawyer say about it? In reference to which Additional permissions to combine are not permission to relicense. Look at section 13 of GPLv3dd4 and of Affero GPLv3dd1. That's the sort of additional permission I'm talking about here. The same kind of additional permission that GPLed projects that use openssl adopt. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
A signature is not a creative work and as such not covered by copyright. At the moment the only protection that the signature/key has is that of a trade secret, the GPLv2 does not cover that type of intellectual propery and does not grant the licensee access to trade secrets. Show me any case law that indicates otherwise. Maybe the content producers will at some point manage to establish that encryption keys and signatures are somehow copyrightable, but until a court of law No, the license says that it does not address the right to run a program, and states that the license does not impose restrictions. That is quite different from saying that the right is unrestricted. I'm talking about the GPLv2, so it doesn't matter what the GPLv3 says wrt. additional permissions. Even if GPLv2 and GPLv3 grant the same freedoms (permissions), the collective work would have additional restrictions because of the GPLv3 code and as such the combined work would result in a sublicensing of the GPLv2 licensed code, which is If they are the original author they can make that decision, just like authors can dual-license, or decide to license their code as GPLv2+. It is kind of funny how they phrase the exception as granting permission to link against OpenSSL, where in reality they accept the added restriction that results from the advertising clause of the BSD license. (i.e. instead of granting you an additional freedom, they chose to remove the freedom to modify the part of the code that advertises). However with the openssl case there is no tight coupling because openssl is a separate library. Some people have argued that the LGPL was never really necessary because (unlike static libraries) shared libraries are still separable from the GPL'd program. Furthermore, those projects are not pulling individual source files from into their project. There are also alternative crypto libraries (gnutls, nessie) which can in many cases easily replace the openssl dependency. Finally the ...
Great, so for ever and ever afterwards the code would have to keep a clear separation between the bits that are under different licences and make sure that no re-factor ever blurred the lines between them enough that you had trouble telling which was which. And don't even get me started about some poor innocent end-user who just wants to use some code from your mutant frankenstein "project" in her pong game (or was it tetris, I lose track of what you're supposed to be playing on your hacked TiVo while it's not allowed to connect to their network any more) and understand what licence the final work is under. Ouch. Bron. -
As long as you care about being able to tell which is which, yes. I can understand why, under some circumstances, this might be taken as worse than not being able to use code under GPLv3 (or any other If it's a mingled combination of code under GPLv2 plus permission to combine with v3, and GPLv3 plus (potential built-in?) permission to combine with v2, these are the combined terms. You can still use it with code under GPLv2 plus permission to combine with v3, and with GPLv3 plus (potential built-in?) permission to combine with v2. I can see that it boggles the minds not used to this kind of combination. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -
