Re: Fwd: That whole "Linux stealing our code" thing
Chris Friesen writes: > Daniel Hazelton wrote: >> On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: >> >>>Daniel Hazelton <[EMAIL PROTECTED]> writes: >>> US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) > > The OpenBSD policy page doesn't agree with you: > > "...That means that having granted a permission, the copyright holder > can not retroactively say that an individual or class of individuals > are no longer granted those permissions. Likewise should the copyright > holder decide to "go commercial" he can not revoke permissions already > granted for the use of the work as distributed, though he may impose > more restrictive permissions in his future distributions of that work." > > http://www.openbsd.org/policy.html By my reading, this is supported by 17 USC 203(a)(3): (3) Termination of the grant may be effected at any time during a period of five years beginning at the end of thirty-five years from the date of execution of the grant; or, if the grant covers the right of publication of the work, the period begins at the end of thirty-five years from the date of publication of the work under the grant or at the end of forty years from the date of execution of the grant, whichever term ends earlier. (from http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0203000-.html ) I would be interested to see what other legal basis is alleged as grounds to rescind a license. Michael - 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: Fwd: That whole Linux stealing our code thing
Chris Friesen writes: Daniel Hazelton wrote: On Tuesday 04 September 2007 09:27:02 Krzysztof Halasa wrote: Daniel Hazelton [EMAIL PROTECTED] writes: US Copyright law. A copyright holder, regardless of what license he/she may have released the work under, can still revoke the license for a specific person or group of people. (There are some exceptions, but they do not apply to the situation that is being discussed) The OpenBSD policy page doesn't agree with you: ...That means that having granted a permission, the copyright holder can not retroactively say that an individual or class of individuals are no longer granted those permissions. Likewise should the copyright holder decide to go commercial he can not revoke permissions already granted for the use of the work as distributed, though he may impose more restrictive permissions in his future distributions of that work. http://www.openbsd.org/policy.html By my reading, this is supported by 17 USC 203(a)(3): (3) Termination of the grant may be effected at any time during a period of five years beginning at the end of thirty-five years from the date of execution of the grant; or, if the grant covers the right of publication of the work, the period begins at the end of thirty-five years from the date of publication of the work under the grant or at the end of forty years from the date of execution of the grant, whichever term ends earlier. (from http://www.law.cornell.edu/uscode/html/uscode17/usc_sec_17_0203000-.html ) I would be interested to see what other legal basis is alleged as grounds to rescind a license. Michael - 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: Noatime vs relatime
Vlad writes: > Relatime seems to be wasteful of both IO resources _and_ CPU cycles. > Instead of performing a single IO operation (as atime does), relatime > performs at least three IO operations and three CPU-dependent > operations: > > 1) a read IO operation to find out the old atime > 2) a read IO operation to find out the old ctime > 3) a read IO operation to find out the old mtime > 4) Comparison of "old atime is <= than mtime/ctime" > 5) Find out current time > 6) Comparison of "current time minus old atime is > X" > > People are going to wonder why all of the sudden everything is running > so slow due to atimes being updated after a long break. Filesystems deal with block devices, which have fairly large (at least 512-byte) read and write granularity. Sane filesystems have atime, ctime and mtime all in the same block, so one read gets all three. The file's metadata would be in the cache while it's open anyway. CPU operations are many orders of magnitude faster than block I/O, so if steps 4-6 eliminate even a fraction of a percent of atime writebacks, relatime is a net benefit. In practice, most files are read many more times than they are written, and most of those are eliminated even with step #6. Academic journals abound with storage-related studies of read versus write patterns (often including temporal locality of reference) for various kinds of files; I refer you to those for details. Michael. - 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: Noatime vs relatime
Vlad writes: Relatime seems to be wasteful of both IO resources _and_ CPU cycles. Instead of performing a single IO operation (as atime does), relatime performs at least three IO operations and three CPU-dependent operations: 1) a read IO operation to find out the old atime 2) a read IO operation to find out the old ctime 3) a read IO operation to find out the old mtime 4) Comparison of old atime is = than mtime/ctime 5) Find out current time 6) Comparison of current time minus old atime is X People are going to wonder why all of the sudden everything is running so slow due to atimes being updated after a long break. Filesystems deal with block devices, which have fairly large (at least 512-byte) read and write granularity. Sane filesystems have atime, ctime and mtime all in the same block, so one read gets all three. The file's metadata would be in the cache while it's open anyway. CPU operations are many orders of magnitude faster than block I/O, so if steps 4-6 eliminate even a fraction of a percent of atime writebacks, relatime is a net benefit. In practice, most files are read many more times than they are written, and most of those are eliminated even with step #6. Academic journals abound with storage-related studies of read versus write patterns (often including temporal locality of reference) for various kinds of files; I refer you to those for details. Michael. - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > On Wed, 20 Jun 2007, Michael Poole wrote: > >> [EMAIL PROTECTED] writes: >> >>> if the GPL can excercise control over compilations, then if Oracle >>> were to ship a Oracle Linux live CD that contained the Oracle Database >>> in the filesystem image, ready to run. then the GPL would be able to >>> control the Oracle Database code. >> >> By copyright law, it could. By its language, it does not. > > many people (including many lawyers will disagree that it could by > copyright law On what grounds would Oracle have a license to ship that part of Linux? Unless you are the sole copyright owner, you have no right to copy a given piece of software _at all_ without a license. The GPL is a remarkably giving license in terms of how little it requires. (This potentially wide scope is one of the major reasons that the GPL mentions "mere aggregation" and that the Debian Free Software Guidelines' include guideline #9.) >>> if the GPL can't do this then it can't control the checksum either. >>> >>> again, it's not just the kernel that's part of the checksum on a tivo, >>> the checksum is over the kernel + initial filesystem, much of which >>> contains code not covered by the gPL) >> >> Again, did you miss where I pointed out that this makes it *worse* for >> Tivo, because they are tying together -- and making inseparable -- a >> combination that would otherwise be "mere aggregation"? > > and it makes most distro CD's illegal since they contain code under > different incompatible licenses and they make a checksum across the > entire CD image. When distributions generate checksums (as opposed to signatures) over images, they do provide all of the inputs. When most distributions provide signatures, the signatures do not function as statements or instructions to computers -- they function as statements to users. Tivo's digital signatures differ in both of these respects. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > if the GPL can excercise control over compilations, then if Oracle > were to ship a Oracle Linux live CD that contained the Oracle Database > in the filesystem image, ready to run. then the GPL would be able to > control the Oracle Database code. By copyright law, it could. By its language, it does not. > if the GPL can't do this then it can't control the checksum either. > > again, it's not just the kernel that's part of the checksum on a tivo, > the checksum is over the kernel + initial filesystem, much of which > contains code not covered by the gPL) Again, did you miss where I pointed out that this makes it *worse* for Tivo, because they are tying together -- and making inseparable -- a combination that would otherwise be "mere aggregation"? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: >> There is a lot of grey and/or arguable area about what constitutes a >> GPL-encumbered collective work versus mere aggregation. > > I think it's technically/legally clear what the standards are, but certainly > arguable whether particular works meet that standard. If the choice of works > to combine is sufficiently creative (above and beyond any choices dictated > by functional considerations), it's a GPL-encumbered collective work. > > I don't think it's arguable that a signature shipped along with a binary is > a collective work. In any event, if that were true, I think we should be > able to agree that Linus would be required to release his kernel signing > keys. The distinction between GPL-covered works and "mere aggregation" is not a function only of legal classifications. If it were, the GPL would be worded differently than it is -- and have different effects than most people believe it does. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: >> However, compilations (even to the extent they are creative >> combinations) are not necessarily derivative works of their elements. >> For more details, see >> http://www.copyright.gov/circs/circ14.html#compilations > > Because compilation copyrights don't really affect the Tivo and GPLv2/GPLv3 > issue, I tend to ignore them when discussing that subject. If you think I'm > wrong and there is some relationship between them, please let me know. I > admit I may not have given that possibility enough thought. I believe compilation copyrights do bear on GPL-licensed software, by virtue of the GPL's sentence "[...] rather, the intent is to exercise the right to control the distribution of derivative _or collective_ works based on the Program." (emphasis added). There is a lot of grey and/or arguable area about what constitutes a GPL-encumbered collective work versus mere aggregation. Although I disagree, I understand and respect that some believe that the kernel plus a digital signature over it is "mere aggregation". I would like to focus the discussion on that question, though, rather than whether the GPL is worded to control the rights to compilations-in-general that include GPLed works. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: >> Most of this list has >> already dismissed your rather unique -- I would even say frivolous -- >> idea of how far "mere aggregation" goes: I, for one, have better >> things to do than explain why a C file is not a "mere aggregation" of >> the functions it contains.) >> >> Michael Poole > > Of course it's not mere aggregation. The functions in a C file are > creatively combined. How many times do I have to say that the opposite of > "mere aggregation" is creative combination? > > It is not unique, it is part of the definition of a "derivative work". By "creative combination" do you mean what US copyright law refers to as compilations (or their subset collective works)? Compilations can be creative combinations while still being mere aggregation under the GPL. For example, if applications are selected to run with a Linux kernel, and they are distributed together, the collection is a creative selection -- and this seems to be one of the cases evoked by the GPL's reference to "mere aggregation". See also practically every Linux distribution on the planet. Compilations also can be creative combinations and *more* than mere aggregation: for example, Linux with respect to its subsystems, or any case where a larger work is derivative of one of its components. However, compilations (even to the extent they are creative combinations) are not necessarily derivative works of their elements. For more details, see http://www.copyright.gov/circs/circ14.html#compilations Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: >> I do not say that the BIOS is doing anything (legally) wrong. The >> wrong act is distributing the binary kernel image without distributing >> complete source code for it. > > Why are you not complaining that Linus does not distribute the keys he uses > to sign kernel source distributions? If a digital signature is part of the > distribution, why is the key used to produce that signature not part of the > distribution? > > If you can cite some legal reason there is a difference, I would be quite > impressed. > > In any event, the argument is obvious nonsense. The signature is merely > aggregated with the kernel. Cooperation, dependent function, and convergent > design can't break mere aggregation or you get ridiculous results. (For > example, a device shipped with the Linux kernel and some applications would > have to GPL all the applications.) Do you make it a habit to pose ranty questions to people while neither attributing their text nor cc'ing them? Especially when you claim the person's argument is "obvious nonsense", it seems quite rude. (Since you have dismissed my argument as nonsense before hearing my response, I will not bother answering your question. Since you are acting like a troll, I will dismiss you as one. Most of this list has already dismissed your rather unique -- I would even say frivolous -- idea of how far "mere aggregation" goes: I, for one, have better things to do than explain why a C file is not a "mere aggregation" of the functions it contains.) Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Tomas Neme writes: >> A "computer program" is a set of statements or instructions to be >> used directly or indirectly in a computer in order to bring about >> a certain result. >> -- US Code, Title 17, Section 101 > > so? People keep arguing that the signature is somehow not part of the kernel or not subject to copyright law. I suspect they do not realize how broad the legal definition of "computer program" is. > Not GPL related, but casino machine software that needs to be approved > by the casino regulation office in Argentina need to provide source, > compiling instructions AND binaries, and the binaries must pass a diff > check. This is impossible without a hacked compiler since the > timestamps WILL differ. > > Just an example that legality doesn't always comply with itself, and > even less make sense. This discussion is about copyright and the GPL, not legal quirks. I am aware of a large number of silly results reached by law. > plus, and I repeat myself.. the program comes with no warranties whatsoever. > > and if your complains are purely moral, see it this way: if TiVo > didn't sign their kernel, digital cable providers wouldn't give them > their hash keys, and they wouldn't be able to show HD signals, > rendering them useless, and making them go bankrupt... so they'd go > BSD, because they ARE a company after all, and they are after The > Moneys.. > > no? The GPL does not guarantee anyone a viable business model. Following it is not conditional on profitability. It is only conditional on exercising rights that are granted by the GPL. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > On Wed, 20 Jun 2007, Michael Poole wrote: > >> Please retract that claim. I have said no such thing, and have >> avoided saying anything that I thought might be misconstrued in that >> direction. >> >> To be absolutely clear: My complaints with Tivo as a hardware or BIOS >> vendor are moral and pragmatic, not legal. My complaint with Tivo as >> a distributor of Linux is what hinges on legal issues. > > but if the GPL doesn't control the BIOS how in the world are you > saying that the fact that the GPL covers the kernel makes what the > BIOS does wrong (even if the kernel was covered by GPLv3)? I do not say that the BIOS is doing anything (legally) wrong. The wrong act is distributing the binary kernel image without distributing complete source code for it. >>> that's a seperate body of code that is in no way derived from the >>> linux kernel (even the anti-tampering functions would work equally >>> well with other Operating systems and are in no way linux >>> specific). it's no even loaded on the same media (the BIOS is in >>> flash/rom on the botherboard, the OS is on the hard drive) >>> >>> and note that the software that is checked to make sure that it hasn't >>> been changed includes much more then the kernel. it checks the kernel >>> and the initrd. >> >> Not legally relevant. > > I disagree. it's very relevant if your argument is that becouse the > checksum if a checksum of the kernel that the license for the kernel > somehow controlls what can be done with it. To the extent that it is relevant, it strengthens the argument against Tivo: they are tying together many works of authorship, including some GPLed works, in a way that makes them effectively inseparable. This is beyond "mere aggregation" on a distribution medium, and tends to implicate *all* parts of the whole as GPL encumbered. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > On Wed, 20 Jun 2007, Michael Poole wrote: > >> [EMAIL PROTECTED] writes: >> >>> no, saying that the result must be acceptable to other software (in >>> this case the software running in the BIOS) is not part of the source >>> code. >> >> Why not? The digital signature is a statement (which translates >> roughly to "Tivo approves this") to be used in a computer in order to >> bring about a certain result. That result is making it boot on the >> PVR. Source code simply means the original forms or inputs used to >> generate machine-readable statements. > > but the signature isn't part of the kernel, and the code that checks > the signature is completely independant. and finally the PVR functions > are not part of the kernel (and not under the GPL in any case) > > if your argument was true then Oracle releasing a database appliance > would require Oracle to give you the source to their database since > it's part of 'bringing about a certain result' namely operating as a > database server. >From the kernel's COPYING file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". See also the portion below. > if your argument was true then releasing a GPL package for windows > would require that the windows kernel source be released, after it > it's nessasary for 'brining about a certain result' namely letting > your code run. >From section 3 of the GPL: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. > these are both nonsense results. .. which is why they are recognized to be different. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > On Wed, 20 Jun 2007, Michael Poole wrote: > >> [EMAIL PROTECTED] writes: >> >>> this is very much NOT true. if you take the source the provide you can >>> compile a kernel that will run on the tivo, the only thing you have to >>> do (on some models) is to change the bios to skip the step that checks >>> if the kernel has been tampered with. >> >> If we are opining whether Tivo provided complete source code for their >> Linux kernel images, the requirement to change non-GPLed software as a >> condition to exercise GPL-protected rights speaks for itself. > > no, the GPL protected rights don't say anything about the hardware the > system runs on. > > you are saying that the GPL now controls what the BIOS software is > allowed to do or not allowed to do. Please retract that claim. I have said no such thing, and have avoided saying anything that I thought might be misconstrued in that direction. To be absolutely clear: My complaints with Tivo as a hardware or BIOS vendor are moral and pragmatic, not legal. My complaint with Tivo as a distributor of Linux is what hinges on legal issues. > that's a seperate body of code that is in no way derived from the > linux kernel (even the anti-tampering functions would work equally > well with other Operating systems and are in no way linux > specific). it's no even loaded on the same media (the BIOS is in > flash/rom on the botherboard, the OS is on the hard drive) > > and note that the software that is checked to make sure that it hasn't > been changed includes much more then the kernel. it checks the kernel > and the initrd. Not legally relevant. >> Out of curiosity, what do you have to do on models besides those? Are >> newer models more or less restrictive in what they run? If newer >> models are more restrictive, I think that also speaks to whether Tivo >> thinks it is conveying complete source code. > > newer models do tend to be more restrictive, but they also tend to > connect to more propriatary networks (satellite or cable) What they connect to is also not relevant. That imples that because a vendor has been issued or licensed patents, they are not obliged to follow the GPL -- that the vendor has other obligations that supercede the GPL's license claims. GPL section 7 addresses that situation. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > no, saying that the result must be acceptable to other software (in > this case the software running in the BIOS) is not part of the source > code. Why not? The digital signature is a statement (which translates roughly to "Tivo approves this") to be used in a computer in order to bring about a certain result. That result is making it boot on the PVR. Source code simply means the original forms or inputs used to generate machine-readable statements. Michael Poole >>A "computer program" is a set of statements or instructions to be >>used directly or indirectly in a computer in order to bring about >>a certain result. >>-- US Code, Title 17, Section 101 - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > this is very much NOT true. if you take the source the provide you can > compile a kernel that will run on the tivo, the only thing you have to > do (on some models) is to change the bios to skip the step that checks > if the kernel has been tampered with. If we are opining whether Tivo provided complete source code for their Linux kernel images, the requirement to change non-GPLed software as a condition to exercise GPL-protected rights speaks for itself. Out of curiosity, what do you have to do on models besides those? Are newer models more or less restrictive in what they run? If newer models are more restrictive, I think that also speaks to whether Tivo thinks it is conveying complete source code. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Tomas Neme writes: >> It's simple: they don't provide _complete_ source code. They keep the >> source code for the part of their Linux kernel images that provides >> the functionality "runs on Tivo DVRs". The GPL requires that > > http://en.wikipedia.org/wiki/Tivoization does not agree that this is > the problem but rather "TiVo circumvented this goal by making their > products run programs only if the program's digital signature matches > those authorised by the manufacturer of the TiVo." > > I'm downloading the sources now.. if they compile, then you're lying > to me, right? Moreover, if I compile them as is, and I can run them on > a TiVo (let's say upgrading the machine's kernel) then you're even > more so.. Whether the sources you download from Tivo compile says very little. It certainly does not mean I am wrong. I could give you binary for version A and sources for version B -- and the sources would compile. The kernel you build from the source code that Tivo distributes must be accepted by Tivo's hardware without making other modifications (to Tivo's hardware or bootloader). If that is possible, I will retract what I said. If it is not possible, they are omitting part of the program's source code: A "computer program" is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. -- US Code, Title 17, Section 101 Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Tomas Neme writes: > I have been following this discussion for the last week or so, and > what I haven't been able to figure out is what the hell is the big > deal with TiVO doing whatever they want to with their stupid design. > They made a design, they build a machine, they sell it as is, and > provide source code for GPL'ed software... what's your problem? It's simple: they don't provide _complete_ source code. They keep the source code for the part of their Linux kernel images that provides the functionality "runs on Tivo DVRs". The GPL requires that distributors of binary versions provide complete source code, not just the parts of source code that are convenient. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Tomas Neme writes: I have been following this discussion for the last week or so, and what I haven't been able to figure out is what the hell is the big deal with TiVO doing whatever they want to with their stupid design. They made a design, they build a machine, they sell it as is, and provide source code for GPL'ed software... what's your problem? It's simple: they don't provide _complete_ source code. They keep the source code for the part of their Linux kernel images that provides the functionality runs on Tivo DVRs. The GPL requires that distributors of binary versions provide complete source code, not just the parts of source code that are convenient. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Tomas Neme writes: It's simple: they don't provide _complete_ source code. They keep the source code for the part of their Linux kernel images that provides the functionality runs on Tivo DVRs. The GPL requires that http://en.wikipedia.org/wiki/Tivoization does not agree that this is the problem but rather TiVo circumvented this goal by making their products run programs only if the program's digital signature matches those authorised by the manufacturer of the TiVo. I'm downloading the sources now.. if they compile, then you're lying to me, right? Moreover, if I compile them as is, and I can run them on a TiVo (let's say upgrading the machine's kernel) then you're even more so.. Whether the sources you download from Tivo compile says very little. It certainly does not mean I am wrong. I could give you binary for version A and sources for version B -- and the sources would compile. The kernel you build from the source code that Tivo distributes must be accepted by Tivo's hardware without making other modifications (to Tivo's hardware or bootloader). If that is possible, I will retract what I said. If it is not possible, they are omitting part of the program's source code: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. -- US Code, Title 17, Section 101 Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: this is very much NOT true. if you take the source the provide you can compile a kernel that will run on the tivo, the only thing you have to do (on some models) is to change the bios to skip the step that checks if the kernel has been tampered with. If we are opining whether Tivo provided complete source code for their Linux kernel images, the requirement to change non-GPLed software as a condition to exercise GPL-protected rights speaks for itself. Out of curiosity, what do you have to do on models besides those? Are newer models more or less restrictive in what they run? If newer models are more restrictive, I think that also speaks to whether Tivo thinks it is conveying complete source code. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: no, saying that the result must be acceptable to other software (in this case the software running in the BIOS) is not part of the source code. Why not? The digital signature is a statement (which translates roughly to Tivo approves this) to be used in a computer in order to bring about a certain result. That result is making it boot on the PVR. Source code simply means the original forms or inputs used to generate machine-readable statements. Michael Poole A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. -- US Code, Title 17, Section 101 - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: On Wed, 20 Jun 2007, Michael Poole wrote: [EMAIL PROTECTED] writes: this is very much NOT true. if you take the source the provide you can compile a kernel that will run on the tivo, the only thing you have to do (on some models) is to change the bios to skip the step that checks if the kernel has been tampered with. If we are opining whether Tivo provided complete source code for their Linux kernel images, the requirement to change non-GPLed software as a condition to exercise GPL-protected rights speaks for itself. no, the GPL protected rights don't say anything about the hardware the system runs on. you are saying that the GPL now controls what the BIOS software is allowed to do or not allowed to do. Please retract that claim. I have said no such thing, and have avoided saying anything that I thought might be misconstrued in that direction. To be absolutely clear: My complaints with Tivo as a hardware or BIOS vendor are moral and pragmatic, not legal. My complaint with Tivo as a distributor of Linux is what hinges on legal issues. that's a seperate body of code that is in no way derived from the linux kernel (even the anti-tampering functions would work equally well with other Operating systems and are in no way linux specific). it's no even loaded on the same media (the BIOS is in flash/rom on the botherboard, the OS is on the hard drive) and note that the software that is checked to make sure that it hasn't been changed includes much more then the kernel. it checks the kernel and the initrd. Not legally relevant. Out of curiosity, what do you have to do on models besides those? Are newer models more or less restrictive in what they run? If newer models are more restrictive, I think that also speaks to whether Tivo thinks it is conveying complete source code. newer models do tend to be more restrictive, but they also tend to connect to more propriatary networks (satellite or cable) What they connect to is also not relevant. That imples that because a vendor has been issued or licensed patents, they are not obliged to follow the GPL -- that the vendor has other obligations that supercede the GPL's license claims. GPL section 7 addresses that situation. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: On Wed, 20 Jun 2007, Michael Poole wrote: [EMAIL PROTECTED] writes: no, saying that the result must be acceptable to other software (in this case the software running in the BIOS) is not part of the source code. Why not? The digital signature is a statement (which translates roughly to Tivo approves this) to be used in a computer in order to bring about a certain result. That result is making it boot on the PVR. Source code simply means the original forms or inputs used to generate machine-readable statements. but the signature isn't part of the kernel, and the code that checks the signature is completely independant. and finally the PVR functions are not part of the kernel (and not under the GPL in any case) if your argument was true then Oracle releasing a database appliance would require Oracle to give you the source to their database since it's part of 'bringing about a certain result' namely operating as a database server. From the kernel's COPYING file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. See also the portion below. if your argument was true then releasing a GPL package for windows would require that the windows kernel source be released, after it it's nessasary for 'brining about a certain result' namely letting your code run. From section 3 of the GPL: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. these are both nonsense results. .. which is why they are recognized to be different. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: On Wed, 20 Jun 2007, Michael Poole wrote: Please retract that claim. I have said no such thing, and have avoided saying anything that I thought might be misconstrued in that direction. To be absolutely clear: My complaints with Tivo as a hardware or BIOS vendor are moral and pragmatic, not legal. My complaint with Tivo as a distributor of Linux is what hinges on legal issues. but if the GPL doesn't control the BIOS how in the world are you saying that the fact that the GPL covers the kernel makes what the BIOS does wrong (even if the kernel was covered by GPLv3)? I do not say that the BIOS is doing anything (legally) wrong. The wrong act is distributing the binary kernel image without distributing complete source code for it. that's a seperate body of code that is in no way derived from the linux kernel (even the anti-tampering functions would work equally well with other Operating systems and are in no way linux specific). it's no even loaded on the same media (the BIOS is in flash/rom on the botherboard, the OS is on the hard drive) and note that the software that is checked to make sure that it hasn't been changed includes much more then the kernel. it checks the kernel and the initrd. Not legally relevant. I disagree. it's very relevant if your argument is that becouse the checksum if a checksum of the kernel that the license for the kernel somehow controlls what can be done with it. To the extent that it is relevant, it strengthens the argument against Tivo: they are tying together many works of authorship, including some GPLed works, in a way that makes them effectively inseparable. This is beyond mere aggregation on a distribution medium, and tends to implicate *all* parts of the whole as GPL encumbered. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Tomas Neme writes: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. -- US Code, Title 17, Section 101 so? People keep arguing that the signature is somehow not part of the kernel or not subject to copyright law. I suspect they do not realize how broad the legal definition of computer program is. Not GPL related, but casino machine software that needs to be approved by the casino regulation office in Argentina need to provide source, compiling instructions AND binaries, and the binaries must pass a diff check. This is impossible without a hacked compiler since the timestamps WILL differ. Just an example that legality doesn't always comply with itself, and even less make sense. This discussion is about copyright and the GPL, not legal quirks. I am aware of a large number of silly results reached by law. plus, and I repeat myself.. the program comes with no warranties whatsoever. and if your complains are purely moral, see it this way: if TiVo didn't sign their kernel, digital cable providers wouldn't give them their hash keys, and they wouldn't be able to show HD signals, rendering them useless, and making them go bankrupt... so they'd go BSD, because they ARE a company after all, and they are after The Moneys.. no? The GPL does not guarantee anyone a viable business model. Following it is not conditional on profitability. It is only conditional on exercising rights that are granted by the GPL. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: I do not say that the BIOS is doing anything (legally) wrong. The wrong act is distributing the binary kernel image without distributing complete source code for it. Why are you not complaining that Linus does not distribute the keys he uses to sign kernel source distributions? If a digital signature is part of the distribution, why is the key used to produce that signature not part of the distribution? If you can cite some legal reason there is a difference, I would be quite impressed. In any event, the argument is obvious nonsense. The signature is merely aggregated with the kernel. Cooperation, dependent function, and convergent design can't break mere aggregation or you get ridiculous results. (For example, a device shipped with the Linux kernel and some applications would have to GPL all the applications.) Do you make it a habit to pose ranty questions to people while neither attributing their text nor cc'ing them? Especially when you claim the person's argument is obvious nonsense, it seems quite rude. (Since you have dismissed my argument as nonsense before hearing my response, I will not bother answering your question. Since you are acting like a troll, I will dismiss you as one. Most of this list has already dismissed your rather unique -- I would even say frivolous -- idea of how far mere aggregation goes: I, for one, have better things to do than explain why a C file is not a mere aggregation of the functions it contains.) Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: Most of this list has already dismissed your rather unique -- I would even say frivolous -- idea of how far mere aggregation goes: I, for one, have better things to do than explain why a C file is not a mere aggregation of the functions it contains.) Michael Poole Of course it's not mere aggregation. The functions in a C file are creatively combined. How many times do I have to say that the opposite of mere aggregation is creative combination? It is not unique, it is part of the definition of a derivative work. By creative combination do you mean what US copyright law refers to as compilations (or their subset collective works)? Compilations can be creative combinations while still being mere aggregation under the GPL. For example, if applications are selected to run with a Linux kernel, and they are distributed together, the collection is a creative selection -- and this seems to be one of the cases evoked by the GPL's reference to mere aggregation. See also practically every Linux distribution on the planet. Compilations also can be creative combinations and *more* than mere aggregation: for example, Linux with respect to its subsystems, or any case where a larger work is derivative of one of its components. However, compilations (even to the extent they are creative combinations) are not necessarily derivative works of their elements. For more details, see http://www.copyright.gov/circs/circ14.html#compilations Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: However, compilations (even to the extent they are creative combinations) are not necessarily derivative works of their elements. For more details, see http://www.copyright.gov/circs/circ14.html#compilations Because compilation copyrights don't really affect the Tivo and GPLv2/GPLv3 issue, I tend to ignore them when discussing that subject. If you think I'm wrong and there is some relationship between them, please let me know. I admit I may not have given that possibility enough thought. I believe compilation copyrights do bear on GPL-licensed software, by virtue of the GPL's sentence [...] rather, the intent is to exercise the right to control the distribution of derivative _or collective_ works based on the Program. (emphasis added). There is a lot of grey and/or arguable area about what constitutes a GPL-encumbered collective work versus mere aggregation. Although I disagree, I understand and respect that some believe that the kernel plus a digital signature over it is mere aggregation. I would like to focus the discussion on that question, though, rather than whether the GPL is worded to control the rights to compilations-in-general that include GPLed works. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: There is a lot of grey and/or arguable area about what constitutes a GPL-encumbered collective work versus mere aggregation. I think it's technically/legally clear what the standards are, but certainly arguable whether particular works meet that standard. If the choice of works to combine is sufficiently creative (above and beyond any choices dictated by functional considerations), it's a GPL-encumbered collective work. I don't think it's arguable that a signature shipped along with a binary is a collective work. In any event, if that were true, I think we should be able to agree that Linus would be required to release his kernel signing keys. The distinction between GPL-covered works and mere aggregation is not a function only of legal classifications. If it were, the GPL would be worded differently than it is -- and have different effects than most people believe it does. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: if the GPL can excercise control over compilations, then if Oracle were to ship a Oracle Linux live CD that contained the Oracle Database in the filesystem image, ready to run. then the GPL would be able to control the Oracle Database code. By copyright law, it could. By its language, it does not. if the GPL can't do this then it can't control the checksum either. again, it's not just the kernel that's part of the checksum on a tivo, the checksum is over the kernel + initial filesystem, much of which contains code not covered by the gPL) Again, did you miss where I pointed out that this makes it *worse* for Tivo, because they are tying together -- and making inseparable -- a combination that would otherwise be mere aggregation? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: On Wed, 20 Jun 2007, Michael Poole wrote: [EMAIL PROTECTED] writes: if the GPL can excercise control over compilations, then if Oracle were to ship a Oracle Linux live CD that contained the Oracle Database in the filesystem image, ready to run. then the GPL would be able to control the Oracle Database code. By copyright law, it could. By its language, it does not. many people (including many lawyers will disagree that it could by copyright law On what grounds would Oracle have a license to ship that part of Linux? Unless you are the sole copyright owner, you have no right to copy a given piece of software _at all_ without a license. The GPL is a remarkably giving license in terms of how little it requires. (This potentially wide scope is one of the major reasons that the GPL mentions mere aggregation and that the Debian Free Software Guidelines' include guideline #9.) if the GPL can't do this then it can't control the checksum either. again, it's not just the kernel that's part of the checksum on a tivo, the checksum is over the kernel + initial filesystem, much of which contains code not covered by the gPL) Again, did you miss where I pointed out that this makes it *worse* for Tivo, because they are tying together -- and making inseparable -- a combination that would otherwise be mere aggregation? and it makes most distro CD's illegal since they contain code under different incompatible licenses and they make a checksum across the entire CD image. When distributions generate checksums (as opposed to signatures) over images, they do provide all of the inputs. When most distributions provide signatures, the signatures do not function as statements or instructions to computers -- they function as statements to users. Tivo's digital signatures differ in both of these respects. Michael Poole - 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: mea culpa on the meaning of Tivoization
Hans-Jürgen Koch writes: > No. Credible licenses should be simple like physical laws. Newton's law > is expressed in terms of a single mathematical equation. That's why it's > still valid, and you still learn it at school although meanwhile people > know that there are limitations to it. > > If you come up with a new version of a license every year, you will only > weaken it. Please note that quantum mechanics is _not_ such a hole-plugging > addition to Newton's law. It's a new simple physical law, expressed in terms > of a single simple mathematical equation that contains the old law as a > border case. If that were not the case, it would have never been accepted. This is an excellent example of how engineers tend to mis-analyze legal issues. In law, neither simple wording nor interpretation is so simple or so mechanical as the things engineers prefer to work with. Take an example: "Thou shalt not kill". Very clear, but also very problematic in that it does not address military conquests (which were apparently approved by that law's drafter), self-defense, or a number of other cases. There are always grey areas between what is explicitly addressed and what is not. Courts interpret laws and precedent in ways that make life (and license or contract writing) more unpredictable. Wishing otherwise will not make a simple license unambiguous. If those areas of ambiguity are exploited enough, the perceived cost of having a hole will exceed the perceived cost of plugging it. Michael Poole - 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: mea culpa on the meaning of Tivoization
Hans-Jürgen Koch writes: No. Credible licenses should be simple like physical laws. Newton's law is expressed in terms of a single mathematical equation. That's why it's still valid, and you still learn it at school although meanwhile people know that there are limitations to it. If you come up with a new version of a license every year, you will only weaken it. Please note that quantum mechanics is _not_ such a hole-plugging addition to Newton's law. It's a new simple physical law, expressed in terms of a single simple mathematical equation that contains the old law as a border case. If that were not the case, it would have never been accepted. This is an excellent example of how engineers tend to mis-analyze legal issues. In law, neither simple wording nor interpretation is so simple or so mechanical as the things engineers prefer to work with. Take an example: Thou shalt not kill. Very clear, but also very problematic in that it does not address military conquests (which were apparently approved by that law's drafter), self-defense, or a number of other cases. There are always grey areas between what is explicitly addressed and what is not. Courts interpret laws and precedent in ways that make life (and license or contract writing) more unpredictable. Wishing otherwise will not make a simple license unambiguous. If those areas of ambiguity are exploited enough, the perceived cost of having a hole will exceed the perceived cost of plugging it. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: >> David Schwartz writes: > >> >> First, end users buy and use the hardware in question. It does not >> >> belong to Tivo, so the analogy to his laptop fails there. > >> > No, this is incorrect. They buy *some* of the rights to the >> > hardware but not >> > all of them. Specifically, they do not buy the right to choose >> > what software >> > runs on that hardware. That right is still owned by TiVo. > >> Do you have a reference to the contract establishing that cession of >> rights from the buyer to Tivo? > > No, and I submit that this is at least arguably something wrong that TiVo is > doing. Note that Microsoft does this too when you buy an Xbox. It has > nothing to do with the GPL. There is a significant difference between what is a legally recognized right and what no one has litigated over. I tend to not recognize the latter as the former until I see specific backing for the idea that the purported right has been recognized by law, a court, or all involved parties. >> To the extent that some contract >> purports to restrict the user in ways contrary to the GPL, I suspect >> Tivo might have a hard time defending it in court. > > I agree, however, this doesn't restrict the user in ways contrary to the > GPL. The GPL does not say that you have to be allowed to modify the Linux > running on some particular piece of hardware because that is a legitimate > authorization decision. TiVo not letting you change the software is the same > as me not letting you change the software on my laptop. I disagree that the two are the same -- for the fundamental reason that you have not distributed the software on your laptop to me. Tivo has distributed the software on Tivo DVRs to their customers. The act of distribution is governed by (in the case of Linux) copyright law and the GPL. >> > You can argue that TiVo is being dishonest, breaking the law, >> > being immoral, >> > or whatever in retaining this right or in failing to disclose that they >> > retain it. But you cannot coherently deny that TiVo retains >> > this right when >> > they sell certain other rights to the hardware. > >> By the first sale doctrine, someone who buys an item has practically >> unlimited rights to deal with it or dispose of it as the buyer wishes. > > This is solely a right against copyright claims. You would be correct if > TiVo were going to sue you for violating some copyright they hold in the > hardware or software if you modified the software. Do you propose that Tivo would (or could) sue a customer for some non-copyright tort if the customer were to run a Linux kernel that has not been authorized by Tivo on a Tivo-manufactured DVR? As far as I can tell, the legal concerns in question are all copyright issues. >> The only things that would restrict that are statute or a contract >> entered as part of the sale -- most likely a EULA or other shrink-wrap >> agreement. Given that most such recognized agreements deal with >> software or services rather than hardware, I am not sure a court would >> recognize a hardware EULA as being binding. (I suspect this is the >> direction you were heading with the paragraph below.) > > Yep, but that has nothing whatsoever to do with the GPL. The exact same > argument applies with the Xbox. It's about whether authorization to modify a > device should or must come with buying that device. > > The GPL was never about allowing you to load modified software onto hardware > where the legitimate creators/owners of that hardware say, "no, you may not > modify the software running on this hardware". True. The GPL always about allowing someone to modify software that they received from someone else. Tivo's Linux kernel images qualify both as softare that they distribute to others and software that is loaded onto hardware that they created. The concern at hand is not about hardware that Tivo owns or software that Tivo never distributes -- except where it is also source code for software that they *do* distribute. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: >> First, end users buy and use the hardware in question. It does not >> belong to Tivo, so the analogy to his laptop fails there. > > No, this is incorrect. They buy *some* of the rights to the hardware but not > all of them. Specifically, they do not buy the right to choose what software > runs on that hardware. That right is still owned by TiVo. Do you have a reference to the contract establishing that cession of rights from the buyer to Tivo? To the extent that some contract purports to restrict the user in ways contrary to the GPL, I suspect Tivo might have a hard time defending it in court. > You can argue that TiVo is being dishonest, breaking the law, being immoral, > or whatever in retaining this right or in failing to disclose that they > retain it. But you cannot coherently deny that TiVo retains this right when > they sell certain other rights to the hardware. By the first sale doctrine, someone who buys an item has practically unlimited rights to deal with it or dispose of it as the buyer wishes. The only things that would restrict that are statute or a contract entered as part of the sale -- most likely a EULA or other shrink-wrap agreement. Given that most such recognized agreements deal with software or services rather than hardware, I am not sure a court would recognize a hardware EULA as being binding. (I suspect this is the direction you were heading with the paragraph below.) Michael Poole > I do in fact argue that there are things that are wrong with TiVo doing > this. But they are not GPL-related things. I would make these same arguments > if the TiVo contained no GPL'd software and I in fact do make them about > products like the Xbox. > > 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > On Mon, 18 Jun 2007, Alexandre Oliva wrote: > >> On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote: >> >>>>> Sure, and you use the hardware to stop me from modifying the >>>>> Linux on your >>>>> laptop. >> >>>> Do I? How so? >> >>> Any number of ways. For example, you probably don't connect the serial ports >>> to a device I have access to. >> >> But you're not the user of the software on my laptop. I am. > > ahh, but by your own argument you aren't > > the software on your laptop is owned by people like Linus, Al Viro, > David M, Alan Cox, etc. To be pedantic, the *copyrights* for certain software on his laptop are owned by those people. (Fortunately, they have been friendly enough to engage in software quid-pro-quo with those rights.) > they have the right to put a license on that software that would > require you to give them access to your hardware (after all, that's > the argument that you are useing to justify requireing Tivo to give > you access to their hardware) Even as straw men go, that is pretty incoherent. First, end users buy and use the hardware in question. It does not belong to Tivo, so the analogy to his laptop fails there. Second, the important access is not to the hardware, but to the bits used to build the version of Linux that is distributed by Tivo. This is purely software. Third, such a license would be neither a free software nor an open source license. No one argues it would be. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: On Mon, 18 Jun 2007, Alexandre Oliva wrote: On Jun 18, 2007, David Schwartz [EMAIL PROTECTED] wrote: Sure, and you use the hardware to stop me from modifying the Linux on your laptop. Do I? How so? Any number of ways. For example, you probably don't connect the serial ports to a device I have access to. But you're not the user of the software on my laptop. I am. ahh, but by your own argument you aren't the software on your laptop is owned by people like Linus, Al Viro, David M, Alan Cox, etc. To be pedantic, the *copyrights* for certain software on his laptop are owned by those people. (Fortunately, they have been friendly enough to engage in software quid-pro-quo with those rights.) they have the right to put a license on that software that would require you to give them access to your hardware (after all, that's the argument that you are useing to justify requireing Tivo to give you access to their hardware) Even as straw men go, that is pretty incoherent. First, end users buy and use the hardware in question. It does not belong to Tivo, so the analogy to his laptop fails there. Second, the important access is not to the hardware, but to the bits used to build the version of Linux that is distributed by Tivo. This is purely software. Third, such a license would be neither a free software nor an open source license. No one argues it would be. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: First, end users buy and use the hardware in question. It does not belong to Tivo, so the analogy to his laptop fails there. No, this is incorrect. They buy *some* of the rights to the hardware but not all of them. Specifically, they do not buy the right to choose what software runs on that hardware. That right is still owned by TiVo. Do you have a reference to the contract establishing that cession of rights from the buyer to Tivo? To the extent that some contract purports to restrict the user in ways contrary to the GPL, I suspect Tivo might have a hard time defending it in court. You can argue that TiVo is being dishonest, breaking the law, being immoral, or whatever in retaining this right or in failing to disclose that they retain it. But you cannot coherently deny that TiVo retains this right when they sell certain other rights to the hardware. By the first sale doctrine, someone who buys an item has practically unlimited rights to deal with it or dispose of it as the buyer wishes. The only things that would restrict that are statute or a contract entered as part of the sale -- most likely a EULA or other shrink-wrap agreement. Given that most such recognized agreements deal with software or services rather than hardware, I am not sure a court would recognize a hardware EULA as being binding. (I suspect this is the direction you were heading with the paragraph below.) Michael Poole I do in fact argue that there are things that are wrong with TiVo doing this. But they are not GPL-related things. I would make these same arguments if the TiVo contained no GPL'd software and I in fact do make them about products like the Xbox. 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
David Schwartz writes: David Schwartz writes: First, end users buy and use the hardware in question. It does not belong to Tivo, so the analogy to his laptop fails there. No, this is incorrect. They buy *some* of the rights to the hardware but not all of them. Specifically, they do not buy the right to choose what software runs on that hardware. That right is still owned by TiVo. Do you have a reference to the contract establishing that cession of rights from the buyer to Tivo? No, and I submit that this is at least arguably something wrong that TiVo is doing. Note that Microsoft does this too when you buy an Xbox. It has nothing to do with the GPL. There is a significant difference between what is a legally recognized right and what no one has litigated over. I tend to not recognize the latter as the former until I see specific backing for the idea that the purported right has been recognized by law, a court, or all involved parties. To the extent that some contract purports to restrict the user in ways contrary to the GPL, I suspect Tivo might have a hard time defending it in court. I agree, however, this doesn't restrict the user in ways contrary to the GPL. The GPL does not say that you have to be allowed to modify the Linux running on some particular piece of hardware because that is a legitimate authorization decision. TiVo not letting you change the software is the same as me not letting you change the software on my laptop. I disagree that the two are the same -- for the fundamental reason that you have not distributed the software on your laptop to me. Tivo has distributed the software on Tivo DVRs to their customers. The act of distribution is governed by (in the case of Linux) copyright law and the GPL. You can argue that TiVo is being dishonest, breaking the law, being immoral, or whatever in retaining this right or in failing to disclose that they retain it. But you cannot coherently deny that TiVo retains this right when they sell certain other rights to the hardware. By the first sale doctrine, someone who buys an item has practically unlimited rights to deal with it or dispose of it as the buyer wishes. This is solely a right against copyright claims. You would be correct if TiVo were going to sue you for violating some copyright they hold in the hardware or software if you modified the software. Do you propose that Tivo would (or could) sue a customer for some non-copyright tort if the customer were to run a Linux kernel that has not been authorized by Tivo on a Tivo-manufactured DVR? As far as I can tell, the legal concerns in question are all copyright issues. The only things that would restrict that are statute or a contract entered as part of the sale -- most likely a EULA or other shrink-wrap agreement. Given that most such recognized agreements deal with software or services rather than hardware, I am not sure a court would recognize a hardware EULA as being binding. (I suspect this is the direction you were heading with the paragraph below.) Yep, but that has nothing whatsoever to do with the GPL. The exact same argument applies with the Xbox. It's about whether authorization to modify a device should or must come with buying that device. The GPL was never about allowing you to load modified software onto hardware where the legitimate creators/owners of that hardware say, no, you may not modify the software running on this hardware. True. The GPL always about allowing someone to modify software that they received from someone else. Tivo's Linux kernel images qualify both as softare that they distribute to others and software that is loaded onto hardware that they created. The concern at hand is not about hardware that Tivo owns or software that Tivo never distributes -- except where it is also source code for software that they *do* distribute. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > Okay. So they give everyone the right to change the software on the box, but > on connection replace the modified stuff with the official versions. Is that > still a copyright problem? Absolutely, positively no. Is the current > situation any different? Not that I can tell - they've changed a reaction > into a preemptive act. Again, it would be useful to limit discussions to this universe rather than one that contains fictions necessary to your religious views. (Separately, hardware connecting to Tivo's network is hardly related to why they have DRM at all, and _entirely_ unrelated to what the GPL permits; basing your argument on that nexus is stupid, but you have obviously given up on your previous idea that the signature is somehow an independent work of authorship and need some -- any -- theory to continue holding to your general faith.) >> > Nope. Because that isn't a right they have that is disconnected from >> > copyright law. Or did you not read the entire post and just decide to try >> > and make me look stupid? >> >> I read your post, but it was full of nonsense. Tivo has every right >> to restrict what connects to their network. Tivo does not have the >> right to infringe copyrights in order to make that restriction >> effective. > > Okay - "nonsense" in this sense meaning "it proves me wrong, but I can't be > wrong, so it has no real meaning." I can accept that. No; it means your position is at odds to fact, law and logic. The rest of my paragraph summarized why your argument is garbage. Have you ever heard of the lawyer joke that if law is on your side, you should pound the law; that if fact is on your side, you should pound the facts; and that if neither are on your side, you should pound the table? You seem to be in the third state. You suggested that Tivo's right to set terms for their network gave them the right to modify the Linux kernel. I twice pointed out in my email that it did not -- that only the GPL gives them that right. Any right to modify the Linux kernel is inherently connected to copyright. Kindly either refute or acknowledge that point: then this discussion can advance. >> You have said -- using enough words that you probably deceived >> yourself -- that if Tivo distributes a specially mangled version of >> Linux in order to restrict what connects to their network, and they >> keep the mangling method proprietary, the GPL cannot shed light on >> whether that hoarding is allowed. Wrong: it can and does. > > But the mangling method isn't proprietary. What is proprietary is a number > that is input to a step of the process. (AFAICT the signing process is done > with proprietary tools, but the process itself isn't) That does not help them at all. In fact, it is probably *worse* for Tivo if they are intentionally withholding input to a tool, since that is closer to the traditional idea of source code. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > On Sunday 17 June 2007 09:54:39 Michael Poole wrote: >> Daniel Hazelton writes: >> > But your server doesn't run the internet. TiVO may use phone lines to >> > connect a device to their server (and this is an example - I don't know >> > how TiVO devices actually connect) but the network being connected to has >> > a single owner who can set such terms. >> > >> > I'll repeat, in full, my earlier examples of this: >> > The first: >> > I buy a cable modem. Until the second I connect the cable-line to it so I >> > can get a connection to the internet I can configure it in whatever >> > manner I please. The second the line is connected, even though I *OWN* >> > the hardware, I lose all control over its configuration. >> > >> > The second: >> > I buy a DSL modem. Until I want to actually connect to the internet it >> > can have whatever settings I want it to have. The second I want to >> > connect to the internet it has to be configured the way that the ISP >> > wants. >> >> Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl >> orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf? >> >> One moment, let me retune. >> >> What in the world makes you think there is a useful analogy >> between communication standards and copyright licenses? > > I don't. I was *REPEATING* an example of how TiVO has a *RIGHT* to change the > kernel or any other facet of the device connecting to their network. That > right *ISN'T* tied to copyright - as you have stated. Since it isn't, why is > the FSF trying to mandate that it is with the tivoization clauses in GPLv3? The FSF *ISN'T* trying to mandate what *CONNECTS* to *TiVO's* *NETWORK*. *BOY* *ISN'T* *SHOUTING* *FUN*? If Tivo wants to restrict what connects to their network, the GPL and FSF will not stop them. The major new (relative to GPLv2) things the FSF is trying to restrict are new technical and legal methods that software distributors have tried to use to convert free software into non-free software. Tivo's right to dictate or change aspects of devices connecting to their network is very much tied to copyright: Tivo needs appropriate license if they are modifying or distributing anyone else's work. I am not sure why you think Tivo's right to free association trumps its freely entered obligations to copyright owners. >> Neither law nor common sense give much common ground to the two, >> except in the general sense of two parties interacting. One is a set >> of rules so the two can interact through some information channel. >> The other is a set of rules so that one can exploit a creative work >> developed by the other. >> >> I suppose that you think it is acceptable for someone to offer access >> to binary and source versions of GPLed software (with or without >> modifications from commonly available versions) -- but only on the >> condition that people never download the source versions? That >> certainly corresponds to the idea that Tivo can keep proprietary >> extensions to the kernel if Tivo's customers want to connect to Tivo's >> network services. > > Nope. Because that isn't a right they have that is disconnected from > copyright > law. Or did you not read the entire post and just decide to try and make me > look stupid? I read your post, but it was full of nonsense. Tivo has every right to restrict what connects to their network. Tivo does not have the right to infringe copyrights in order to make that restriction effective. You have said -- using enough words that you probably deceived yourself -- that if Tivo distributes a specially mangled version of Linux in order to restrict what connects to their network, and they keep the mangling method proprietary, the GPL cannot shed light on whether that hoarding is allowed. Wrong: it can and does. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > But your server doesn't run the internet. TiVO may use phone lines to connect > a device to their server (and this is an example - I don't know how TiVO > devices actually connect) but the network being connected to has a single > owner who can set such terms. > > I'll repeat, in full, my earlier examples of this: > The first: > I buy a cable modem. Until the second I connect the cable-line to it so I can > get a connection to the internet I can configure it in whatever manner I > please. The second the line is connected, even though I *OWN* the hardware, I > lose all control over its configuration. > > The second: > I buy a DSL modem. Until I want to actually connect to the internet it can > have whatever settings I want it to have. The second I want to connect to the > internet it has to be configured the way that the ISP wants. Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf? One moment, let me retune. What in the world makes you think there is a useful analogy between communication standards and copyright licenses? Neither law nor common sense give much common ground to the two, except in the general sense of two parties interacting. One is a set of rules so the two can interact through some information channel. The other is a set of rules so that one can exploit a creative work developed by the other. I suppose that you think it is acceptable for someone to offer access to binary and source versions of GPLed software (with or without modifications from commonly available versions) -- but only on the condition that people never download the source versions? That certainly corresponds to the idea that Tivo can keep proprietary extensions to the kernel if Tivo's customers want to connect to Tivo's network services. Your reliance on counterfactual arguments severely undermines your position -- whether the fiction is how Tivo devices connect (a quick search on Google indicates that Tivo recommends a broadband Ethernet connection rather than a phone line) or that we should analyze based on DRM signatures distributed separately from the kernel (when they are not). We are arguing about the universe we inhabit, not some alternative where the GPL might actually be the Groundhog Petting License. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: > * Alexandre Oliva <[EMAIL PROTECTED]> wrote: > >> On Jun 15, 2007, Ingo Molnar <[EMAIL PROTECTED]> wrote: >> >> > it is a false statement on your part that the executable "does not >> > function properly" if it lacks that part. Try it: take out the harddisk >> > from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux >> > PC, mount it, modify a bit in the kernel image header and it will likely >> > still boot just fine on that PC. >> >> Ok, try this: take the disk out, remove/replace/modify the signature, >> put the disk back in, and tell me what it is that fail to run. > > you mean back into the Tivo? That is not support for what you claimed. > You claimed the "executable does not function properly" if it lacks that > part (and you did not qualify your statement with anything). That was a > false statement, because it still works fine in just about any > bog-standard PC. A true statement would be: "the modified executable > does not function properly _in the Tivo_". It still works fine on a > general purpose PC. I claimed that. Unless I missed something, Alexandre did not. Ability to run on a standard PC is irrelevant. Tivo distributes the executable for the specific purpose of running on their hardware. Having the signature accepted by the hardware is a critical aspect of the executable. That purpose and function are what make the signature part of the work based on Linux. Courts consider purpose and intent when analyzing actions; except when one has bought the best available legal system, they would not follow your logic. (The role the signature plays in controlling access to a copyrighted work, per DMCA, might also separately identify it as part of the work based on Linux.) If I wished to distribute a kernel with extended functionality from a C file but not the C source files, under your logic I need not give them out -- a user could modify the binary and run it on a general purpose PC. Right? At most it would take clever linker tricks to make the change small enough. As to the suggestion that vendors would use another kernel: I would not mind. A huge fraction of the interesting and useful work in open source kernels happens in Linux (first or only). Using any third party software is a trade-off of what you get versus what you give up. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: * Alexandre Oliva [EMAIL PROTECTED] wrote: On Jun 15, 2007, Ingo Molnar [EMAIL PROTECTED] wrote: it is a false statement on your part that the executable does not function properly if it lacks that part. Try it: take out the harddisk from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux PC, mount it, modify a bit in the kernel image header and it will likely still boot just fine on that PC. Ok, try this: take the disk out, remove/replace/modify the signature, put the disk back in, and tell me what it is that fail to run. you mean back into the Tivo? That is not support for what you claimed. You claimed the executable does not function properly if it lacks that part (and you did not qualify your statement with anything). That was a false statement, because it still works fine in just about any bog-standard PC. A true statement would be: the modified executable does not function properly _in the Tivo_. It still works fine on a general purpose PC. I claimed that. Unless I missed something, Alexandre did not. Ability to run on a standard PC is irrelevant. Tivo distributes the executable for the specific purpose of running on their hardware. Having the signature accepted by the hardware is a critical aspect of the executable. That purpose and function are what make the signature part of the work based on Linux. Courts consider purpose and intent when analyzing actions; except when one has bought the best available legal system, they would not follow your logic. (The role the signature plays in controlling access to a copyrighted work, per DMCA, might also separately identify it as part of the work based on Linux.) If I wished to distribute a kernel with extended functionality from a C file but not the C source files, under your logic I need not give them out -- a user could modify the binary and run it on a general purpose PC. Right? At most it would take clever linker tricks to make the change small enough. As to the suggestion that vendors would use another kernel: I would not mind. A huge fraction of the interesting and useful work in open source kernels happens in Linux (first or only). Using any third party software is a trade-off of what you get versus what you give up. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: But your server doesn't run the internet. TiVO may use phone lines to connect a device to their server (and this is an example - I don't know how TiVO devices actually connect) but the network being connected to has a single owner who can set such terms. I'll repeat, in full, my earlier examples of this: The first: I buy a cable modem. Until the second I connect the cable-line to it so I can get a connection to the internet I can configure it in whatever manner I please. The second the line is connected, even though I *OWN* the hardware, I lose all control over its configuration. The second: I buy a DSL modem. Until I want to actually connect to the internet it can have whatever settings I want it to have. The second I want to connect to the internet it has to be configured the way that the ISP wants. Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf? One moment, let me retune. What in the world makes you think there is a useful analogy between communication standards and copyright licenses? Neither law nor common sense give much common ground to the two, except in the general sense of two parties interacting. One is a set of rules so the two can interact through some information channel. The other is a set of rules so that one can exploit a creative work developed by the other. I suppose that you think it is acceptable for someone to offer access to binary and source versions of GPLed software (with or without modifications from commonly available versions) -- but only on the condition that people never download the source versions? That certainly corresponds to the idea that Tivo can keep proprietary extensions to the kernel if Tivo's customers want to connect to Tivo's network services. Your reliance on counterfactual arguments severely undermines your position -- whether the fiction is how Tivo devices connect (a quick search on Google indicates that Tivo recommends a broadband Ethernet connection rather than a phone line) or that we should analyze based on DRM signatures distributed separately from the kernel (when they are not). We are arguing about the universe we inhabit, not some alternative where the GPL might actually be the Groundhog Petting License. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: On Sunday 17 June 2007 09:54:39 Michael Poole wrote: Daniel Hazelton writes: But your server doesn't run the internet. TiVO may use phone lines to connect a device to their server (and this is an example - I don't know how TiVO devices actually connect) but the network being connected to has a single owner who can set such terms. I'll repeat, in full, my earlier examples of this: The first: I buy a cable modem. Until the second I connect the cable-line to it so I can get a connection to the internet I can configure it in whatever manner I please. The second the line is connected, even though I *OWN* the hardware, I lose all control over its configuration. The second: I buy a DSL modem. Until I want to actually connect to the internet it can have whatever settings I want it to have. The second I want to connect to the internet it has to be configured the way that the ISP wants. Jung va gur jbeyq znxrf lbh guvax gurer vf n hfrshy nanybtl orgjrra pbzzhavpngvba fgnaqneqf naq pbclevtug yvprafrf? One moment, let me retune. What in the world makes you think there is a useful analogy between communication standards and copyright licenses? I don't. I was *REPEATING* an example of how TiVO has a *RIGHT* to change the kernel or any other facet of the device connecting to their network. That right *ISN'T* tied to copyright - as you have stated. Since it isn't, why is the FSF trying to mandate that it is with the tivoization clauses in GPLv3? The FSF *ISN'T* trying to mandate what *CONNECTS* to *TiVO's* *NETWORK*. *BOY* *ISN'T* *SHOUTING* *FUN*? If Tivo wants to restrict what connects to their network, the GPL and FSF will not stop them. The major new (relative to GPLv2) things the FSF is trying to restrict are new technical and legal methods that software distributors have tried to use to convert free software into non-free software. Tivo's right to dictate or change aspects of devices connecting to their network is very much tied to copyright: Tivo needs appropriate license if they are modifying or distributing anyone else's work. I am not sure why you think Tivo's right to free association trumps its freely entered obligations to copyright owners. Neither law nor common sense give much common ground to the two, except in the general sense of two parties interacting. One is a set of rules so the two can interact through some information channel. The other is a set of rules so that one can exploit a creative work developed by the other. I suppose that you think it is acceptable for someone to offer access to binary and source versions of GPLed software (with or without modifications from commonly available versions) -- but only on the condition that people never download the source versions? That certainly corresponds to the idea that Tivo can keep proprietary extensions to the kernel if Tivo's customers want to connect to Tivo's network services. Nope. Because that isn't a right they have that is disconnected from copyright law. Or did you not read the entire post and just decide to try and make me look stupid? I read your post, but it was full of nonsense. Tivo has every right to restrict what connects to their network. Tivo does not have the right to infringe copyrights in order to make that restriction effective. You have said -- using enough words that you probably deceived yourself -- that if Tivo distributes a specially mangled version of Linux in order to restrict what connects to their network, and they keep the mangling method proprietary, the GPL cannot shed light on whether that hoarding is allowed. Wrong: it can and does. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: Okay. So they give everyone the right to change the software on the box, but on connection replace the modified stuff with the official versions. Is that still a copyright problem? Absolutely, positively no. Is the current situation any different? Not that I can tell - they've changed a reaction into a preemptive act. Again, it would be useful to limit discussions to this universe rather than one that contains fictions necessary to your religious views. (Separately, hardware connecting to Tivo's network is hardly related to why they have DRM at all, and _entirely_ unrelated to what the GPL permits; basing your argument on that nexus is stupid, but you have obviously given up on your previous idea that the signature is somehow an independent work of authorship and need some -- any -- theory to continue holding to your general faith.) Nope. Because that isn't a right they have that is disconnected from copyright law. Or did you not read the entire post and just decide to try and make me look stupid? I read your post, but it was full of nonsense. Tivo has every right to restrict what connects to their network. Tivo does not have the right to infringe copyrights in order to make that restriction effective. Okay - nonsense in this sense meaning it proves me wrong, but I can't be wrong, so it has no real meaning. I can accept that. No; it means your position is at odds to fact, law and logic. The rest of my paragraph summarized why your argument is garbage. Have you ever heard of the lawyer joke that if law is on your side, you should pound the law; that if fact is on your side, you should pound the facts; and that if neither are on your side, you should pound the table? You seem to be in the third state. You suggested that Tivo's right to set terms for their network gave them the right to modify the Linux kernel. I twice pointed out in my email that it did not -- that only the GPL gives them that right. Any right to modify the Linux kernel is inherently connected to copyright. Kindly either refute or acknowledge that point: then this discussion can advance. You have said -- using enough words that you probably deceived yourself -- that if Tivo distributes a specially mangled version of Linux in order to restrict what connects to their network, and they keep the mangling method proprietary, the GPL cannot shed light on whether that hoarding is allowed. Wrong: it can and does. But the mangling method isn't proprietary. What is proprietary is a number that is input to a step of the process. (AFAICT the signing process is done with proprietary tools, but the process itself isn't) That does not help them at all. In fact, it is probably *worse* for Tivo if they are intentionally withholding input to a tool, since that is closer to the traditional idea of source code. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Florin Malita writes: > On 06/15/2007 12:18 PM, Michael Poole wrote: >> Florin Malita writes: >> >> >>> On 06/15/2007 10:56 AM, Michael Poole wrote: >>> >>>> The GPL cares about the key >>>> used to generate an integral part of the executable form of the GPLed >>>> work. >>> GLPv2 doesn't: why do you think the digital signature is an integral >>> part of the executable? It can be a totally separate blob, distributed >>> via a separate channel and even stored at a different location than >>> the executable. Does it still look like an integral part of the >>> executable to you then? >>> >> >> Yes. If I cut a book in half and store the halves separately, does >> the second half become an independent work? > > Except in this case you're not touching the book at all. If you write > a review for a book (much better analogy methinks), then your review > is obviously not an integral part of the book even though it's based > on its content. Extremely poor analogy. I do not distribute my review with the book. Someone buying the book is able to use the book just fine (for the purpose for which it was sold) without my review. They need neither my review nor other modifications before the book becomes readable. As Ingo said, you need either the digital signature or other changes before a Tivo kernel image will load. >> The integral-ness is a >> function of how the thing is created and how it functions, not how it >> is stored. If you need part B for part A to execute as intended, then >> part A is not a complete work in itself. > > Being an integral part (as in combined or derived work) has nothing to > do with usability. There are many other bits and pieces your > executable needs in order to function properly (or at all) but that > doesn't make your CPU microcode & electricity provider an integral > part of the program, does it? No. Those are independent works. They are not distributed to make a certain piece of software function in a particular way or place. The presence of software in a box with CPU microcode is -- at least in every case I have seen -- what GPL calls "mere aggregation". > Luckily, it doesn't really matter what you or I think that > "integral-ness" means, all it matters is how copyright law defines a > "derivative work" and whether a cryptographic hash is such a > thing. Now are you seriously arguing that a hash is a derivative work? No. I explained this before. Try reading the thread and the GPL. I am not sure where people get the (wrong) idea that the GPL only concerns itself with "derivative work[s]". >> On top of this, in the Tivo >> case the two are distributed together, and even part of the same file. >> > > It's mere aggregation, but it's totally irrelevant because they could > just as easily change their approach. If and when they do, I'll consider the rules that might apply. Until then, it is fairly stupid to try to defend Tivo by saying they *might* do something they currently don't, and if they did, they *might* have a defense that they currently don't. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Florin Malita writes: > On 06/15/2007 10:56 AM, Michael Poole wrote: >> The GPL cares about the key >> used to generate an integral part of the executable form of the GPLed >> work. > > GLPv2 doesn't: why do you think the digital signature is an integral > part of the executable? It can be a totally separate blob, distributed > via a separate channel and even stored at a different location than > the executable. Does it still look like an integral part of the > executable to you then? Yes. If I cut a book in half and store the halves separately, does the second half become an independent work? The integral-ness is a function of how the thing is created and how it functions, not how it is stored. If you need part B for part A to execute as intended, then part A is not a complete work in itself. On top of this, in the Tivo case the two are distributed together, and even part of the same file. [snip] > Do you honestly believe GPLv2 requires the distributor to provide you > with the right environment for your modified copy to "function > properly"? I would say it doesn't, but feel free to point me to > specific sections which *state* otherwise. AFAICT, GPLv2 is > specifically limited to "copying, distribution and modification". How > you use (or don't use, or can't use) your modified copy is totally > outside its scope. The GPL does not require a distributor to provide me with any kind of environment. If I get a Tivo kernel image but do not have a Tivo, the GPL does not require anyone to give me hardware. Fortunately, that is not at all my argument. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: > * Michael Poole <[EMAIL PROTECTED]> wrote: > >> > I.e. you cannot just cleverly define "source code" to include >> > something unrelated and then pretend that it's all in one work. And >> > that's exactly what the GPLv3 does: it creatively defines the >> > hardware's key into the 'source code' of the software and then asks >> > for that to be provided _not_ because somehow the key derives from >> > the software (it clearly does not), but as a "compensation" for the >> > right to redistribute! I.e. it's trying to extend its scope to some >> > item that is not part of the software. See? >> >> No. The GPL does not care about the hardware's key, as I pointed out >> in the part of my email that you cut out. The GPL cares about the key >> used to generate an integral part of the executable form of the GPLed >> work. The executable does not function properly if it lacks that >> part. [...] > > it is a false statement on your part that the executable "does not > function properly" if it lacks that part. Try it: take out the harddisk > from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux > PC, mount it, modify a bit in the kernel image header and it will likely > still boot just fine on that PC. Tivo did not program or sell the hard drive to be used in an arbitrary Linux PC. They sold the hard drive to be used in their hardware, with a Linux kernel specifically modified for that. Without the right digital signature, it does not do the same thing: it is *incomplete*. That is eminently a software issue. Hardware limitations -- whether they be RAM size or requirement for a certain digital signature -- are beside the point. The requirement that I "modify a bit in the kernel image header" is also one of the most pathetic cop-outs I have seen. What makes that binary format the preferred form for modification of Linux? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: > * Michael Poole <[EMAIL PROTECTED]> wrote: > >> >> I do not suggest that copyright subsists in the signature or in the >> >> signing key. Whether it does is irrelevant to the signing key >> >> being part of the source code (when the signature is needed for the >> >> binary to work properly). >> > >> > it is very much relevant. By admitting that the key is not part of >> > the "work", you have lost all moral basis to claim control over it. >> >> I have not admitted any such thing. I have said the key and signature >> do not have separate copyright protection. Variables named "i" in a >> file are not protected by copyright, but they are very much part of >> the source code in that file. > > the problem with your argument is that the definition of what > constitutes "work" is up to copyright law, _not_ the license writer. Linux is unquestionably a work protected under copyright law. When I compile Linux, copyright law still protects the executable form. This is not a problem. > I.e. you cannot just cleverly define "source code" to include something > unrelated and then pretend that it's all in one work. And that's exactly > what the GPLv3 does: it creatively defines the hardware's key into the > 'source code' of the software and then asks for that to be provided > _not_ because somehow the key derives from the software (it clearly does > not), but as a "compensation" for the right to redistribute! I.e. it's > trying to extend its scope to some item that is not part of the > software. See? No. The GPL does not care about the hardware's key, as I pointed out in the part of my email that you cut out. The GPL cares about the key used to generate an integral part of the executable form of the GPLed work. The executable does not function properly if it lacks that part. This is exactly the same way in which the GPL cares about the programming instructions in other parts of the source code: if you remove them, the resulting work does something quite different. See? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: > * Michael Poole <[EMAIL PROTECTED]> wrote: > >> > However, since the signing is an automated process it cannot >> > generate a "new" work - at least, not under the laws of the US - so >> > the signature itself cannot have a copyright at all. > [...] >> >> I do not suggest that copyright subsists in the signature or in the >> signing key. Whether it does is irrelevant to the signing key being >> part of the source code (when the signature is needed for the binary >> to work properly). > > it is very much relevant. By admitting that the key is not part of the > "work", you have lost all moral basis to claim control over it. I have not admitted any such thing. I have said the key and signature do not have separate copyright protection. Variables named "i" in a file are not protected by copyright, but they are very much part of the source code in that file. >> Similarly, copyright might not subsist in a simple linker script -- >> its content being determined by the operating system and perhaps the >> rest of the program's source code -- but under the GPL, the linker >> script would be part of the source code for a compiled version. > > the linker script is still part of the whole work though - even if that > particular element might not be copyrightable in isolation. Likewise, > the kernel contains code that is in the public domain - to which > copyright protection does not extend either. But you cannot argue that > the Tivo 'key' is part of the whole work. It is part of the _hardware_. > The Tivo box is a compilation (at most a collection) of multiple works, > and allowing the GPL to jump over derivation/modification lines is > wrong. The GPLv2 certain doesnt do that land-grab. Where in the Tivo hardware is the signing key? There is a related key in the hardware, but that one is not used to generate an integral part of the kernel binary. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > On Friday 15 June 2007 05:30:09 Bernd Paysan wrote: >> On Friday 15 June 2007 01:46, [EMAIL PROTECTED] wrote: >> > if you cannot modify the software that runs on your Tivo hardware you >> > haven't tried very hard. >> >> Yes, but the GPLv2 clearly says that you don't have to try very hard. The >> preferred form of modification has to be distributed. I can run a >> decompiler or disassembler on a program, and I can even modify it in place >> with a hex editor (I have even modified programs in embedded ROMs by using >> focussed ion beam, so I know you can modify every program if you try hard >> enough). It's certainly possible to crack Tivo's firmware to accept my own >> signature, but it's *not* the preferred form of modification, the source >> code and Tivo's key for the signature. > > How is a signing key part of the "preferred form for modification"? It isn't > a > requirement to *modify* anything, just to *replace* something. (And I am > *NOT* going to explain why "replace != modify" again) The signing key determines a critical portion of the binary form that was distributed. You cannot produce that portion of the binary form without the signing key. Without that portion, the binary form does not perform the function for which it is distributed. If you think such an input is not part of "the preferred form for modification", I have a bridge to sell you. The work that the GPL protects a recipient's right to modify and redistribute is not the source code -- it is each form the user receives. >> Since Tivo's firmware only accepts a signed kernel, the combination of >> kernel+signature is the binary they ship. The kernel itself is useless, the >> signature as well. Therefore, you can imply that Tivo's key is part of >> the "other stuff" the GPLv2 mentions, because you need it to recreate the >> same code as Tivo did and shipped (compilers insert timestamps and such), >> and to modify that code. The source code is just a mean, the thing they >> shipped is the end (the binary), and they have to comply with the GPL for >> that binary - which by all means of practical understanding includes the >> signature. > > I can find no such requirement in the GPLv2. In fact, it actually says that > you don't even have to be able to *USE* the program. See section 12 of the > GPL if you don't believe me. Section 12 of the GPL(v2) is a warranty and liability disclaimer. It is not an absolution of license obligations. It limits the liability of a distributor to the end user, not to copyright owners. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > Following your logic it would be a "failure to distribute the source code for > a work". > > However, since the signing is an automated process it cannot generate a "new" > work - at least, not under the laws of the US - so the signature itself > cannot have a copyright at all. > > DRH > PS: This is the exact same reason that the GPL cannot apply to a Bison > generated parser in the US. The "input" file that causes Bison to generate > the output can have a copyright, but not the output - no matter what RMS or > anyone else wants, and no matter what the GPL says about it. I do not suggest that copyright subsists in the signature or in the signing key. Whether it does is irrelevant to the signing key being part of the source code (when the signature is needed for the binary to work properly). Similarly, copyright might not subsist in a simple linker script -- its content being determined by the operating system and perhaps the rest of the program's source code -- but under the GPL, the linker script would be part of the source code for a compiled version. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: Following your logic it would be a failure to distribute the source code for a work. However, since the signing is an automated process it cannot generate a new work - at least, not under the laws of the US - so the signature itself cannot have a copyright at all. DRH PS: This is the exact same reason that the GPL cannot apply to a Bison generated parser in the US. The input file that causes Bison to generate the output can have a copyright, but not the output - no matter what RMS or anyone else wants, and no matter what the GPL says about it. I do not suggest that copyright subsists in the signature or in the signing key. Whether it does is irrelevant to the signing key being part of the source code (when the signature is needed for the binary to work properly). Similarly, copyright might not subsist in a simple linker script -- its content being determined by the operating system and perhaps the rest of the program's source code -- but under the GPL, the linker script would be part of the source code for a compiled version. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: On Friday 15 June 2007 05:30:09 Bernd Paysan wrote: On Friday 15 June 2007 01:46, [EMAIL PROTECTED] wrote: if you cannot modify the software that runs on your Tivo hardware you haven't tried very hard. Yes, but the GPLv2 clearly says that you don't have to try very hard. The preferred form of modification has to be distributed. I can run a decompiler or disassembler on a program, and I can even modify it in place with a hex editor (I have even modified programs in embedded ROMs by using focussed ion beam, so I know you can modify every program if you try hard enough). It's certainly possible to crack Tivo's firmware to accept my own signature, but it's *not* the preferred form of modification, the source code and Tivo's key for the signature. How is a signing key part of the preferred form for modification? It isn't a requirement to *modify* anything, just to *replace* something. (And I am *NOT* going to explain why replace != modify again) The signing key determines a critical portion of the binary form that was distributed. You cannot produce that portion of the binary form without the signing key. Without that portion, the binary form does not perform the function for which it is distributed. If you think such an input is not part of the preferred form for modification, I have a bridge to sell you. The work that the GPL protects a recipient's right to modify and redistribute is not the source code -- it is each form the user receives. Since Tivo's firmware only accepts a signed kernel, the combination of kernel+signature is the binary they ship. The kernel itself is useless, the signature as well. Therefore, you can imply that Tivo's key is part of the other stuff the GPLv2 mentions, because you need it to recreate the same code as Tivo did and shipped (compilers insert timestamps and such), and to modify that code. The source code is just a mean, the thing they shipped is the end (the binary), and they have to comply with the GPL for that binary - which by all means of practical understanding includes the signature. I can find no such requirement in the GPLv2. In fact, it actually says that you don't even have to be able to *USE* the program. See section 12 of the GPL if you don't believe me. Section 12 of the GPL(v2) is a warranty and liability disclaimer. It is not an absolution of license obligations. It limits the liability of a distributor to the end user, not to copyright owners. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: * Michael Poole [EMAIL PROTECTED] wrote: However, since the signing is an automated process it cannot generate a new work - at least, not under the laws of the US - so the signature itself cannot have a copyright at all. [...] I do not suggest that copyright subsists in the signature or in the signing key. Whether it does is irrelevant to the signing key being part of the source code (when the signature is needed for the binary to work properly). it is very much relevant. By admitting that the key is not part of the work, you have lost all moral basis to claim control over it. I have not admitted any such thing. I have said the key and signature do not have separate copyright protection. Variables named i in a file are not protected by copyright, but they are very much part of the source code in that file. Similarly, copyright might not subsist in a simple linker script -- its content being determined by the operating system and perhaps the rest of the program's source code -- but under the GPL, the linker script would be part of the source code for a compiled version. the linker script is still part of the whole work though - even if that particular element might not be copyrightable in isolation. Likewise, the kernel contains code that is in the public domain - to which copyright protection does not extend either. But you cannot argue that the Tivo 'key' is part of the whole work. It is part of the _hardware_. The Tivo box is a compilation (at most a collection) of multiple works, and allowing the GPL to jump over derivation/modification lines is wrong. The GPLv2 certain doesnt do that land-grab. Where in the Tivo hardware is the signing key? There is a related key in the hardware, but that one is not used to generate an integral part of the kernel binary. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: * Michael Poole [EMAIL PROTECTED] wrote: I do not suggest that copyright subsists in the signature or in the signing key. Whether it does is irrelevant to the signing key being part of the source code (when the signature is needed for the binary to work properly). it is very much relevant. By admitting that the key is not part of the work, you have lost all moral basis to claim control over it. I have not admitted any such thing. I have said the key and signature do not have separate copyright protection. Variables named i in a file are not protected by copyright, but they are very much part of the source code in that file. the problem with your argument is that the definition of what constitutes work is up to copyright law, _not_ the license writer. Linux is unquestionably a work protected under copyright law. When I compile Linux, copyright law still protects the executable form. This is not a problem. I.e. you cannot just cleverly define source code to include something unrelated and then pretend that it's all in one work. And that's exactly what the GPLv3 does: it creatively defines the hardware's key into the 'source code' of the software and then asks for that to be provided _not_ because somehow the key derives from the software (it clearly does not), but as a compensation for the right to redistribute! I.e. it's trying to extend its scope to some item that is not part of the software. See? No. The GPL does not care about the hardware's key, as I pointed out in the part of my email that you cut out. The GPL cares about the key used to generate an integral part of the executable form of the GPLed work. The executable does not function properly if it lacks that part. This is exactly the same way in which the GPL cares about the programming instructions in other parts of the source code: if you remove them, the resulting work does something quite different. See? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: * Michael Poole [EMAIL PROTECTED] wrote: I.e. you cannot just cleverly define source code to include something unrelated and then pretend that it's all in one work. And that's exactly what the GPLv3 does: it creatively defines the hardware's key into the 'source code' of the software and then asks for that to be provided _not_ because somehow the key derives from the software (it clearly does not), but as a compensation for the right to redistribute! I.e. it's trying to extend its scope to some item that is not part of the software. See? No. The GPL does not care about the hardware's key, as I pointed out in the part of my email that you cut out. The GPL cares about the key used to generate an integral part of the executable form of the GPLed work. The executable does not function properly if it lacks that part. [...] it is a false statement on your part that the executable does not function properly if it lacks that part. Try it: take out the harddisk from the Tivo (it's a bog standard IDE harddisk), put into a nice Linux PC, mount it, modify a bit in the kernel image header and it will likely still boot just fine on that PC. Tivo did not program or sell the hard drive to be used in an arbitrary Linux PC. They sold the hard drive to be used in their hardware, with a Linux kernel specifically modified for that. Without the right digital signature, it does not do the same thing: it is *incomplete*. That is eminently a software issue. Hardware limitations -- whether they be RAM size or requirement for a certain digital signature -- are beside the point. The requirement that I modify a bit in the kernel image header is also one of the most pathetic cop-outs I have seen. What makes that binary format the preferred form for modification of Linux? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Florin Malita writes: On 06/15/2007 10:56 AM, Michael Poole wrote: The GPL cares about the key used to generate an integral part of the executable form of the GPLed work. GLPv2 doesn't: why do you think the digital signature is an integral part of the executable? It can be a totally separate blob, distributed via a separate channel and even stored at a different location than the executable. Does it still look like an integral part of the executable to you then? Yes. If I cut a book in half and store the halves separately, does the second half become an independent work? The integral-ness is a function of how the thing is created and how it functions, not how it is stored. If you need part B for part A to execute as intended, then part A is not a complete work in itself. On top of this, in the Tivo case the two are distributed together, and even part of the same file. [snip] Do you honestly believe GPLv2 requires the distributor to provide you with the right environment for your modified copy to function properly? I would say it doesn't, but feel free to point me to specific sections which *state* otherwise. AFAICT, GPLv2 is specifically limited to copying, distribution and modification. How you use (or don't use, or can't use) your modified copy is totally outside its scope. The GPL does not require a distributor to provide me with any kind of environment. If I get a Tivo kernel image but do not have a Tivo, the GPL does not require anyone to give me hardware. Fortunately, that is not at all my argument. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Florin Malita writes: On 06/15/2007 12:18 PM, Michael Poole wrote: Florin Malita writes: On 06/15/2007 10:56 AM, Michael Poole wrote: The GPL cares about the key used to generate an integral part of the executable form of the GPLed work. GLPv2 doesn't: why do you think the digital signature is an integral part of the executable? It can be a totally separate blob, distributed via a separate channel and even stored at a different location than the executable. Does it still look like an integral part of the executable to you then? Yes. If I cut a book in half and store the halves separately, does the second half become an independent work? Except in this case you're not touching the book at all. If you write a review for a book (much better analogy methinks), then your review is obviously not an integral part of the book even though it's based on its content. Extremely poor analogy. I do not distribute my review with the book. Someone buying the book is able to use the book just fine (for the purpose for which it was sold) without my review. They need neither my review nor other modifications before the book becomes readable. As Ingo said, you need either the digital signature or other changes before a Tivo kernel image will load. The integral-ness is a function of how the thing is created and how it functions, not how it is stored. If you need part B for part A to execute as intended, then part A is not a complete work in itself. Being an integral part (as in combined or derived work) has nothing to do with usability. There are many other bits and pieces your executable needs in order to function properly (or at all) but that doesn't make your CPU microcode electricity provider an integral part of the program, does it? No. Those are independent works. They are not distributed to make a certain piece of software function in a particular way or place. The presence of software in a box with CPU microcode is -- at least in every case I have seen -- what GPL calls mere aggregation. Luckily, it doesn't really matter what you or I think that integral-ness means, all it matters is how copyright law defines a derivative work and whether a cryptographic hash is such a thing. Now are you seriously arguing that a hash is a derivative work? No. I explained this before. Try reading the thread and the GPL. I am not sure where people get the (wrong) idea that the GPL only concerns itself with derivative work[s]. On top of this, in the Tivo case the two are distributed together, and even part of the same file. It's mere aggregation, but it's totally irrelevant because they could just as easily change their approach. If and when they do, I'll consider the rules that might apply. Until then, it is fairly stupid to try to defend Tivo by saying they *might* do something they currently don't, and if they did, they *might* have a defense that they currently don't. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: > On Fri, 15 Jun 2007, Alexandre Oliva wrote: > >> Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 >> >> On Jun 14, 2007, Bill Nottingham <[EMAIL PROTECTED]> wrote: >> >>> OK. Let's take this to the simple and logical conclusion. A signed >>> filesystem image containing both GPL and non-GPL code. From your >>> point A, this is a derived work. >> >> I claim the signature is derived from the GPLed bits, yes. Whether >> that's a derived work, in the legal sense, I'm not qualified to say. > > it's also derived from the non-GPLed bits as well. > > so if it were a derived work in a legal sense (nessasary for your > argument to have any legal meaning) then it's now illegal to make and > distribute a checksum of a CD that contains software with incompatible > licenses. It is not necessary for the end item to be a derived work in order for the GPL to apply. A literal copy is not a derived work; a translation is not a derived work; an executable version of a program is not a derived work of its source code; and so forth. What is necessary is that the "work based on the [GPLed] Program" be more than a mere aggregation of the GPLed component(s) with non-GPLed components. The fact that part of the work-as-a-whole is a descriptor of the GPLed part does not mean all descriptions the GPLed part are governed by the GPL. The critical factor is that the GPLed part will not function properly without the DRM signature. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Linus Torvalds writes: > On Thu, 14 Jun 2007, Michael Poole wrote: >> >> If the DRM signature and program executable are coupled such that they >> are not useful when separated, the implication to me is that they form >> one work that is based on the original Program. This is beyond the >> GPL's permission for "mere aggregation". > > So you want to make things like a 160-bit SHA1 hash of a binary be a > "derived work" of that software? No. That is why I specified "not useful when separated". I also intentionally avoided the phrase "derived work": the legal definition of derived work is based on entirely different factors. If the signature is one that serves to indicate origin, to detect tampering, or the other things you mentioned, the program's binary is useful when separated from the signature. My objection arises when a functionally equivalent binary -- including advertised functions such as "runs on platform XYZ" -- cannot be produced from the distributed source code. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > On Thursday 14 June 2007 22:13:13 Michael Poole wrote: > >> The fundamental reason for this is that neither the executable code >> nor the digital signature serves the desired function alone. The user >> received a copy of the executable for a particular purpose: to run the >> program on a particular platform. With DRM signatures, only the >> combination of program and signature will perform that function, and >> separating the two based on strictly read legal definitions is risky. > > I agree. > >> The question of whether DRM signatures are covered by the license must >> be resolved before one can determine whether Tivo gave "*EXACTLY*" the >> same rights to object-code recipients as Tivo received. GPLv2 is >> worded such that the answer to this does not depend on whether one is >> in file A and the other in file B, or whether one is on hard drive C >> and the other is in flash device D, as long as they are delivered as >> part of one unit; it *might* matter if, say, one is received on >> physical media and the other is downloaded on demand. > > I have read the GPLv2 at least three times since it was pointed out that I > had > forgotten part of it. At no point can I find a point where Tivo broke the > GPLv2 requirement that they give the recipients of the object code the same > rights they received when they acquired a copy of the object or source code. I am trying to reconcile your responses to those two paragraphs. If the DRM signature and program executable are coupled such that they are not useful when separated, the implication to me is that they form one work that is based on the original Program. This is beyond the GPL's permission for "mere aggregation". If they are one work, and the original Program was licensed under the GPLv2, the combined work must also be licensed under the terms of the GPLv2. The input files required to generate a DRM-valid digital signature are part the preferred form for modifying that work. If those bits are not distributed along with the rest of the GPL'ed work, the distributor is either not giving the same rights to the end user, not distributing the source code for the work, or both. Which is it? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: > What rights did they give to "downstream" recipients of the "object code" > version? *EXACTLY* those they received from the GPLv2. Doing the e-mail equivalent of yelling about this will not change the fact that people who think Tivo did something wrong -- legally and/or morally -- consider DRM locks on a piece of software to be part of the "work based on the Program" that is governed by the GPL. The fundamental reason for this is that neither the executable code nor the digital signature serves the desired function alone. The user received a copy of the executable for a particular purpose: to run the program on a particular platform. With DRM signatures, only the combination of program and signature will perform that function, and separating the two based on strictly read legal definitions is risky. The question of whether DRM signatures are covered by the license must be resolved before one can determine whether Tivo gave "*EXACTLY*" the same rights to object-code recipients as Tivo received. GPLv2 is worded such that the answer to this does not depend on whether one is in file A and the other in file B, or whether one is on hard drive C and the other is in flash device D, as long as they are delivered as part of one unit; it *might* matter if, say, one is received on physical media and the other is downloaded on demand. (Linus likes to say that FSF counsel thinks that Tivo did not violate GPLv2. I suspect the actual situation is that FSF counsel believes that there is no case law on point, and that it could go either way, making it improper to publicly claim that Tivo violated any copyright. Until a court rules on a close-enough case, the question of whether GPLv2 covers DRM signatures remains open. In the mean time, it makes more sense for the FSF to issue a new license that squarely addresses this -- such as the GPLv3 -- and persuade as many developers as possible that using it is the best way to protect free software.) Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Matt Keenan writes: > Michael Poole wrote: >> Matt Keenan writes: >> >> >>> Alexandre Oliva wrote: >>> >>>> Err, no. Software, per legal definitions in Brazil, US and elsewhere, >>>> require some physical support. That's the hard disk in the TiVO DVR, >>>> in this case. I don't see how this matters, though. >>>> >>>> >>>> >>> I'm now intrigued, where are these (Brazilian and US) definitions >>> stipulated, and under what authority? >>> >> >> In the US, 17 USC 101 (the "Definitions" section of the title dealing >> with Copyright) makes this definition: >> >> A "computer program" is a set of statements or instructions to be >> used directly or indirectly in a computer in order to bring about >> a certain result. >> >> As its purpose is to outline the scope of copyright law, this >> definition is made under the authority granted to Congress by Article >> I, Section 8 of the United States Constitution. >> >> > But where is the part that says it "requires some physical support"? It > says what it is; "a set of statements or instructions", how it should be > used; "to be used directly or indirectly in a computer", and what > purpose it serves; "in order to bring about a certain result", but it > doesn't seem to indicate that it "requires physical support" aka needing > some physical representation. I suspect this argument boils down to the > philosophical debate of whether ideas (in this case software) can be > truely devoid of the physical. Sets of statements or instructions that cannot "be used directly or indirectly in a computer in order to bring about a certain result" are, for the purposes of copyright law, not software. "A computer" is a physical device. It always has been a physical device, except when "computer" referred to a person who performed computations -- and that meaning fell out of common use 40 years ago. Any suggestion that the requirement to be usable on a physical device is significantly different from "require[s] some physical support" is laughably stupid. 17 USC 102 requires that copyright protection only subsists in works that are "fixed in any tangible medium of expression" -- which obviously includes paper and hard drives, and has been ruled to include volatile program memory (the 9th Circuit's holding to this effect in MAI Systems Corp. v. Peak Computer, Inc. is what inspired the addition of 17 USC 117(c)). If the set of instructions exist only in transmission or in someone's head, they are not protected by copyright law. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: > this is largely irrelevant to my argument: the FSF is clearly trying to > extend the scope of the GPL to restrict the distribution of certain > hardware+software combinations. The FSF is not really arguing that the > boundary between software and hardware is diffuse. (which btw. it > clearly is) The FSF simply wants to be able to say via the GPLv3: "to be > able to distribute GPL-ed software, the hardware is required to do this > and this". Most people arguing for the expansive interpretation do not really care what hardware is combined with what software. They care about the ability for the user (in the GPLv2's terms, someone who receives GPL'ed software) to have comparable ability to modify and (re-)distribute the software as the software distributor does. The issue of GPLed software on DRMed hardware applies equally to digital video recorders, where the hardware and software distributor are usually the same, and video game consoles, where they are not. There is no good reason to treat a "GPL-incompatible" hardware platform (for example, incompatible due to restrictions on the keys to generate digital signatures) differently than a "GPL-incompatible" patent area. If a software distributor cannot simultaneously comply with the GPL and his other obligations, he should either not distribute the software or be prepared to face the liability from breaching his obligations. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Matt Keenan writes: > Alexandre Oliva wrote: >> >> Err, no. Software, per legal definitions in Brazil, US and elsewhere, >> require some physical support. That's the hard disk in the TiVO DVR, >> in this case. I don't see how this matters, though. >> >> > I'm now intrigued, where are these (Brazilian and US) definitions > stipulated, and under what authority? In the US, 17 USC 101 (the "Definitions" section of the title dealing with Copyright) makes this definition: A "computer program" is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. As its purpose is to outline the scope of copyright law, this definition is made under the authority granted to Congress by Article I, Section 8 of the United States Constitution. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Matt Keenan writes: Alexandre Oliva wrote: Err, no. Software, per legal definitions in Brazil, US and elsewhere, require some physical support. That's the hard disk in the TiVO DVR, in this case. I don't see how this matters, though. I'm now intrigued, where are these (Brazilian and US) definitions stipulated, and under what authority? In the US, 17 USC 101 (the Definitions section of the title dealing with Copyright) makes this definition: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. As its purpose is to outline the scope of copyright law, this definition is made under the authority granted to Congress by Article I, Section 8 of the United States Constitution. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Ingo Molnar writes: this is largely irrelevant to my argument: the FSF is clearly trying to extend the scope of the GPL to restrict the distribution of certain hardware+software combinations. The FSF is not really arguing that the boundary between software and hardware is diffuse. (which btw. it clearly is) The FSF simply wants to be able to say via the GPLv3: to be able to distribute GPL-ed software, the hardware is required to do this and this. Most people arguing for the expansive interpretation do not really care what hardware is combined with what software. They care about the ability for the user (in the GPLv2's terms, someone who receives GPL'ed software) to have comparable ability to modify and (re-)distribute the software as the software distributor does. The issue of GPLed software on DRMed hardware applies equally to digital video recorders, where the hardware and software distributor are usually the same, and video game consoles, where they are not. There is no good reason to treat a GPL-incompatible hardware platform (for example, incompatible due to restrictions on the keys to generate digital signatures) differently than a GPL-incompatible patent area. If a software distributor cannot simultaneously comply with the GPL and his other obligations, he should either not distribute the software or be prepared to face the liability from breaching his obligations. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Matt Keenan writes: Michael Poole wrote: Matt Keenan writes: Alexandre Oliva wrote: Err, no. Software, per legal definitions in Brazil, US and elsewhere, require some physical support. That's the hard disk in the TiVO DVR, in this case. I don't see how this matters, though. I'm now intrigued, where are these (Brazilian and US) definitions stipulated, and under what authority? In the US, 17 USC 101 (the Definitions section of the title dealing with Copyright) makes this definition: A computer program is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result. As its purpose is to outline the scope of copyright law, this definition is made under the authority granted to Congress by Article I, Section 8 of the United States Constitution. But where is the part that says it requires some physical support? It says what it is; a set of statements or instructions, how it should be used; to be used directly or indirectly in a computer, and what purpose it serves; in order to bring about a certain result, but it doesn't seem to indicate that it requires physical support aka needing some physical representation. I suspect this argument boils down to the philosophical debate of whether ideas (in this case software) can be truely devoid of the physical. Sets of statements or instructions that cannot be used directly or indirectly in a computer in order to bring about a certain result are, for the purposes of copyright law, not software. A computer is a physical device. It always has been a physical device, except when computer referred to a person who performed computations -- and that meaning fell out of common use 40 years ago. Any suggestion that the requirement to be usable on a physical device is significantly different from require[s] some physical support is laughably stupid. 17 USC 102 requires that copyright protection only subsists in works that are fixed in any tangible medium of expression -- which obviously includes paper and hard drives, and has been ruled to include volatile program memory (the 9th Circuit's holding to this effect in MAI Systems Corp. v. Peak Computer, Inc. is what inspired the addition of 17 USC 117(c)). If the set of instructions exist only in transmission or in someone's head, they are not protected by copyright law. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: What rights did they give to downstream recipients of the object code version? *EXACTLY* those they received from the GPLv2. Doing the e-mail equivalent of yelling about this will not change the fact that people who think Tivo did something wrong -- legally and/or morally -- consider DRM locks on a piece of software to be part of the work based on the Program that is governed by the GPL. The fundamental reason for this is that neither the executable code nor the digital signature serves the desired function alone. The user received a copy of the executable for a particular purpose: to run the program on a particular platform. With DRM signatures, only the combination of program and signature will perform that function, and separating the two based on strictly read legal definitions is risky. The question of whether DRM signatures are covered by the license must be resolved before one can determine whether Tivo gave *EXACTLY* the same rights to object-code recipients as Tivo received. GPLv2 is worded such that the answer to this does not depend on whether one is in file A and the other in file B, or whether one is on hard drive C and the other is in flash device D, as long as they are delivered as part of one unit; it *might* matter if, say, one is received on physical media and the other is downloaded on demand. (Linus likes to say that FSF counsel thinks that Tivo did not violate GPLv2. I suspect the actual situation is that FSF counsel believes that there is no case law on point, and that it could go either way, making it improper to publicly claim that Tivo violated any copyright. Until a court rules on a close-enough case, the question of whether GPLv2 covers DRM signatures remains open. In the mean time, it makes more sense for the FSF to issue a new license that squarely addresses this -- such as the GPLv3 -- and persuade as many developers as possible that using it is the best way to protect free software.) Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Daniel Hazelton writes: On Thursday 14 June 2007 22:13:13 Michael Poole wrote: The fundamental reason for this is that neither the executable code nor the digital signature serves the desired function alone. The user received a copy of the executable for a particular purpose: to run the program on a particular platform. With DRM signatures, only the combination of program and signature will perform that function, and separating the two based on strictly read legal definitions is risky. I agree. The question of whether DRM signatures are covered by the license must be resolved before one can determine whether Tivo gave *EXACTLY* the same rights to object-code recipients as Tivo received. GPLv2 is worded such that the answer to this does not depend on whether one is in file A and the other in file B, or whether one is on hard drive C and the other is in flash device D, as long as they are delivered as part of one unit; it *might* matter if, say, one is received on physical media and the other is downloaded on demand. I have read the GPLv2 at least three times since it was pointed out that I had forgotten part of it. At no point can I find a point where Tivo broke the GPLv2 requirement that they give the recipients of the object code the same rights they received when they acquired a copy of the object or source code. I am trying to reconcile your responses to those two paragraphs. If the DRM signature and program executable are coupled such that they are not useful when separated, the implication to me is that they form one work that is based on the original Program. This is beyond the GPL's permission for mere aggregation. If they are one work, and the original Program was licensed under the GPLv2, the combined work must also be licensed under the terms of the GPLv2. The input files required to generate a DRM-valid digital signature are part the preferred form for modifying that work. If those bits are not distributed along with the rest of the GPL'ed work, the distributor is either not giving the same rights to the end user, not distributing the source code for the work, or both. Which is it? Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Linus Torvalds writes: On Thu, 14 Jun 2007, Michael Poole wrote: If the DRM signature and program executable are coupled such that they are not useful when separated, the implication to me is that they form one work that is based on the original Program. This is beyond the GPL's permission for mere aggregation. So you want to make things like a 160-bit SHA1 hash of a binary be a derived work of that software? No. That is why I specified not useful when separated. I also intentionally avoided the phrase derived work: the legal definition of derived work is based on entirely different factors. If the signature is one that serves to indicate origin, to detect tampering, or the other things you mentioned, the program's binary is useful when separated from the signature. My objection arises when a functionally equivalent binary -- including advertised functions such as runs on platform XYZ -- cannot be produced from the distributed source code. Michael Poole - 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
[EMAIL PROTECTED] writes: On Fri, 15 Jun 2007, Alexandre Oliva wrote: Subject: Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 On Jun 14, 2007, Bill Nottingham [EMAIL PROTECTED] wrote: OK. Let's take this to the simple and logical conclusion. A signed filesystem image containing both GPL and non-GPL code. From your point A, this is a derived work. I claim the signature is derived from the GPLed bits, yes. Whether that's a derived work, in the legal sense, I'm not qualified to say. it's also derived from the non-GPLed bits as well. so if it were a derived work in a legal sense (nessasary for your argument to have any legal meaning) then it's now illegal to make and distribute a checksum of a CD that contains software with incompatible licenses. It is not necessary for the end item to be a derived work in order for the GPL to apply. A literal copy is not a derived work; a translation is not a derived work; an executable version of a program is not a derived work of its source code; and so forth. What is necessary is that the work based on the [GPLed] Program be more than a mere aggregation of the GPLed component(s) with non-GPLed components. The fact that part of the work-as-a-whole is a descriptor of the GPLed part does not mean all descriptions the GPLed part are governed by the GPL. The critical factor is that the GPLed part will not function properly without the DRM signature. Michael Poole - 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: GPL violation by CorAccess?
Steven Rostedt writes: > On Wed, 2005-04-20 at 14:57 +0200, Arjan van de Ven wrote: >> On Wed, 2005-04-20 at 08:49 -0400, Steven Rostedt wrote: >> > On Wed, 2005-04-20 at 09:30 +0200, Bernd Petrovitsch wrote: >> > >> > > >> > > As long as they do not statically link against LGPL (or GPL) code and as >> > > long as they do not link dynamically agaist GPL code. And there are >> > > probably more rules . >> > > >> > >> > Actually, I believe that the LGPL allows for static linking as well. >> >> it does, as long as you provide the .o files of your own stuff so that >> the end user can relink with say a bugfixed version of library. > > I don't see that in the license. As point 5 showed: "Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License." "Such a work" refers to "A program that contains no derivative of any portion of the library." A program that is statically linked against the library clearly contains part or all of the library, and cannot qualify for the lower threshold of section 5. Section 5 is talking about late binding to the library; dynamic linking is one example. For programs distributed as object code that does contain part of the library, the distributor must -- sooner or later -- comply with 6(a) (allow the user to relink) or 6(b) (use dynamic linking). Michael Poole - 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: GPL violation by CorAccess?
Steven Rostedt writes: On Wed, 2005-04-20 at 14:57 +0200, Arjan van de Ven wrote: On Wed, 2005-04-20 at 08:49 -0400, Steven Rostedt wrote: On Wed, 2005-04-20 at 09:30 +0200, Bernd Petrovitsch wrote: As long as they do not statically link against LGPL (or GPL) code and as long as they do not link dynamically agaist GPL code. And there are probably more rules . Actually, I believe that the LGPL allows for static linking as well. it does, as long as you provide the .o files of your own stuff so that the end user can relink with say a bugfixed version of library. I don't see that in the license. As point 5 showed: Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. Such a work refers to A program that contains no derivative of any portion of the library. A program that is statically linked against the library clearly contains part or all of the library, and cannot qualify for the lower threshold of section 5. Section 5 is talking about late binding to the library; dynamic linking is one example. For programs distributed as object code that does contain part of the library, the distributor must -- sooner or later -- comply with 6(a) (allow the user to relink) or 6(b) (use dynamic linking). Michael Poole - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz writes: >>Copyright law only _explicitly_ grants a monopoly on preparation of >>derivative works. However, it is trivial, and overwhelmingly common, >>for a copyright owner to grant a license to create a derivative work >>that is conditional on how the licensee agrees to distribute (or not >>distribute) the derivative work. > > This would, of course, only make sense if you *had* to agree to the > license > to *create* the derivative work. If you were able to create the derivative > work under first sale or fair use rights, then the restrictions in the > contract would not apply to you. This would, of course, only make sense if fair use or first sale rights *allow* the creation of derivative works. I have seen nothing in this thread or in the statutes to suggest that they do. Do not forget that your copyright interest in a derivative work is limited to the creative elements which you contributed. Simply having a license (or right) to create a derivative work does not permit you to infringe the original work's copyright, which still subsists in the derivative work insofar as the derivative work contains copyrightable elements from the original work. Even if some court agrees with your hypothesis that the compiled program is a derivative work of the source (which I doubt would happen), and you find some permission outside of the GPL to prepare that derivative work, you still need permission to copy it further. Michael Poole - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa writes: > David Schwartz wrote: > >> > On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote: >> >> >> >> The way you stop someone from distributing part of your work is >> >> by arguing that the work they are distributing is a derivative >> >> work of your work and they had no right to *make* it in the first >> >> place. See, for example, Mulcahy v. Cheetah Learning. >> >> >> > Er, that's one way, but not *the* way. I could grant you >> > permission to create derivatives of my work, but not to >> > redistribute them. To stop you from distributing them, I'd argue >> > that you had no right to distribute them--you *did* have the right >> > to make it in the first place. >> >> >> You could do that be means of a contract, but I don't think you could >> it do by means of a copyright license. The problem is that there is >> no right to control the distribution of derivative works for you to >> withhold from me. > Wrong, sorry. Copyright is a *monopoly* on some activities (copy, > distribution of copies, making *and* distribution of derivative works). Copyright law only _explicitly_ grants a monopoly on preparation of derivative works. However, it is trivial, and overwhelmingly common, for a copyright owner to grant a license to create a derivative work that is conditional on how the licensee agrees to distribute (or not distribute) the derivative work. Michael Poole - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa writes: David Schwartz wrote: On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote: The way you stop someone from distributing part of your work is by arguing that the work they are distributing is a derivative work of your work and they had no right to *make* it in the first place. See, for example, Mulcahy v. Cheetah Learning. Er, that's one way, but not *the* way. I could grant you permission to create derivatives of my work, but not to redistribute them. To stop you from distributing them, I'd argue that you had no right to distribute them--you *did* have the right to make it in the first place. You could do that be means of a contract, but I don't think you could it do by means of a copyright license. The problem is that there is no right to control the distribution of derivative works for you to withhold from me. Wrong, sorry. Copyright is a *monopoly* on some activities (copy, distribution of copies, making *and* distribution of derivative works). Copyright law only _explicitly_ grants a monopoly on preparation of derivative works. However, it is trivial, and overwhelmingly common, for a copyright owner to grant a license to create a derivative work that is conditional on how the licensee agrees to distribute (or not distribute) the derivative work. Michael Poole - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz writes: Copyright law only _explicitly_ grants a monopoly on preparation of derivative works. However, it is trivial, and overwhelmingly common, for a copyright owner to grant a license to create a derivative work that is conditional on how the licensee agrees to distribute (or not distribute) the derivative work. This would, of course, only make sense if you *had* to agree to the license to *create* the derivative work. If you were able to create the derivative work under first sale or fair use rights, then the restrictions in the contract would not apply to you. This would, of course, only make sense if fair use or first sale rights *allow* the creation of derivative works. I have seen nothing in this thread or in the statutes to suggest that they do. Do not forget that your copyright interest in a derivative work is limited to the creative elements which you contributed. Simply having a license (or right) to create a derivative work does not permit you to infringe the original work's copyright, which still subsists in the derivative work insofar as the derivative work contains copyrightable elements from the original work. Even if some court agrees with your hypothesis that the compiled program is a derivative work of the source (which I doubt would happen), and you find some permission outside of the GPL to prepare that derivative work, you still need permission to copy it further. Michael Poole - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther writes: > Hello, > > > Current linux kernel source hold undistributable non-free firmware blobs, and > to consider them as mere agregation, a clear licence statement from the > copyright holders of said non-free firmware blobls is needed, read below for > details. > > > Please keep everyone in the CC, as not everyone reads debian-legal or LKML. This question comes up every four or five months. You might have even been the last one to raise this question on one or more of the mailing lists you cc'ed. Please, go check the list archives for the previous (lengthy and multiple) discussions about this topic. Michael Poole - 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther writes: Hello, quick sumary Current linux kernel source hold undistributable non-free firmware blobs, and to consider them as mere agregation, a clear licence statement from the copyright holders of said non-free firmware blobls is needed, read below for details. /quick sumary Please keep everyone in the CC, as not everyone reads debian-legal or LKML. This question comes up every four or five months. You might have even been the last one to raise this question on one or more of the mailing lists you cc'ed. Please, go check the list archives for the previous (lengthy and multiple) discussions about this topic. Michael Poole - 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: eepro100/usb interrupts stop with 2.4.x kernels?
Alan Cox <[EMAIL PROTECTED]> writes: > > What seems to happen is that the kernel stops seeing interrupts on the > > IRQ shared by eth0 (my outside interface) and usb-uhci. I can still > > ssh in on eth1, and when I do, syslog contains things like "eth0: > > Interrupt timed out" and usb-uhci griping about devices that failed to > > accept new endpoints. > > Do you see this if you run a -ac kernel or apply the APIC 440BX patch ? I haven't tried either, but I'm about to reboot into 2.4.4-ac4 to see if it helps. If it still happens, I'll get more of the syslog output and try to figure out what got wedged. -- Michael - 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/
eepro100/usb interrupts stop with 2.4.x kernels?
Since about 2.4.2, I have been seeing intermittent hangs on my system; usually once or twice a week, but once just 10 minutes after rebooting. What seems to happen is that the kernel stops seeing interrupts on the IRQ shared by eth0 (my outside interface) and usb-uhci. I can still ssh in on eth1, and when I do, syslog contains things like "eth0: Interrupt timed out" and usb-uhci griping about devices that failed to accept new endpoints. I'm not sure if for some reason my chipset stopped passing these interrupts on to the kernel, or if the kernel got into some funny state and stopped accepting those interrupts. Any hints on where I should look? >From /proc/interrupts now: CPU0 CPU1 0: 243741 233914IO-APIC-edge timer 1: 4 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 0IO-APIC-edge rtc 10: 0 0 IO-APIC-level EMU10K1 11: 18775 17937 IO-APIC-level usb-uhci, eth0 12: 1221 1236 IO-APIC-level eth1 14: 84039 68162IO-APIC-edge ide0 15: 18 18 IO-APIC-level BusLogic BT-950 NMI: 0 0 LOC: 477548 477547 ERR: 0 -- Michael - 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/
eepro100/usb interrupts stop with 2.4.x kernels?
Since about 2.4.2, I have been seeing intermittent hangs on my system; usually once or twice a week, but once just 10 minutes after rebooting. What seems to happen is that the kernel stops seeing interrupts on the IRQ shared by eth0 (my outside interface) and usb-uhci. I can still ssh in on eth1, and when I do, syslog contains things like eth0: Interrupt timed out and usb-uhci griping about devices that failed to accept new endpoints. I'm not sure if for some reason my chipset stopped passing these interrupts on to the kernel, or if the kernel got into some funny state and stopped accepting those interrupts. Any hints on where I should look? From /proc/interrupts now: CPU0 CPU1 0: 243741 233914IO-APIC-edge timer 1: 4 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8: 0 0IO-APIC-edge rtc 10: 0 0 IO-APIC-level EMU10K1 11: 18775 17937 IO-APIC-level usb-uhci, eth0 12: 1221 1236 IO-APIC-level eth1 14: 84039 68162IO-APIC-edge ide0 15: 18 18 IO-APIC-level BusLogic BT-950 NMI: 0 0 LOC: 477548 477547 ERR: 0 -- Michael - 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: eepro100/usb interrupts stop with 2.4.x kernels?
Alan Cox [EMAIL PROTECTED] writes: What seems to happen is that the kernel stops seeing interrupts on the IRQ shared by eth0 (my outside interface) and usb-uhci. I can still ssh in on eth1, and when I do, syslog contains things like eth0: Interrupt timed out and usb-uhci griping about devices that failed to accept new endpoints. Do you see this if you run a -ac kernel or apply the APIC 440BX patch ? I haven't tried either, but I'm about to reboot into 2.4.4-ac4 to see if it helps. If it still happens, I'll get more of the syslog output and try to figure out what got wedged. -- Michael - 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: NT soon to surpass Linux in specweb99 performance?
Paul Flinders <[EMAIL PROTECTED]> writes: > Gregory Maxwell wrote: > > > Looks like TUX caught MS's attention: > > http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html > > > > Anyone know if their method of achieveing this is as flexible as TUX, or is > > their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the > > specweb dyanmic stuff in x86 assembly in their microkernel? :) > > Yeah, but Tux 2 is still faster on the same/similar hardware > > http://www.spec.org/osg/web99/results/res2000q4/web99-20001127-00075.html Well, if you look closely, the Tux 2 system had an extra GigE card and 5 9GB 10KRPM drives instead of 1 9GB 10KRPM drive plus 8 16GB 15KRPM drives under IIS, so the hardware wasn't exactly the same for both. Perhaps more telling is that in both cases the "Conforming Simultaneous Connections" was the same as the "Requested Connections" -- suggesting that neither TUX 2.0 nor IIS were pushed to the breaking point in the tests. Before gloating about holding the highest performance, compare with Zeus running on a (much beefier) IBM eServer: http://www.spec.org/osg/web99/results/res2001q1/web99-20001225-00092.html (And of course the normal disclaimers apply about how little benchmark results reflect what "average" commercial deployments see.) -- Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NT soon to surpass Linux in specweb99 performance?
Paul Flinders [EMAIL PROTECTED] writes: Gregory Maxwell wrote: Looks like TUX caught MS's attention: http://www.spec.org/osg/web99/results/res2000q4/web99-20001211-00082.html Anyone know if their method of achieveing this is as flexible as TUX, or is their "SWC 3.0" simply mean 'spec web cheat' and involve implimenting the specweb dyanmic stuff in x86 assembly in their microkernel? :) Yeah, but Tux 2 is still faster on the same/similar hardware http://www.spec.org/osg/web99/results/res2000q4/web99-20001127-00075.html Well, if you look closely, the Tux 2 system had an extra GigE card and 5 9GB 10KRPM drives instead of 1 9GB 10KRPM drive plus 8 16GB 15KRPM drives under IIS, so the hardware wasn't exactly the same for both. Perhaps more telling is that in both cases the "Conforming Simultaneous Connections" was the same as the "Requested Connections" -- suggesting that neither TUX 2.0 nor IIS were pushed to the breaking point in the tests. Before gloating about holding the highest performance, compare with Zeus running on a (much beefier) IBM eServer: http://www.spec.org/osg/web99/results/res2001q1/web99-20001225-00092.html (And of course the normal disclaimers apply about how little benchmark results reflect what "average" commercial deployments see.) -- Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Matthias Andree <[EMAIL PROTECTED]> writes: > On Fri, 15 Sep 2000, David S. Miller wrote: > > > Every Linux inetd in the world would instantly stop working. > > Why should it? inetd.c does not touch fd flags. No F_SETFL, no > O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) > semantics? Most of the programs called by inetd don't expect non-blocking I/O on their stdin and stdout, which they would suddenly get if accept()'ed sockets inherited the non-blocking nature of inetd's listening socket. Personally, I think that the common case is that the caller will want the same blocking attribute for an accept()'ed socket as on the listening socket it came from, and inetd is the only app I have seen offered as a counterexample. If it's just one app, it can easily be changed and marked as required for upgrades to kernels that have the same semantics as the BSDs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No Bug: accept discards socket options/O_NONBLOCK
Matthias Andree [EMAIL PROTECTED] writes: On Fri, 15 Sep 2000, David S. Miller wrote: Every Linux inetd in the world would instantly stop working. Why should it? inetd.c does not touch fd flags. No F_SETFL, no O_NONBLOCK, no fcntl. Why should inetd fail with a changed accept(2) semantics? Most of the programs called by inetd don't expect non-blocking I/O on their stdin and stdout, which they would suddenly get if accept()'ed sockets inherited the non-blocking nature of inetd's listening socket. Personally, I think that the common case is that the caller will want the same blocking attribute for an accept()'ed socket as on the listening socket it came from, and inetd is the only app I have seen offered as a counterexample. If it's just one app, it can easily be changed and marked as required for upgrades to kernels that have the same semantics as the BSDs. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
