Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Jun 28, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: >> So, let's narrow the scenario to: tivoized machine downloads binary >> from protected site, refrains from downloading sources that it could >> download, user can still access and copy the binaries, but can't >> obtain the sources because the machine opted not to get them. >> Now, the user can't distribute the binaries, because doing so without >> being able to get the sources to pass them on would be copyright >> infringement. Would a court see this as a restriction on distribution >> imposed by the distributor? Or by the copyright holder? > I'm not sure my point was clear (not even to myself), so let me try to > clarify with a slightly different scenario. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 30, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> 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. > So do I have to buy a program and then negotiate the right to run it > separately? That seems very crazy. 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 license anyway? >> 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. > 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 > right, then I am safe from such craziness. 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 non-Free Software. > I am probably one of the stronger supporters of intellectual > property rights 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> > 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. > Who was talking about reading? 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 results if you treat ordinary use of other works as a right under copyright. > 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. 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 me from selling the product or giving it away). > 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. So do I have to buy a program and then negotiate the right to run it separately? That seems very crazy. > 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. 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 right, then I am safe from such craziness. > 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? 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva write: >> > 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). >> ... and modification and, depending on the jurisdiction, execution. > 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. Possible consequence: http://fsfla.org/svnwiki/blogs/lxo/2007-06-29-gplv3-tivo-and-linux.en > 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. Hopefully. But we know how justice is in the US, right? :-( > 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. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva write: > > 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). > ... and modification and, depending on the jurisdiction, execution. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > So, let's narrow the scenario to: tivoized machine downloads binary > from protected site, refrains from downloading sources that it could > download, user can still access and copy the binaries, but can't > obtain the sources because the machine opted not to get them. > Now, the user can't distribute the binaries, because doing so without > being able to get the sources to pass them on would be copyright > infringement. Would a court see this as a restriction on distribution > imposed by the distributor? Or by the copyright holder? 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://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> 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? > 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. How do you reach this conclusion as to this kind of distinction? > 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. Hey, why stop at these excuses to stop someone from modifying copies of the GPL? Why not list legal obstacles as well? > 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". Yup. > 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). ... 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: >> 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. > 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, 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 GPL. >> 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 when you scribble in the margin of a book you are also modifying it, > so what. Maybe it's fair use, especially for a printed book, of which many copies presumably exist. > I don't think you even need copyright permission, although you > will probably get into trouble if the book was borrowed from a library. > I don't see the relevance in the context of this discussion. 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 argument holds water. >> Here are variations of another scenario I proposed back then: >> >> - Tivoizing device ships with tivoized software, regardless of whether >> the corresponding sources are accessible to the end user or hidden >> inside the box, in a fully-encrypted disk that only that machine can >> read. > I'm assuming no written offer for access to the software is included. Yup, that's the idea. > Source are inaccessible, restricted the recipients rights to copy, > distribute and modify the source code, GPLv2 violation. So, the same standards would apply to the binaries: if they were inaccessible, copyright holder could claim infringement under the same grounds, right? > If it doesn't download the sources then the binary is not accompanied by > the corresponding source code and since we assumed no written offer this > is a violation of section 3. Except, perhaps, for this bit: If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. So, let's narrow the scenario to: tivoized machine downloads binary from protected site, refrains from downloading sources that it could download, user can still access and copy the binaries, but can't obtain the sources because the machine opted not to get them. Now, the user can't distribute the binaries, because doing so without being able to get the sources to pass them on would be copyright infringement. Would a court see this as a restriction on distribution imposed by the distribut
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> 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? 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 encumbering these. > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Wed, Jun 27, 2007 at 08:08:08PM -0300, Alexandre Oliva wrote: > On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > > > 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. > > 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? That was explained in next paragraph where I said that preventing access sure sounds like a restriction on copying and modification, which is where the GPL violation would be. > 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. 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 violation. > 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 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. I don't see the relevance in the context of this discussion. > 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. 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 granted rights, to copy, distribute and modify, are restricted ... > Here are variations of another scenario I proposed back then: > > - Tivoizing device ships with tivoized software, regardless of whether > the corresponding sources are accessible to the end user or hidden > inside the box, in a fully-encrypted disk that only that machine can > read. 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 and recipient can copy, distribute and modify. > - Network authenticates the device with help of the built-in crypto > device, and device requests feature-complete binaries in encrypted > network sessions. It's in the fature-complete binaries that the most > valuable improvements made by the tivoizer are, that they don't want > to share with anyone else. Sources *are* available behind the same > authentication machinery you don't can't get past. Whether the device > chooses to download them into the encrypted device you can't get to , > to dispose of them right away or even leave them around, or it simply > refrains from downloading the sources because it doesn't need them, > the end result is the same: you've received the sources over the > network, but
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Until someplace you can't actually access the software is customarily used > for software interchange, ... As in TiVo boxes? :-) :-) > 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. 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 might not even apply to themselves. > 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). I think that's correct, and IMHO that's how it's intended to be. > 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. ... 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thursday 28 June 2007 00:45:18 Alexandre Oliva wrote: > On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > > 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. > > Let's hope courts see it this way. I'm sure they will. Section 0 of the GPLv2 states what the license covers. Copying & modification are two of those things. > 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? 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. What they do is stop the hardware from running the modified form. > 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. I can't argue with this. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote: > 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. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> Alexandre Oliva writes: > > >> 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? > > > Behind a barrier is not the preferred form for modification. > > Where does it state that there must not be a barrier? I see it saying > the source must accompany the binary, under 3a. > > > Encrypted with a key you don't have is not the preferred form for > > modification. > > 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 > binary it accompanies. > > >> 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? > > > I honestly don't see what relevance this could possibly > > have. Getting access to the source is a fundamental GPL right. > > That's the spirit. But where does the *letter* of the GPL state it? 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Wednesday 27 June 2007 22:37:42 Alexandre Oliva wrote: > On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > > Behind a barrier is not on a medium customarily used for software > > interchange, which 3a requires. > > Are you per chance claiming that you've never heard of anyone > receiving encrypted software in a CD, or pre-installed in a computer? 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, contained the entire game, along with all previous idsoft games. > >> > I honestly don't see what relevance this could possibly > >> > have. Getting access to the source is a fundamental GPL right. > >> > >> That's the spirit. But where does the *letter* of the GPL state it? > > > > 3a says it. > > 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 > binary, for that matter? 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Behind a barrier is not on a medium customarily used for software > interchange, which 3a requires. Are you per chance claiming that you've never heard of anyone receiving encrypted software in a CD, or pre-installed in a computer? >> > I honestly don't see what relevance this could possibly >> > have. Getting access to the source is a fundamental GPL right. >> >> That's the spirit. But where does the *letter* of the GPL state it? > 3a says it. 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 binary, for that matter? > It makes no difference who imposes the restriction. Read section 7 > carefully. If *anything* imposes restrictions on the recipient's > exercise of their GPL rights, you can't distribute. 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 in this kind of situation that section 7 kicks in. >> >> 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. >> > 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. >> If your desktop is sufficiently similar, and the kernel binaries are >> identical, why should I not expect the same result to arise? > Because you have no way to get that software to run on my desktop, 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 because the party who distributed the software to me introduced mechanisms to prevent me from modifying the software, how is that not a "further restriction"? >> 2. You may modify your copy or copies of the Program or any portion >> of it ^^ > This is pretty clear that no copy is special. In any event, this is a grant > of license, not a guarantee of ability. (Read the context.) Yes, it's a grant of license. And then, section 6 tells a licensee that, when he distributes the software to someone else, she receives a license to modify that copy of the software, as well as to make further copies and modify them, and he must not impose any further restrictions on the exercise of the granted rights. QED > Otherwise, you could get around the GPL just by having someone else > impose restrictions. Oh, wow, really? Are you familiar with the Microsoft Novell deal? Is this not exactly how they got around the GPL? The only reason GPLv3 can oppose distribution under these conditions is precisely the existence of the deal, which turns both Microsoft and Novell parties of an arrangement to distribute the software in a way that imposes further restrictions on the recipient's rights granted by the license. Unfortunately, I'm told GPLv2 is vulnerable to this particular deal. Also remember that it's not enough for Microsoft or anyone else to have patents that might be used to impose restrictions on others' exercise of their rights for the GPL to say you can't distribute the software. You must (voluntarily or not) accept a restrictive license before section 7 kicks in and stops you from distributing the software under the restri
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > > > Alexandre Oliva writes: > > >> 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? > > Behind a barrier is not the preferred form for modification. > Where does it state that there must not be a barrier? I see it saying > the source must accompany the binary, under 3a. Behind a barrier is not on a medium customarily used for software interchange, which 3a requires. > > Encrypted with a key you don't have is not the preferred form for > > modification. > 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 > binary it accompanies. 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 the source code. > >> 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? > > > I honestly don't see what relevance this could possibly > > have. Getting access to the source is a fundamental GPL right. > > That's the spirit. But where does the *letter* of the GPL state it? 3a says it. > > By this argument, shipping a GPL'd work in ROM would violate the GPL > > because you cannot easily modify that particular copy. > 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 > a means to stop you from making modifications. It makes no difference who imposes the restriction. Read section 7 carefully. If *anything* imposes restrictions on the recipient's exercise of their GPL rights, you can't distribute. > >> 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. > > 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. > If your desktop is sufficiently similar, and the kernel binaries are > identical, why should I not expect the same result to arise? Because you have no way to get that software to run on my desktop, just as you have no way to get that software to run on your Tivo. > > Again, nonsense view leads to nonsense conclusions. The fix is to > > reject the nonsense view. There are no special GPL rights to > > particular copies of works or particular hardware. > 2. You may modify your copy or copies of the Program or any portion > of it ^^ This is pretty clear that no copy is special. In any event, this is a grant of license, not a guarantee of ability. (Read the context.) > >> 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. > > > Intent is not the issue. > > Imposing further restrictions is the issue. 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 someone else impose restrictions. > > If the GPL says I can modify my distributed copy, then distributing > > on CDROM is a GPL violation. > 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 > GPL violation. 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 cannot distribute on CDROM. > > It is mind-bogglingly obvious that any sort of "right to modify one > > particular copy" is *not* a GPL right.
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva writes: >> 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? > Behind a barrier is not the preferred form for modification. Where does it state that there must not be a barrier? I see it saying the source must accompany the binary, under 3a. > Encrypted with a key you don't have is not the preferred form for > modification. 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 binary it accompanies. >> 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? > I honestly don't see what relevance this could possibly > have. Getting access to the source is a fundamental GPL right. That's the spirit. But where does the *letter* of the GPL state it? > By this argument, shipping a GPL'd work in ROM would violate the GPL > because you cannot easily modify that particular copy. 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 a means to stop you from making modifications. >> 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. > 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. If your desktop is sufficiently similar, and the kernel binaries are identical, why should I not expect the same result to arise? > Again, nonsense view leads to nonsense conclusions. The fix is to > reject the nonsense view. There are no special GPL rights to > particular copies of works or particular hardware. 2. You may modify your copy or copies of the Program or any portion of it ^^ >> 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. > Intent is not the issue. Imposing further restrictions is the issue. > 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 it is imposed by the licensee, yes, it is indeed. > If you can't distribute so as to give all GPL rights, you can't > distribute at all. Exactly. > If the GPL says I can modify my distributed copy, then distributing > on CDROM is a GPL violation. 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 GPL violation. > It is mind-bogglingly obvious that any sort of "right to modify one > particular copy" is *not* a GPL right. Please read the license instead of assuming you know what it says. You clearly don't. See above. > You are wasting an awful lot of time and effort analyzing things that have > *NO* GPL consequence at all. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva writes: > 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? Behind a barrier is not the preferred form for modification. Encrypted with a key you don't have is not the preferred form for modification. > 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? 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 burden access to the source. > 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. 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 is wrong.) > 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. 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 particular copies of works or particular hardware. > 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. 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 particular copy" is *not* a GPL right. > Saying that I can modify the sources and build another copy of the > binary and then install that, but then it won't work, but that's fine > because this is not modifying, while true, does not disqualify the > claim that TiVo's design imposes artificial restrictions on my > abilities to modify the copies of the program that I have received. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > 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. 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 work, but that's fine because this is not modifying, while true, does not disqualify the claim that TiVo's design imposes artificial restrictions on my abilities to modify the copies of the program that I have received. > And yes, I do realize that you intentionally tried to come up with your > example to somehow bring tivoization to the source code. Actually, I first came up with this example long before GPLv3dd3 was published, and I know there have been changes to the draft in response to it. Here are variations of another scenario I proposed back then: - Tivoizing device ships with tivoized software, regardless of whether the corresponding sources are accessible to the end user or hidden inside the box, in a fully-encrypted disk that only that machine can read. - The software that ships is feature-limited. It's just barely enough to enable the device to connect to the network and download feature-complete software. - Network authenticates the device with help of the built-in crypto device, and device requests feature-complete binaries in encrypted network sessions. It's in the fature-complete binaries that the most valuable improvements made by the tivoizer are, that they don't want to share with anyone else. Sources *are* available behind the same authentication machinery you don't can't get past. Whether the device chooses to download them into the encrypted device you can't get to, to dispose of them right away or even leave them around, or it simply refrains from downloading the sources because it doesn't need them, the end result is the same: you've received the sources over the network, but you can't get to them. - Updates to the feature-complete software can be delivered over the same secure channel, and, as a result, derived versions of your software are distributed to third parties in ways that neither you nor the recipient can get to the sources. Here's another variation: - Vendor distributes device with feature-limited software in the fully-encrypted disk, with just enough software to download sources from the network, build the feature-complete software from sources, and install it. - Sources are behind network authentication, as above, so although your device receives them, you can't get to them because they're in the encrypted disk. Does it seem to you that GPLv2 blocks any of these means to distribute your code without granting its users access to the source code? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Tue, Jun 26, 2007 at 04:47:34AM -0300, Alexandre Oliva wrote: > On Jun 26, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > > On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > >> You could argue that they do not restrict copying, distribution > >> and modification of the sources in general, only of the specific copy > >> they distribute. > > > "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 > > you'll get to the source code in the first place." > > 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? ;-) 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: >> You could argue that they do not restrict copying, distribution >> and modification of the sources in general, only of the specific copy >> they distribute. > "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 > you'll get to the source code in the first place." 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote: >> Consider this scenario: vendor tivoizes Linux in the device, and >> includes the corresponding sources only in a partition that is >> theoretically accessible using the shipped kernel, but that nothing in >> the software available in the machine will let you get to. Further, >> sources (like everything else on disk) are encrypted, and you can only > 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. 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 can read, using hardware-assisted decryption. > Another gripe is that encrypted media are not customarily used for > software interchange. 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 software in them. > 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." 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 used to escape its intent in this or other recent threads. > You could argue that they do not restrict copying, distribution > and modification of the sources in general, only of the specific copy > they distribute. "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 you'll get to the source code in the first place." > They get sued for copyright infringement because they are not in > compliance with section 3 and the sources are released as a result. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Mon, Jun 25, 2007 at 04:54:52PM -0300, Alexandre Oliva wrote: > Consider this scenario: vendor tivoizes Linux in the device, and > includes the corresponding sources only in a partition that is > theoretically accessible using the shipped kernel, but that nothing in > the software available in the machine will let you get to. Further, > sources (like everything else on disk) are encrypted, and you can only 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, distribute or modify the source code. > Does anyone think this is permitted by the letter of GPLv2? No. > How are the sources passed on in this way going to benefit the user or > the community? 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 25, 2007, [EMAIL PROTECTED] (Lennart Sorensen) wrote: > On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote: >> 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. > Just because someone has a different opinion than you or the FSF does > not make what they say a lie. 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 retract my assessment of such behavior as 'lying'. > Well what the spirit is, is certainly debateable, 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 literal wording. > 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. 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 consequences are characterized. > Intelligent people know better than to listen to such groups. Ignoring facts that don't fit your ideology, or that support an ideology you reject, will mislead you, no matter what your fanaticism or anti-fanaticism is. > I think I know exactly as much about the GPL now as I did two weeks ago. Good for you (assuming you're not saying you've refused to learn anything just because I was the one passing on the knowledge, because, well, this would be unintelligent too, right? ;-) Consider this scenario: vendor tivoizes Linux in the device, and includes the corresponding sources only in a partition that is theoretically accessible using the shipped kernel, but that nothing in the software available in the machine will let you get to. Further, sources (like everything else on disk) are encrypted, and you can only decrypt it with hardware crypto that is disabled if the boot loader doesn't find a correct signature for the boot partition, or maybe the signature is irrelevant, given that everything on disk is encrypted in such a way that, if you don't have the keys, you can't update the kernel properly anyway. The vendor refuses to give customers other copies of the sources. To add insult to the injury, the vendor configures the computer to set up the encrypted disk partition containing the sources as a swap device, such that the shared-secret key used to access that entire filesystem is overwritten upon the first boot, rendering the entire previous contents of the partition holding the source code into an incomprehensible stream of bits. Does anyone think this is permitted by the letter of GPLv2? Is it in the spirit of GPLv2? How are the sources passed on in this way going to benefit the user or the community? Is this still desirable by the Linux developers? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote: > 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. 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 want to listen to the FSF and its advocates. > 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. 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 RMS are not the only ones that count in the world. > 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. 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 beliefs. > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> > 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 > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Theodore Tso <[EMAIL PROTECTED]> wrote: > On Fri, Jun 22, 2007 at 10:14:23AM +0100, Alan Cox wrote: >> > Another law of negotiations --- don't goad people into hardening their >> > positions; it helps neither you nor your interests. >> >> That always depends which side you really support, whether you want to >> force someone to wedge themselves in an undefendable corner and so on.. > Well yes, I'm assuming that the goal is successfully concluded > negotiations. 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 wrote this, I learned that many Linux authors really understood the "no further restrictions" provision of GPLv2 in a far more limited different way, that the spirit in which they licensed their code departed from the spirit of the GPL. Nevertheless, I offered the reasoning I had to offer about potential benefits of anti-tivoization provisions, because I saw no evidence that anything but potential negative consequences had been taken into account. The same negative consequences that are being brought up WRT the GPLv3 clarifications have repeatedly been brought up against the GPL since its inception: "Oh my God, this will scare businesses, they will never use it." Time is showing these fears were largely exaggerated. I hope this will prove true for GPLv3 as well, but my crystal ball is failing me, even more so because a critical piece of code that would enable us to tell, in the long run, is, let's say, highly skeptical of the possibility that prohibiting certain uses can be beneficial in the long run. As for why I got into this debate... Isn't it much simpler to believe that I got into the debate because Greg KH wrote things about GPLv3 that I understand to be incorrect, and I wanted to set the record straight on it, than that I, an admittedly unskilled negotiator, was going to try to "push GPLv3 down your throats"? And that the most important issue to set the record straight on was *precisely* about the complaint, signed by him and about half of the major contributors to Linux, and later supported by other major contributors, that GPLv3 changed the spirit of the license? How on earth can you and others possibly claim with a straight face that "nobody cares about the spirit"? The other point I intended to make was the accusation that the FSF was dividing the community. This is very unfair. If the release of a license that more clearly expresses the intent of part of the community, and this part of the community adopts it, while another part of the community rejects it, is this not a sign that the community is already divided? Given that part of the community at large, including the FSFes, seeks better defenses for the freedom of their code, seeks respect for the "freedom or death" provision already present in GPLv2 (even if interpreted by some in a narrower sense than it was meant), how is it fair to complain that they exercise the option to obtain such defenses, on the grounds that the complaining party might no longer get the full cooperation of the party
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 10:14:23AM +0100, Alan Cox wrote: > > Another law of negotiations --- don't goad people into hardening their > > positions; it helps neither you nor your interests. > > That always depends which side you really support, whether you want to > force someone to wedge themselves in an undefendable corner and so on.. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 03:00:30AM -0300, Alexandre Oliva wrote: > 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. 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 GPLv3 was an inferior license, FOR THE LINUX KERNEL. > That I was perceived as pushing it is not surprising at all. 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 community) was one where you would keep slidng away from. > 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. Great. So can we please END this thread? Thank you. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> Another law of negotiations --- don't goad people into hardening their > positions; it helps neither you nor your interests. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> 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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote: >> 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. > And that constitutes the change of license. I stand corrected. I misread what you wrote as "relicensing under GPLv3, or GPLv2+". Sorry. > Suppose ZFS _is_ pulled into the tree via that mechanism. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 22, 2007, Theodore Tso <[EMAIL PROTECTED]> wrote: > has probably made it made it much more *unlikely* that the Linux > kernel will ever go GPLv3. 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 http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, 22 Jun 2007 01:34:24 -0300 Alexandre Oliva wrote: > > You're not going to make a happy, happy merging code sharing world > > by fragmenting the licence landscape even more. > > I take it that removing barriers to cooperation in GPLv3 by default is > undesirable. Well, then, what can I say? I tried. :-( preferably that you give up. Thanks. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 01:34:24AM -0300, Alexandre Oliva wrote: > I take it that removing barriers to cooperation in GPLv3 by default is > undesirable. Well, then, what can I say? That It's All Their[kernel developers'] Fault(tm), of course. > I tried. :-( Or that, indeed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 01:26:54AM -0300, Alexandre Oliva wrote: > On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > > > On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote: > >> 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? > > > You know, I'm rapidly losing any respect for your integrity. The only > > "privelege" claimed is that of not relicensing one's contributions. > > 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. 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"? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 01:14:27AM -0300, Alexandre Oliva wrote: > On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote: > >> It's not like anyone can safely tivoize devices with GPLv2 already, > > > So you really didn't pay any attention to anything people told you? > > 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 > understand? > > > 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. > > 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! 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 makes that determination there is no kaboom here. > 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. > > Kaboom! 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. So again, not much of a kaboom here either. > > A mutual compatibility agreement (sublicense) would effectively > > terminate any rights granted by the GPLv2, > > 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. 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 explicitly not permitted. > The same kind of additional permission that GPLed projects that use > openssl adopt. 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 original author accepts the additional restriction that comes from the BSD + advertising clause, while the GPLv2 authors do not accept the additional restrictions they would inherit from the GPLv3 otherwise they would re-license their code to GPLv2+. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > 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. 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 incompatible license) at all. > understand what licence the final work is under. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Bron Gondwana <[EMAIL PROTECTED]> wrote: > None of this "Projects" nonsense. 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 to licenses (part of the policy of each project). > Suddenly using other GPLv2 code becomes fraught with "which path did > I obtain this licence down" games 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 followed. But IANAL. > You're not going to make a happy, happy merging code sharing world > by fragmenting the licence landscape even more. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote: >> 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? > You know, I'm rapidly losing any respect for your integrity. The only > "privelege" claimed is that of not relicensing one's contributions. 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 (the alternative being to remove all of his contributions). > What really gets me is that you know 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Fri, Jun 22, 2007 at 02:34:17AM +0100, Al Viro wrote: > 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). 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 merely extremely unlikely has become "practically impossible". > The first law of holes: when you are in one, stop digging... Indeed. Another law of negotiations --- don't goad people into hardening their positions; it helps neither you nor your interests. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote: >> It's not like anyone can safely tivoize devices with GPLv2 already, > So you really didn't pay any attention to anything people told you? 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 understand? > 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. 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. Kaboom! > There is no need to take out contributions because the GPLv2 does > not prevent tivoization. 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 jurisdiction? > A mutual compatibility agreement (sublicense) would effectively > terminate any rights granted by the GPLv2, 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote: > 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: 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote: > On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > > >> > 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? > > >> No. This is not permission to relicense. This is permission to > >> combine. Each author still gets to enforce the terms of her own code. > > > 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 > > Tivoize) in the derivative work that it becomes mixed with? > > In just the same way you'd enforce it today: with help from a lawyer > who understands these issues that you clearly don't understand. 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, Jun 21, 2007 at 10:00:22PM -0300, Alexandre Oliva wrote: > 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? 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... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > 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. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, Jun 21, 2007 at 08:23:57PM -0300, Alexandre Oliva wrote: > On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > > >> > 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? > > >> No. This is not permission to relicense. This is permission to > >> combine. Each author still gets to enforce the terms of her own code. > > > 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 > > Tivoize) in the derivative work that it becomes mixed with? > > In just the same way you'd enforce it today: with help from a lawyer > who understands these issues that you clearly don't understand. > > >> 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. > > > 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? > > 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 > doesn't share your opinion. That's your call. > > > 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. > > 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. 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_. Tivo in no way limits your ability to exercise any of these rights. > FWIW, all of my (very few) contributions to Linux were made with the > intent of not permitting tivoization or any form of restricting users > freedoms. I guess this means, from now on, you'd stop a
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote: >> 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. > Oh, right. "Anyone who doesn't like proprietary code in the tree > can just remove it, what's the big deal?" analog. Sorry, doesn't work. 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 about that. >> I can see that one-way cooperation could be perceived as unfair, even >> if permissions granted by GPLv3 are all granted by GPLv2 as well. > ... 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. > And you are saying that it's not one-way? 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 GPLv3. As to whether this has any effects on GPLv3 projects, it does. It weakens the legal defenses for the entire project, in as much as the wholes in GPLv2 might still be exploited. >> > ... except for that pesky "no added restrictions" part, but hey, who >> > cares? >> But see, nobody would be adding restrictions to *your* code. > What you are saying is "but your code will be still > available under GPLv2". No, I'm saying far more than this obvious conclusion, on which you apparently stopped thinking. I'm saying the project that uses it won't get as strong legal defenses as it would get if it were under GPLv3. So, yes, both sides sacrifice some of their stances in order to enable mutual cooperation. Sure, if you don't want to do that, that's your call. But don't try to frame it as if there was something wrong or unfair about it. > So it will be if e.g. SCO pulls it into proprietary codebase. Except that then I won't be able to enjoy any of the rights that you meant me to enjoy as to the code that SCO distributes. Whereas with combination of GPLv2 with GPLv3, every licensee still gets all of the same freedoms respected. The difference is only as to how much they can deny other licensees the freedoms you meant them to get. And if someone cares about using your code to deny other licensees freedoms, they still can. Depending on how much you intermingled your code with code that doesn't want to permit this, it will be more or less difficult to do, but it can be done. > The first change in v3 project affecting both imported v2 code and > native v3 one will create a big problem. Why? The licenses permit combination/linking, each portion remains under the same license as their authors meant. >> > ... because it's For The Benefit Of User Freedoms!!! >> It is either way. Do you deny that tivoization also benefits one >> user/licensee? And in detriment of others, while at that? > 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. And it's indeed the same issue: placing the interests of a few license
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva wrote: > 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. > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > 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 > you do. 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 case, and you pick on me. Puhlease! > 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 > the FSF. 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 your mistake won't make it true. > 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 > speaking for that company. Indeed, compiler engineers are often the bearers of company's voices. Not! > 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. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Are you seriously suggesting that the Linux kernel source contain code with > various different licenses It already does. All the way from permissive Free Software licenses to GPLv2-incompatible non-Free Software licenses. > 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. 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 the intent of the GPL. > Unless, that is, GPLv3 makes itself compatible with GPlv2. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> > 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? >> No. This is not permission to relicense. This is permission to >> combine. Each author still gets to enforce the terms of her own code. > 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 > Tivoize) in the derivative work that it becomes mixed with? In just the same way you'd enforce it today: with help from a lawyer who understands these issues that you clearly don't understand. >> 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. > 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? 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 doesn't share your opinion. That's your call. > 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. 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 give you what you want. FWIW, all of my (very few) contributions to Linux were made with the intent of not permitting tivoization or any form of restricting users freedoms. I guess this means, from now on, you'd stop accepting my contributions and take out whatever contributions I've made, since otherwise I'd be able to enforce them against tivoizers. And what's more, I could still use your code in my GPLv2 projects, and enforce that against tivoizers, and there's nothing you can do to stop me. So what exactly are you trying to accomplish by pretending that mutual compatibility with GPLv3 would set you back in any way? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On 22/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > On 21/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > [snip] >> >> 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 ;-) > Given your signature below, no, that's not at all clear : 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 associated with them? 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 you do. >> FSF Latin America Board Member http://www.fsfla.org/ > If you don't speak for the FSF then adverticing the fact that you are > a FSF board member seems a little odd. 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 FSFs. 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 the FSF. > I also fail to see (or at least wonder at) how a board member of the > FSF can state that he's not associated with the FSF... hmm, the mind > boggles.. Yeah, it's really hard to clarify broken assumptions and jumping to conclusions. See above. >> Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} > Same thing for the RedHat bit here, along with posting from a > @redhat.com email addr. 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... 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 speaking for that company. If I posted from my ISP e-mail address, would you assume I was speaking for the ISP? 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 <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "Jesper Juhl" <[EMAIL PROTECTED]> wrote: > On 21/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > [snip] >> >> 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 ;-) > Given your signature below, no, that's not at all clear : 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 associated with them? >> FSF Latin America Board Member http://www.fsfla.org/ > If you don't speak for the FSF then adverticing the fact that you are > a FSF board member seems a little odd. 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 FSFs. > I also fail to see (or at least wonder at) how a board member of the > FSF can state that he's not associated with the FSF... hmm, the mind > boggles.. Yeah, it's really hard to clarify broken assumptions and jumping to conclusions. >> Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} > Same thing for the RedHat bit here, along with posting from a > @redhat.com email addr. 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, Jun 21, 2007 at 05:15:03PM -0300, Alexandre Oliva wrote: > On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > > > On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote: > > >> - the kernel Linux could use code from GPLv3 projects > > > ... and inherit GPLv3 additional restrictions. No. > > Respecting the wishes of the author of that code. Are you suggesting > they should not be respected? Do piss off. You know full well what I'm saying. > 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. Oh, right. "Anyone who doesn't like proprietary code in the tree can just remove it, what's the big deal?" analog. Sorry, doesn't work. > Without this provision, you wouldn't be able to use the code in the > first place, so I don't perceive any loss for anyone. Do you? Replace GPLv3 with proprietary in your argument and look in archives. That had come up quite a few time in such form. > >> - GPLv3 projects could use code from Linux > > > Oh, rapture! How could one object against such a glorious outcome? > > Exactly ;-) Look up "sarcasm". > > Two-way cooperation. I'm told that's good. I was told this was even > desirable. Again, replace v3 with proprietary and reread your argument. > I can see that one-way cooperation could be perceived as unfair, even > if permissions granted by GPLv3 are all granted by GPLv2 as well. ... 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. And you are saying that it's not one-way? > > ... except for that pesky "no added restrictions" part, but hey, who > > cares? > > But see, nobody would be adding restrictions to *your* code. 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 affecting both imported v2 code and native v3 one will create a big problem. > > ... because it's For The Benefit Of User Freedoms!!! > > It is either way. Do you deny that tivoization also benefits one > user/licensee? And in detriment of others, while at that? 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 of "Will somebody think of chiiildrun!!!?!?!?" > > No. Permission denied. > > Your opinion is duly noted. Thanks. It's not an opinion. It's a lack of permission to distribute GPLv2 code under conditions violating its license. > > If somebody wants to dual-license *others* code, > > 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. Ah. Got it. Nice spin. "Your license doesn't allow to put your code under the license we want, you are mean and uncooperative! Gmm!!! Or be condemned as a Bad Person and an Enemy of Freedom" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva wrote: > With a mere permission to combine, I can only enforce these provisions > over my own code. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
> > 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? > No. This is not permission to relicense. This is permission to > combine. Each author still gets to enforce the terms of her own code. 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 Tivoize) in the derivative work that it becomes mixed with? > 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On 21/06/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote: [snip] 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 ;-) Given your signature below, no, that's not at all clear : -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ 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 associated with the FSF... hmm, the mind boggles.. Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Same thing for the RedHat bit here, along with posting from a @redhat.com email addr. -- Jesper Juhl <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, Al Viro <[EMAIL PROTECTED]> wrote: > On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote: >> - the kernel Linux could use code from GPLv3 projects > ... and inherit GPLv3 additional restrictions. No. 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 first place, so I don't perceive any loss for anyone. Do you? >> - GPLv3 projects could use code from Linux > Oh, rapture! How could one object against such a glorious outcome? 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 if permissions granted by GPLv3 are all granted by GPLv2 as well. >> - each copyright holder would still get to enforce the terms s/he >> chose for his/her own code > ... except for that pesky "no added restrictions" part, but hey, who > cares? 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 (including the authors themselves). >> 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 > ... because it's For The Benefit Of User Freedoms!!! It is either way. Do you deny that tivoization also benefits one user/licensee? And in detriment of others, while at that? > No. Permission denied. Your opinion is duly noted. Thanks. > If somebody wants to dual-license *others* code, 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, [EMAIL PROTECTED] wrote: > this is standard dual-licensing, not special just becouse both > licenses are GPL versions 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 explicit in GPLv3. > 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 Which is precisely why I suggested this approach of permission to combine, rather than as dual licensing. Because then nobody could do what you say. > one of the big problems that people don't realize is that if it takes > GPLv3+ exception to be compatible with the apache license 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: > Alexandre Oliva wrote: >> 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: > 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? 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva wrote: > 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: 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, 21 Jun 2007, Alexandre Oliva wrote: On Jun 21, 2007, jimmy bahuleyan <[EMAIL PROTECTED]> wrote: 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)? 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 ;-) 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Thu, Jun 21, 2007 at 06:39:07AM -0300, Alexandre Oliva wrote: > 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 ... and inherit GPLv3 additional restrictions. No. > - GPLv3 projects could use code from Linux Oh, rapture! How could one object against such a glorious outcome? > - each copyright holder would still get to enforce the terms s/he > chose for his/her own code ... except for that pesky "no added restrictions" part, but hey, who cares? > 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 ... 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
On Jun 21, 2007, jimmy bahuleyan <[EMAIL PROTECTED]> wrote: > 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)? 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 [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?
Alexandre Oliva wrote: > 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: > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how about mutual compatibility between Linux's GPLv2 and GPLv3?
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 GPLv3? Thanks, and sorry for taking your attention away from coding one more time. I hope you find it worth it this time. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/