RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: > > Well that's the problem. While copyright law does permit > > you to restrict > > the right to create derivative works, it doesn't permit you to > > restrict the > > distribution of lawfully created derivative works to licensees of the > > original work. As far as I know, no law has ever granted this right to > > copyright holders and no court has ever recognized this right. And I've > > looked. Courts have specifically recognized the absence of this right. > The GPL is very clear in its implementation: it grants wider permission > to create derivative works than to distribute them, implementing its > "virality" in terms of restrictions on distribution, not creation. It doesn't even need to do this. First sale grants the right to use a work one lawfully possesses. One cannot "use" the Linux kernel source without compiling it. So one doesn't need the GPL to create at least some derivative works. > So, > it seems that you're claiming that the GPL is broken or unenforcable in > some aspects. (If you're not, I'd like to know where I'm confused.) > If that's the case, it's a claim I'm not qualified to debate, but would > be interested in hearing the FSF's response. It has always been the FSF's position that you don't need to agree to the GPL to use the covered work. One cannot use the Linux kernel without compiling it and linking it. One cannot use a library without creating a work that uses the library, including the header files, and compiling/linking to form a result. So you can *create* a broad array of derivative works without invoking the GPL's restrictions (under first sale and how source code is ordinarily used). The argument that you cannot distribute a derived work unless the GPL says you can *because* you must have agreed to the GPL in order to lawfully create the derivative work is pure bunk. I don't know that the FSF relies upon the argument, however, it came up in this thread, which is why I refuted it (at least four times now). ;) DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > The GPL applies to distributing a Linux binary I just made even > > though nobody ever chose to apply the GPL to the binary I just made > > only because the binary I just made is a derivative work of the > > Linux kernel, and the authors of that work chose to apply the GPL to > > it. > How can the binary be a derivative work when it does *not* contain > firmware, but suddenly cease to be a derivative work if one *does* > add firmware into it? Because, the argument would go, the binary with the firmware linked in is not a work, it is two works that are aggregated because there's a license boundary between them. The argument would be that the binary with the firmware is *a* *derivative* *work* of the Linux kernel source. The "a" is a critical part of the argument that cannot be omitted. Showing that the linked binary was two works would be sufficient to significantly weaken the argument that it can't be distributed. You can't argue that only the GPL gives you the right to distribute the result, regardless of what it is, because there are other sources of such rights. These include fair use, first sale, and the fact that the law does not create a special right to restrict the distribution of lawfully-created derivative works (to licensees of the original work). My point is not simply that the question of whether or not linking creates a single work that is a derivative work of all the things linked is important to the question of whether you can distribute GPL'd works linked with non-GPL'd works. And the standard is copyright law, not what the GPL says. (Though that's also important, because then you would have even more rights.) DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sunday 10 April 2005 01:18 pm, David Schwartz wrote: > 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. and then later... > Well that's the problem. While copyright law does permit you to restrict > the right to create derivative works, it doesn't permit you to restrict the > distribution of lawfully created derivative works to licensees of the > original work. As far as I know, no law has ever granted this right to > copyright holders and no court has ever recognized this right. And I've > looked. Courts have specifically recognized the absence of this right. I have no idea what the context of this thread is... its way to long and I just didn't keep up with it from the beginning, so you'll excuse me for not knowing the central issue seeking to be resolved. What I can do is comment on the above statement and try to inject a little legal reality :) First, the GPL is likely a contract, not just a license. While there are great legal debates about what that means and the benefits of the two, I think its unwise to claim parts of the GPL are unenforceable because it relies solely on copyright law. The GPL's warranty provisions are certainly not covered by copyright law... and while there are some good arguments for why that's not necessarily proof that its a contract, it can't just be dismissed. As for claim that copyright has no control over derived works. I can preface my grant that allows you to make a derived work with whatever restriction my little heart desires. If that means you can only make the derived work if I then get the complete rights to that work and you can only distribute to girls named Mary, then the copyright law empowers me to restrict that grant accordingly. If I just give you a blanket right to make a derived work, then things might be a bit more hairy. I could see a persuasive argument, but have no citable cases in front of me, that would treat a derived work similar to a joint work. This e-mail is a joint work, because I combined copyrighted work of mine and of David's. If I go out and sell this e-mail, David cannot stop me... BUT, he can sue me for an accounting and get his rightful share of the profits (Fair Use and implied license issues aside). Again, this is a right of copyright law, not just contract. -Sean -- Sean Kellogg 2nd Year - University of Washington School of Law GPSS Senator - Student Bar Association Editor-at-Large - National ACS Blog [http://www.acsblog.org] So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: > Well that's the problem. While copyright law does permit you to restrict > the right to create derivative works, it doesn't permit you to restrict the > distribution of lawfully created derivative works to licensees of the > original work. As far as I know, no law has ever granted this right to > copyright holders and no court has ever recognized this right. And I've > looked. Courts have specifically recognized the absence of this right. The GPL is very clear in its implementation: it grants wider permission to create derivative works than to distribute them, implementing its "virality" in terms of restrictions on distribution, not creation. So, it seems that you're claiming that the GPL is broken or unenforcable in some aspects. (If you're not, I'd like to know where I'm confused.) If that's the case, it's a claim I'm not qualified to debate, but would be interested in hearing the FSF's response. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Sven Luther <[EMAIL PROTECTED]> > On Fri, Apr 08, 2005 at 03:10:43AM +0100, Henning Makholm wrote: >> Scripsit Humberto Massa <[EMAIL PROTECTED]> >> > After a *lot* of discussion, it was deliberated on d-l that >> > this is not that tricky at all, and that the "mere >> > aggregation" clause applies to the combination, for various >> > reasons, with a great degree of safety. >> When was this alleged conclusion reached? I remember nothing like >> that. > http://lists.debian.org/debian-legal/2005/03/msg00273.html The point you seem to be arguing there is | My understanding of this is that neither the firmware constitute a | derived work from the flasher, nor the flasher constitute a derived | work of the firmware. which I agree with. But that is not the same thing as the above claim by Humberto that a "mere aggregation" results from _linking_ those two none-derived-from-the-other components. > http://lists.debian.org/debian-legal/2005/03/msg00283.html Here you lose me at | First we have to consider if the mere presense of the actual | firmware non-free code in the linux driver is enough to make it a | derived work or constitute mere aggregation. As far as I can see you are assuming that it is either "a derived work" or "mere aggregation", and cannot be both or neither. You then try to argue that because it is not a derived work, it must me a mere aggregation. I dispute the initial assumption; it appears to be logically possible [1] that it is neither "derived work" or "mere aggregation". [1] And indeed plausible if one assumes a jurisdiction with a sufficiently narrow definition of "derived work". (I wonder what happens in jurisdications whose copyright law is not phrased in terms of "derived" - or that have several native words which are given different explicit meaning by the local law but would all need to be represented as a form of "derive" in English). -- Henning Makholm "Monarki, er ikke noget materielt ... Borger!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Sven Luther <[EMAIL PROTECTED]> > On Fri, Apr 08, 2005 at 04:56:50AM +0100, Henning Makholm wrote: >> Yes I would. Linking forms a tighter coupling than just placing the >> two parts side by side on a filesystem designed for general storage of >> byte streams. There is more to say about the situation than the naked > So, why didn't you say it when i posted my analysis to debian-legal a month > ago and asked for comments ? I have this thing called a day job which sometimes take priority over reading debian-legal postings. Occasionally I have to purge the backlog of unread postings by the "catch-up" command. Also, the subject has been beaten into .. well, if not death then at least very bad health, so often that it would serve no useful purpose to consistently repost old arguments each time the question was raised. > Read my argumentation, comment on it, and be prepared to consider the same > copy of the firmware as a derived work if shipped on a prom on the device > itself. Strawman. I do not consider the firmware _itself_ to be a derived work at all. When it is distributed alone (e.g. on a prom on the device itself), it is completly independent of the copyright state of the driver that works with it. -- Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at følge den vej kun bliver gennemsnitligt ca. 48 år gammel, og at man sætter sin sociale situation ganske overstyr og, så vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed."
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> >> However, then you cannot legally copy it at all, because it contains >> part of the original author's copyrighted work and therefore can only >> legally be copied with the permission of the author. > 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. You don't need to argue that the thing being distributed is a derivative work. It is enough that it _contains_ your copyrighted work. > My point is that the reason the derivative work issue is so > important is because it's the only way (in U.S. law anyway) that the > GPL can apply to anything other than the exact thing the author > chose to apply it to. The taske of the GPL is to _give permission_ when certain conditions hold. Therefore, if the GPL does not apply yet you still need permission from the author (beacuse what you're distributing contains his work), then you do not have that permission and cannot distribute _at all_. I'm not sure whether meant instead that the original _copyright_ only influences things that are derivative works, but that would have even more bizarre consequences. > The GPL applies to distributing a Linux binary I just made even > though nobody ever chose to apply the GPL to the binary I just made > only because the binary I just made is a derivative work of the > Linux kernel, and the authors of that work chose to apply the GPL to > it. How can the binary be a derivative work when it does *not* contain firmware, but suddenly cease to be a derivative work if one *does* add firmware into it? -- Henning Makholm"Vi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag!"
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Humberto Massa <[EMAIL PROTECTED]> > Henning Makholm wrote: > >Yes I would. Linking forms a tighter coupling than just > >placing the two parts side by side on a filesystem designed > >for general storage of byte streams. There is more to say > >about the situation than the naked fact that that they are > >aggreated on the same medium; ergo the sutiation does not > >constitute *only* aggregation, and the "mere aggregation" > >language of the GPL does not apply. > Starting from the beginning: yes, it's true that linking forms > normally a tighter (functional) coupling between some parts > (caller/callee pairs, etc) of the things linked. And therefore it is not "mere aggregation". > >In particular, the end of GPL #2 does not provide a blanket > >exception for all forms of aggregation; it specifically > >speaks about aggregation "on a volume of a storage or > >distribution medium". > And that is exactly what I argue that an ELF executable with > an embedded firmware to be uploaded is, like a zip/tgz archive > that happens to contain, among other stuff, the firmware. Either you are deliberately ignoring reality here, or you are really ignorant about what the function of an ELF executable is, compared to a zip/tgz archive. They are completely different things. > Notice that I once have argued more completely about the > hermeneutics of the GPL, explaining why I think that the "mere > aggregation" clause 2, para 3 of the GPL is applicable to any > anthology works, because of the dispositions on what is a > derivative "work based on the Program" from clause 0. There is no valid path from the explanation about "work based on the program" to whether something is "mere aggregation". The "mere aggregation" exception does not mention "work based on the program" at all, except in mentioning the _components_ of the aggregation. Specifically, there is _no_ implication that "mere aggregation" is supposed to refer generally to "everything that is not a work based on the program". > >It *is*, therefore, relevant, whether the GPL's special > >conditions for works "that in whole or in part contains the > >Program" apply to the linked object files. > Hmmm. I still think that the phrase that the precedes what you > just cited, "either the Program or any derivative work under > copyright law", applies even more strongly. I do not see any argument that this explanation has any relevance here at all. > >No, it wouldn't be obviously unreasonable for a license to > >recognize such a "license boundary". However, as I see it the > >GPL happens not to do this. > I think it does, when in clause 0 it defines << a "work based > on the Program" means either the Program or any derivative > work under copyright law" >>, which is an authoritative > definition, instead of the "that is to say" explanation that > comes after it. It seems that you belive that the GPL gives you an unconditional permission to copy anything as long as you can argue that it is not "a work based on the program". I cannot find any such permission in the GPL. I claim that ther is, in fact, no such permission, and your argument that the binary is not "a work based in the program", can therefore not be used to conclude that you are allowed to copy the binary. > >I think the "derivative work" angle is a red herring. I do > >not think that either of the two parts that are being linked > >together (i.e. the driver and the firmware) are derivates of > >the other. The relevant point is that distribution of the > >linked _result_ is nevertheless subject to the condition in > >GPL #2, which is in general the only source we have for a > >permission to distribute a non-verbatim-source form of the > >driver. > And what would be the consequence on this? The consequence of this is that the only way we can get permission to copy the linked binary is to follow the conditions in GPL #2 and #3. Of course, if you want to be really restrictive you could say that if I modify my copy of the program in a way that does *not*, in your opinion, create a "work based in the Program", then GPL #2 does not give me permission to copy it _at all_, and I am left with no permission to distribute the result. -- Henning Makholm "Det er du nok fandens ene om at mene. For det ligger i Australien!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Creative Commons license summary (version 4)
On Fri, 08 Apr 2005 10:29:58 -0300 Humberto Massa wrote: > my suggestion: > > You may not distribute, publicly display, publicly > perform, or publicly digitally perform the Work with > any technological measures that prevent the recipient > from exercising the rights granted to them by section > 8a and section 3 of this License, unless you also > offer to distribute, publicly display, publicly > perform or publicly digitally perform the Work for the > same recipient without those measures. > > The difference being only the words "offer to". Yes, perhaps it's better to make it explicit. But remember that, e.g., when the GPLv2 says "Accompany it with the complete corresponding machine-readable source code" (clause 3a), it's OK even if you do not force recipients of the binary to receive the source too, as long as they have the opportunity to get both. I think that "you also distribute" may be interpreted in a similar way: it's OK even if you do not force recipients of the DRM-encumbered form to receive the unencumbered form too, as long as they have the opportunity to get both. Anyway, as I said, it's maybe better to make it explicit... P.S.: Please do not reply to me Cc:ing the list, as I would rather not receiving replies twice. Reply to the list only, when you want to keep the discussion public. Thanks. P.P.S: Am I the only one that sees threads broken by Humberto's replies? It seems that his MUA sometimes sets "In-Reply-To:" and "References:" fields to the "Resent-Message-ID:" value of the message he's replying to, rather than to its "Message-ID:" value... Is this right? Is my MUA misbehaving as it seems it builds threads without taking "Resent-Message-ID:" fields into account (i.e.: only looking at "Message-ID:" values)? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpJ0PH567zk9.pgp Description: PGP signature
Re: Creative Commons update and steps forward
On Sun, Apr 03, 2005 at 11:51:56AM -0400, Evan Prodromou wrote: > I got email from Lawrence Lessig this week that their new general > counsel, Mia Garlick, has been reviewing the debian-legal summary and > will have a response for us by 8 April. So, another update: I got email from LL on Friday. He said that the general counsel had produced a response, but that he (Lessig) hadn't managed to read and revise before then. He was going to spend his weekend doing that to get us the doc by Monday, but I told him it'd be OK to get it to use by Tue or Wed. So: we can expect a Creative Commons response by Tu or W next week. ~Evan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> 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. > The GPL does this. Note GPL #2b: "any work that you distribute > or publish". > If you don't distribute or publish the derivative work, the work does not > need to be "licensed ... under the terms of this License." It > very carefully > separates the permissions granted for merely creating a derivative work, > and the permissions granted for distributing those works; if you > distribute > a linked binary in violation of the GPL, you may very well have > had permission > to make it in the first place. Yes, but this would be valid if and only if there was a right to restrict the distribution of derivative works that was recognized under copyright law. I can find no record of the existence of such a right. > (Of course, if whether the work is a derivative is in question, that would > need to be established--you would, indeed, need to argue that the > work they > are distributing is a derivative work--but you wouldn't > necessarily further > argue that they had no right to make it in the first place.) Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:
>> Every book in my book shelf is software?
>
> If you digitalize it, yes.
AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't "software". Although it surely isn't hardware
either.
--
Giuseppe "Oblomov" Bilotta
"E la storia dell'umanità, babbo?"
"Ma niente: prima si fanno delle cazzate,
poi si studia che cazzate si sono fatte"
(Altan)
("And what about the history of the human race, dad?"
"Oh, nothing special: first they make some foolish things,
then you study what foolish things have been made")
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
