Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > That is the point: the result is not a single work. It is a > > collection or compilation of works, just like an anthology. If > > there is any creativity involved, is in choosing and ordering > > the parts. The creation of works that "can be linked together" > > is not protected by copyright: the literary analogy was to > > "create a robot short story". Such a story could go into an > > anthology called (duh) "Robot Short Stories", but its > > licensing is independent of every other robot short story in > > the world -- except those it is a derivative work of. On Thu, Apr 14, 2005 at 10:44:10AM -0700, David Schwartz wrote: > That's fine then, if you want to define derivative work in this > way, then I can configure, compile, and link the Linux kernel without > permission of the copyright holder under first sale (since no derivative > work is created). I can write a program that uses a library, compile > my program, and link it to the library, again without creating a > derivative work. It's quite true that linking does not create a derivative work. However, it might be the case that a derivative work had already been created. Only when you have legally obtained copies of a work are you entitled to retain those copies. Technical details (such as downloading the work in pieces, from different sites, perhaps using bittorrent, or perhaps using ftp, or perhaps using other protocols) don't make any more difference [either positively or negatively] than linking does. > Okay. This gets to the same result that I get to, which is that > you can do all the things you want to do without permission from > the copyright holder under first sale. Since this is not creating a > derivative work, no special permission is needed. Sure. Of course this doesn't apply when you got the copy from someone who wasn't entitled to give it to you. For example, if I'm distributing some program derived from a GPLed program and I have no intention of providing source for the derived form, I'm at fault, and depending on details you might or might not have a license to the derivative I authored. On the other hand, the GPL itself has an explicit exception for this case, the GPLed content is legal for other people to use even if the person distributing it had lost their copyright grant. But if we're talking about linking and derived works, you could easily be using derived code which is not GPLed. The GPL can't offer you any rights to that code, because someone else owns the copyright. -- Raul - 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 wrote:
>>That is the point: the result is not a single work. It is a
>>collection or compilation of works, just like an anthology.
>>If there is any creativity involved, is in choosing and
>>ordering the parts. The creation of works that "can be
>>linked together" is not protected by copyright: the literary
>>analogy was to "create a robot short story". Such a story
>>could go into an anthology called (duh) "Robot Short
>>Stories", but its licensing is independent of every other
>>robot short story in the world -- except those it is a
>>derivative work of.
>
>
>That's fine then, if you want to define derivative
>work in this way, then I can configure, compile, and link the
Not me -- copyright law defines derivative works in this way.
>Linux kernel without permission of the copyright holder under
>first sale (since no derivative work is created). I can
>write a program that uses a library, compile my program, and
>link it to the library, again without creating a derivative
>work.
I already conceded on this.
(...)
>
>Read the quote above.
?! I did not understand which quote, or which part. But I
suspect you're talking about lu-12.html (below), for which
just now you pointed me to.
>>Second: you did not provide a concrete pointer to one of
>>Eben Moglen's posts, for instance, saying that modification
>>is not covered by the GPL. Me, OTOH, showed you that the
>>TEXT of the GPL says it covers modifications.
>
>
>Read the quote. For about the fourth time in this
>thread, here's the cite:
>http://emoglen.law.columbia.edu/publications/lu-12.html "The
>license does not require anyone to accept it in order to
>acquire, install, use, inspect, or even experimentally modify
>GPL'd software."
This is the first time you gave me an URL. I'll look into it.
(...)
>
>
>I never said that the FSF says the GPL does not cover
>modifications, I said it doesn't cover ordinary use. That
>means it doesn't cover modifications when those modifications
>are made in the course of ordinary use.
Insofar, you did not show me an example of need to create a
derivative work in the course of the ordinary use.
(...)
>Okay. So you get to the same place I get by a
>different route. One of the strange things I've noticed is
>nearly all cases, you get the same result whether you think
>the final work is a derivative work or not.
>
(...)
Now some things interesting:
>I don't think courts seem to agree with this, but I
>can only find cases where the result really would have been
>the same whether or not the work was derivative. For example,
>one case inolved a company that stole test questions from
>another company. The courts ruled that the test with some of
>the "borrowed" questions was a derivative work, even though
>there's no special "integration" of the questions. But they
>could perfectly well have reached the same conclusion without
>the "derivative work" argument.
>
>There are court cases on point that definitely
>disagree with you, for example Mirage Editions, Inv. v.
>Albuquerque ART (cutting a picture out of a book creates a
>derivative work). Also National Football League v. TVRadio
>Now (embedding someone else's broadcast with your
>advertisements through an automated process creates a
>derivative work).
The embedding was not made by a fully automated process, was
it? Didn't someone had to create the advertisements, with the
purpose to be presented embedded in the broadcast? I suspect
-- without looking at the case files at the moment -- that
there was the creation of the derivative works...
>
>I think it would make a lot of sense if courts held
>that compiling and linking are analogous to format changes
>(like converting an audio-visual work from DVD to VHS). This
Our (.br) courts do. I don't know (I'd have to read the cases
you cited) why did those courts ignored the intellectual
novelty requirement of a derivative work, but I'll look into
it.
>process involves making copies of the work so that it can be
>used in different environments that have different technical
>requirements. (Except in cases where one work is heavily
>adapted to the internals of another.) It's clear that anyone
>who tried to get an independent copyright on their compiled
>Linux kernel binary should be laughed off the planet.
>
>> >I think even if the result is not a derivative work,
>> >the rules for distributing it would be the same. However,
>> >it would change the rules for creating it. Either way,
>> >however, you get that you can do it without agreeing to
>> >the GPL, and this is the FSF's position.
>
>
>>You repeated this a lot of times, but you have not
>>substatitiated it, at least WRT something I asked you:
>>please, give me some *link* where EM, RMS, or any other
>>FSF/GNU guy contradicts the GPL section 0 paragraph 1
>>("modification") saying that you can modify a GPLd work
>>without agreeing to the GPL.
>
>
>This has always been their position, when modification
>is needed for ordinary use. Se
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, 2005-04-13 at 21:47 +0200, Sven Luther wrote: > On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote: > > > > This is different. They are not giving the source at all. The licence > > > > for those object files _has_ to be different. _They_ want it to be > > > > different. > > > > > > Sure, but in this case, the binary firmware blob is also a binary without > > > sources. If they really did write said firmware directly as it is, then > > > they > > > should say so, but this is contrary to everyone's expectation, and a > > > dangerous > > > precedent to set. > > > > You should realize that any author can publish his work in the form he > > likes. He's not bound to "everyone's expectation". I see no danger in > > that. > > I think there may be some limitation of using the GPL as licence in this case > though, as such behavior may limit its value, and the GPL itself is by no > means free software. That GPL isn't the best license in this case (firmware included as hexstring in the driver source), we already know. But fixing it is up to the copyright holder. We or GPL face no risk. Note that the holder does. I'd be interesting if someone produced a derivative work, such a translation. A translation from the hex form to some kind of textual formally defined language, such as, say, assembler, or C. That would be covered by GPL. And would be distributable under it. Say that the resulting binary is slightly different. You are _required_ by GPL to provide the source in the preferred form, this time, preferred by _you_. What if that is C? Interesting enough. Can the hexstring be reverse-engineered into C, if it's placed under GPL? Can the copyright holder really prevent that? Something new to think of. :-) Have a nice day, .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - 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.
> That is the point: the result is not a single work. It is a > collection or compilation of works, just like an anthology. If > there is any creativity involved, is in choosing and ordering > the parts. The creation of works that "can be linked together" > is not protected by copyright: the literary analogy was to > "create a robot short story". Such a story could go into an > anthology called (duh) "Robot Short Stories", but its > licensing is independent of every other robot short story in > the world -- except those it is a derivative work of. That's fine then, if you want to define derivative work in this way, then I can configure, compile, and link the Linux kernel without permission of the copyright holder under first sale (since no derivative work is created). I can write a program that uses a library, compile my program, and link it to the library, again without creating a derivative work. > You are making deaf ears: using a library (even by static > linkage) does NOT create a derivative work unless: > > (a) you make another version, subset or superset of > the same library, modifying, enhancing, the > functionality of the original library; or > > (b) you make a program that is *so* dependent on the > *internal* implementation structure of the library > that it can be considered a derivative work. Okay. This gets to the same result that I get to, which is that you can do all the things you want to do without permission from the copyright holder under first sale. Since this is not creating a derivative work, no special permission is needed. > >> >This is, by the way, the FSF's own position. It's not > >> >something I'm making up or guessing at. > >> > >>Please send us some pointers to this statements for the FSF. > > > > > >Read any of Eben Moglen's posts. > > > >> >"The license does not require anyone to accept it in order > >> >to acquire, install, use, inspect, or even experimentally > >> >modify GPL'd software. All of those activities are either > >> >forbidden > >> > >>Wrong again. GPL, section 0, para 1: "Activities other than > >>copying, distribution, and *modification* are not covered by > >>this License". Emphasis mine. > >You are free to disagree with the FSF's interpretation of the > >GPL, but you are not free to misrepresent the FSF's > >interpreration. > No. First of all: you are begin uncivil here. I did not accuse > you of anything, other than not reading correctly what I > wrote previously; which I can attribute to my poor knowledge > of the English language. So, please, I am not being impolite > to you, do the same. Read the quote above. > Second: you did not provide a concrete pointer to one of Eben > Moglen's posts, for instance, saying that modification is not > covered by the GPL. Me, OTOH, showed you that the TEXT of the > GPL says it covers modifications. Read the quote. For about the fourth time in this thread, here's the cite: http://emoglen.law.columbia.edu/publications/lu-12.html "The license does not require anyone to accept it in order to acquire, install, use, inspect, or even experimentally modify GPL'd software." > >Feel free to disagree with the FSF about the meaning of the > >GPL, but it is the FSF's position that you can modify a GPL'd > >work without agreeing to the GPL. > I don't disagree with the FSF -- you are alleging that this is > their position, and I am disagreeing with YOU. And you have > not produced evidence in contrary. I don't know what to say. The FSF has had a clear, consistent position on the GPL for a very long time and it has always been that ordinary use is permitted without agreeing to the GPL. For source code, modification is often part of ordinary use. Anyone who has grabbed a package intended for a different version of their OS and had to tweak things to get the code to work knows this. > We = You and Me disagreeing. And you still have to show where > the FSF says the GPL does not cover modifications. I never said that the FSF says the GPL does not cover modifications, I said it doesn't cover ordinary use. That means it doesn't cover modifications when those modifications are made in the course of ordinary use. > >2) The result is not a derivative work, hence you > >don't need permission from the copyright holder to do it. > ** THIS ** : yes, the result is NOT a derivative work. > So, to link with a library you don't need permission. > That's what I said since the beginning. > >Either way you get the same result, permission is not > >needed beyond permission to use. > > Conceded. Okay. So you get to the same place I get by a different route. One of the strange things I've noticed is nearly all cases, you get the same result whether you think the final work is a derivative work or not. > >Then all the people who think that creating a binary > >k
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz wrote: >> >Would you agree that compiling and linking a program that >> >uses a library creates a derivative work of that library? > > >>No. Compiling and linking are mechanical, >>non-intellectually-novel acts. At most, you have a >>collective work where the real intellectually-novel work was >>to select what goes into the collective. > > >Compiling and linking are mechanical, but unless you >want to argue that the result is not a single work, it >clearly creates a derivative work of all the things linked. >The creativity is not in the linking itself but in the >creation of the individual works such that they can be linked >together. That is the point: the result is not a single work. It is a collection or compilation of works, just like an anthology. If there is any creativity involved, is in choosing and ordering the parts. The creation of works that "can be linked together" is not protected by copyright: the literary analogy was to "create a robot short story". Such a story could go into an anthology called (duh) "Robot Short Stories", but its licensing is independent of every other robot short story in the world -- except those it is a derivative work of. Now, this is what copyright protects: creation of derivative works (see the definition, below) is an exclusive right of the copyright owner. I can't write a history featuring Daneel Olivaw or Susan Calving without the (written, express) permission of Mrs. Asimov and/or her daughter. And if I *do* have their consent (in the form of GPL'ing it, for instance), even so I can only copy and distribute *my* work in the terms permitted expressely by the consent I received (in the example, the terms of the GPL) > >> >Wouldn't you agree that this is the normal form of use of >> >a library? And doesn't first sale give you the right to >> >normal use of a work you have legally acquired? >> >>Yes. And yes, if you buy a copy of the library, yes (but >>notice: not if you downloaded it for free from the Net). > > >There is no legal distinction. Why do you think that? You can even be right on this, but your argument below did not convince me. >Your rights come not from the fact that you paid money for >the work but simply from the fact that you acquired it >legally. Again, the reductio ad absurdum is the guy who drops >copies of his poem from an airplane and then demands >royalities from everyone who reads it. If you legally >acquired it, you get the bundle of rights under first sale. You are spinning, you know? If I drop a poem from an airplane, and you get it from the ground, you can read it (this is not forbidden by copyright law) but you have *no* right of copying it, publishing it or redistributing it. Especially if my poem has my name or pseudonym on it. Yeah, you can even get the bundle of rights under first sale if you acquired it lawfully, and I must be wrong about my quoted paragraph above, and so I back out on my error and apologize for it. But making a derivative work is not (in principle) a first sale doctrine right. > >> >There are many ways you can lawfully create a derivative >> >work without explicit permission of the copyright holder. >> >One >> >>No. The copyright law states that the copyright owner has >>the monopolistic right to create derivative works. > > >Yes, but this doesn't restrict first sale or fair use. >You cannot use a library without creating a derivative work, >so if first sale grants you rights to use, it automatically >grants you the right to do anything necessary for use. You are making deaf ears: using a library (even by static linkage) does NOT create a derivative work unless: (a) you make another version, subset or superset of the same library, modifying, enhancing, the functionality of the original library; or (b) you make a program that is *so* dependent on the *internal* implementation structure of the library that it can be considered a derivative work. > >> >clear case is when you lawfully possess the work, there is >> >no EULA or shrink-wrap agreement, and you need to produce >> >a derivative work to use the work in the ordinary fashion. > > >>No... Try writing a book with Harry Potter as your main >>character and JKR's lawyers will be at your door soon. > > >Sometimes I wonder if you are reading what I said or not. Me too. >I said "you need to produce a derivative work to use the >work in the ordinary fashion" and you say "No" and follow >with an example where you clearly *don't* need to produce a >derivative work to use the work in the ordinary fashion. Ok, let's replay: David: "There are many ways you can lawfully create a derivative work." Me: "no, the only way to create a derivative work lawfully is having an authorization from the copyright owner." David: "You cannot use a library without creating a derivative work,", implying that it would be your first sale doctring right. Me: "No, simply linking a library in NO hypothesis creates a derivative w
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > What compels you to agree with an EULA? On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote: > If you do not agree with the EULA, you cannot and do not acquire > lawful possession of the work. What about cases where you pay for the software before you're allowed to see the EULA? -- Raul - 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/
[Long OT] Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
This thread should probably get moved off-list soon, it's like beating the dead horse long after its flesh has decayed and its bones disintegrated to dust. On Apr 13, 2005, at 21:54, David Schwartz wrote: On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote: Yes, the GPL can give you rights you wouldn't otherwise have. A EULA can take away rights you would otherwise have. What compels you to agree with an EULA? If you do not agree with the EULA, you cannot and do not acquire lawful possession of the work. Of course, one could always assert the following: 1) I went to a store 2) I found a box 3) I went to the cash register 4) I gave money to the cashier for the box 5) I took the box home 6) I opened the box and took out the contents Now, to the end user, the above is the same procedure for purchasing a box of cereal or a piece of software, therefore the restrictions are the same. I'm not allowed to distribute the copyrightable materials, which for a cereal box is the images on the box, and for a CD is the digital data stored therein. Other than that, I can take a hammer and smash my CD/cereal, I can make a dozen copies of the CD/box-art and mount them on the wall or burn them, both of which are symbolic speech. I can make backup copies of my cereal box-art/CD too. At what point of the above did I agree to any license? As far as I know, a license (IE: contract) is not valid for a product unless made at the point-of-sale, before exchanging money. This is especially valid since almost all computer retailers refuse refunds for opened software. When you have to open the box to see the license, that's bad, but when, as I've seen far too many times, you have to break the seal and insert the CD to even _see_ the license, it cannot be valid. The only real point of most of the EULAs is to protect the owners copyright, which is implicitly protected in any case. Cheers, Kyle Moffett -BEGIN GEEK CODE BLOCK- Version: 3.12 GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$ L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r !y?(-) --END GEEK CODE BLOCK-- - 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.
> On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote: > > Yes, the GPL can give you rights you wouldn't otherwise have. A > > EULA can take away rights you would otherwise have. > What compels you to agree with an EULA? If you do not agree with the EULA, you cannot and do not acquire lawful possession of the work. > > In the few court cases that have directly addresses shrink-wrap and > > click-wrap type agreements, I've seen them consistently upheld. However, > > this is not relevent to the GPL issue at all because the GPL > > can only give > > you rights you wouldn't otherwise have, it cannot take away any rights. > The GPL offers you certain rights if you agree to be bound by certain > conditions. Right, and normally the way you become bound by the GPL is if you do something that you could not acquire the right to do any other way. That's why GPL issues frequently hinge on whether you could not acquire the right any other way. Possible other ways include first sale and fair use. > You are not compelled to agree to those conditions, but those who do > not gain no rights from the GPL. Right, again, that's why it's important to look at whether they could have acquired the rights any other way. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> >Would you agree that compiling and linking a program that > >uses a library creates a derivative work of that library? > No. Compiling and linking are mechanical, > non-intellectually-novel acts. At most, you have a collective > work where the real intellectually-novel work was to select > what goes into the collective. Compiling and linking are mechanical, but unless you want to argue that the result is not a single work, it clearly creates a derivative work of all the things linked. The creativity is not in the linking itself but in the creation of the individual works such that they can be linked together. > >Wouldn't you agree that this is the normal form of use of a > >library? And doesn't first sale give you the right to normal > >use of a work you have legally acquired? > > Yes. And yes, if you buy a copy of the library, yes (but > notice: not if you downloaded it for free from the Net). There is no legal distinction. Your rights come not from the fact that you paid money for the work but simply from the fact that you acquired it legally. Again, the reductio ad absurdum is the guy who drops copies of his poem from an airplane and then demands royalities from everyone who reads it. If you legally acquired it, you get the bundle of rights under first sale. > >There are many ways you can lawfully create a derivative work > >without explicit permission of the copyright holder. One > > No. The copyright law states that the copyright owner has the > monopolistic right to create derivative works. Yes, but this doesn't restrict first sale or fair use. You cannot use a library without creating a derivative work, so if first sale grants you rights to use, it automatically grants you the right to do anything necessary for use. > >clear case is when you lawfully possess the work, there is no > >EULA or shrink-wrap agreement, and you need to produce a > >derivative work to use the work in the ordinary fashion. > No... Try writing a book with Harry Potter as your main > character and JKR's lawyers will be at your door soon. Sometimes I wonder if you are reading what I said or not. I said "you need to produce a derivative work to use the work in the ordinary fashion" and you say "No" and follow with an example where you clearly *don't* need to produce a derivative work to use the work in the ordinary fashion. > >This is, by the way, the FSF's own position. It's not > >something I'm making up or guessing at. > > Please send us some pointers to this statements for the FSF. Read any of Eben Moglen's posts. > >"The license does not require anyone to accept it in order to > >acquire, install, use, inspect, or even experimentally modify > >GPL'd software. All of those activities are either forbidden > > Wrong again. GPL, section 0, para 1: "Activities other than > copying, distribution, and *modification* are not covered by > this License". Emphasis mine. You are free to disagree with the FSF's interpretation of the GPL, but you are not free to misrepresent the FSF's interpreration. > >or controlled by proprietary software firms, so they require > >you to accept a license, including contractual provisions > >outside the reach of copyright, before you can use their > >works. The free software movement thinks all those > >activities are rights, which all users ought to have; we > >don't even want to cover those activities by license." > > Except for the modification part, which *is* the scope of > regular, Berne-convention-molded copyrights law. Feel free to disagree with the FSF about the meaning of the GPL, but it is the FSF's position that you can modify a GPL'd work without agreeing to the GPL. > >Now we draw different conclusions based on this, but we agree > >on this. You do not need to agree to the GPL to create > >derivative works. > > No, we disagree on this too. I don't know who "we" is, but I agree with the FSF. > >>If you will keep your copy and registration # of windows, > >>yes, you *must* wipe out the machine before selling it. > > > > > >Since there is no copy or registration number of a GPL'd work > >to keep, this actually argues the reverse of what I said. If > >I legally acquire ten copies of Windows, I can perform normal > >use on those ten copies and then transfer those copies to > >someone else. > This is not the point: you still would have to wipe your ten > computers clean if you want to sell the ten copies you have. Right. You cannot increase the number of copies. > In the GPL'd case, if you disregard the terms of the license, > you can still keep, use, etc. You can *not* copy it, > distribute it, or modify it tough. You can, so long as you don't increase the number of copies. This is a right under first sale. > >>So, no, when you get a WinXP CD from Microsoft, you have > >>absolutely *no* rights to create derivative works. If a > >>person creates a
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote: > > > This is different. They are not giving the source at all. The licence > > > for those object files _has_ to be different. _They_ want it to be > > > different. > > > > Sure, but in this case, the binary firmware blob is also a binary without > > sources. If they really did write said firmware directly as it is, then they > > should say so, but this is contrary to everyone's expectation, and a > > dangerous > > precedent to set. > > You should realize that any author can publish his work in the form he > likes. He's not bound to "everyone's expectation". I see no danger in > that. I think there may be some limitation of using the GPL as licence in this case though, as such behavior may limit its value, and the GPL itself is by no means free software. Friendly, Sven Luther - 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.
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote: > On Tue, Apr 12, 2005 at 06:14:17PM +0200, Marco Colombo wrote: > > No one will ever do that. If you are distributing the software I released > > under GPL, be sure I _will_ sue you if you break the licence. What do you > > want from me? A promise I won't sue you if you don't? That is implicit > > in the existance of the licence. > > > > Are you implying debian will stop distributing _any_ software unless > > the all the copyright holders of GPL software "explicitly say" they > > won't sue you? > > Well, we won't distribute binaries placed under the GPL, definitively not. And > if there is a dubious case, we ask for clarification of the author. Your choice, of course. [...] > > This is different. They are not giving the source at all. The licence > > for those object files _has_ to be different. _They_ want it to be > > different. > > Sure, but in this case, the binary firmware blob is also a binary without > sources. If they really did write said firmware directly as it is, then they > should say so, but this is contrary to everyone's expectation, and a dangerous > precedent to set. You should realize that any author can publish his work in the form he likes. He's not bound to "everyone's expectation". I see no danger in that. > > >So, really, i doubt any manufacturer distributing non-free firmware would > > >really have trouble in adding to their licence something like this : > > > > > > In addition, , considers the firmware blob, identified as > > > <...>, as > > > a non-derivative piece of work, and thus not covered by the GPL of the > > > rest > > > of it. gives permission to distribute said firmware blob as > > > part of the linux kernel module driver for their hardware. The actual > > > syntax > > > of the inclusion of the code is still covered by the GPL, as is the rest > > > of > > > the driver code. > > > > This is fine with me. It is the existance of legal threats versus > > debian I don't agree upon. > > Notice that debian can't afford to be sued even if they are right, so ... So what? This is not the point. You can be sued any time by any one, even if you're right. If debian can't afford it, it can't afford existance. > > >>Yes, but it does not apply to our case here. There's no "all other > > >>copyright holders". _You_ stated that the firmware is included by mere > > >>aggregation, so there's no other holders involved. We're talking > > >>about the firmware case. A is one or two well identified subjects. > > >>And A wrote it is GPL'ed. Whether you agree or not, that's the licence > > >>A chose. A placed the copyright notice. > > > > > >This is where i would need legal counsel, as to whether this means C or > > >someone else may stop you from distributing unless you provide the source. > > >And > > >the real problem is that A didn't state anything, so we are only working on > > >the assumption that this may be the case, and A can change its mind later, > > >and > > >the costs to defend ourselves in front of a judge, even if your > > >interpretations are right, are enough prohibitive for debian not to > > >distribute > > >said files. > > > > A did put a GPL notice on it. He can't change his mind later. > > Then he should give us the source. No, why? GPL cannot place restrictions or obligations on the copyright owner. Let's stop discussing it please, you can't buy me on this either. I have my own interpretation of what a license it, and it seems you don't agree with it: to me, it's one way: _you_, the licensee, get some rights if you fulfill some conditions. Conditions are all placed on you, none on the copyright holder. In particular, the one about making source available is placed on distributors, verbatim copies of the source for binary distribution of the work, or full source of the modifications for modified versions of the work. And anyway, this has nothing to do with with legal threats from the copyright holder. My point being: he cannot sue you for not distributing the source "as provided by him" if he failed to provide them in the first place in a different from. That is, he has to give you the source, if he is trying to force you distributing it. > > >>The licence is a matter between A and D. A may sue D and D may (less > > >>likely) sue A, if conditions are not met. I'm not sure at all GPL > > >>is enforceable by D upon A. Let's assume it is, for sake of discussion, > > >>anyway. > > > > > >Ah, but the licence is transitive, and if D may sue A, then C may also sue > > >D, > > >since the GPL makes no distinction between who makes the distribution, > > >apart > > >from the fact that A may relicence its code. But if he distributes it as > > >part > > >of the GPL ... > > > > Pardon me, I have no idea of what a "transitive" licence could be. > > Sublicencing or relicencing is _explicitly_ not covered by GPL anyway. > > You give away the source to someone, he has the same rights you had, except > relicen
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 11:28:59PM -0700, Sean Kellogg wrote: > Failure to have a click-through license means that there is no acceptance, > which is a fundamental part of contract law. No acceptance, no > contract, no exceptions. False. For example, you can indicate acceptance of the GPL by exercising the rights it grants. Furthermore, the converse is also false: it's quite possible to install software on your machine without clicking on the click-through license. For example, someone else might install it for you. [You expect my dad to figure out how to install anything?] -- Raul - 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.
On Tue, 12 Apr 2005, David Schwartz wrote: > > > > The EULA is irrelevant in germany and in many parts of the USA. > > > > Really? I was under the impression EULA's were routinely > > > upheld in the USA. > > > If you have any references for that, I'd love to hear them. > > > http://www.freibrunlaw.com/articles/articl22.htm > > This wasn't a copyright case. The court only refused to uphold the > agreement because there was no oppurtunity to review the agreement before > purchase. So it certainly wouldn't apply to a click-through type agreement. So you can review click-through-licenses before buying the product? -- Funny quotes: 32. "I am" is reportedly the shortest sentence in the English language. Could it be that "I do" is the longest sentence? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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.
On Tuesday 12 April 2005 10:46 pm, Raul Miller wrote: > In essence, you're claiming that the difference between Davidson > & Associates v. Internet Gateway Inc (2004) and other cases such as > Softman v. Adobe (2001) and Novell, Inc. v. CPU Distrib., Inc. (2000) > is that the presence of a click-through is the determining factor. > Of course, it could just as easily be something else (for example, > admitting in court agreement with the license). Failure to have a click-through license means that there is no acceptance, which is a fundamental part of contract law. No acceptance, no contract, no exceptions. So yes, the difference in many of the click through license cases is whether the contract was something you couldn't avoid accepting. There is talk these days among tech contract drafters to develop a more universal method for electronic acceptance... probably something that will be written into the Uniform Commercial Code in the next few decades (behold, the speed of legal evolution!). -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] c: 206.498.8207 e: [EMAIL PROTECTED] w: http://probonogeek.blogspot.com So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown - 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.
On Tue, Apr 12, 2005 at 03:45:43PM -0700, David Schwartz wrote: > This wasn't a copyright case. The court only refused to uphold the > agreement because there was no oppurtunity to review the agreement before > purchase. So it certainly wouldn't apply to a click-through type agreement. http://www.answers.com/topic/first-sale-doctrine cites several cases, and has a very nice writeup on the current status of this issue. In essence, you're claiming that the difference between Davidson & Associates v. Internet Gateway Inc (2004) and other cases such as Softman v. Adobe (2001) and Novell, Inc. v. CPU Distrib., Inc. (2000) is that the presence of a click-through is the determining factor. Of course, it could just as easily be something else (for example, admitting in court agreement with the license). Does this thread have anything to do with the linux kernel at this point? -- Raul - 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.
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote: [snip] > > A did put a GPL notice on it. He can't change his mind later. > Then he should give us the source. [snip] > The fact remains that those firmware blob have no licence, and thus defacto > fall under the GPL. > > > Moreover, the firmare in not in binary form, but is part of a C source > > file. > > It is in binary form. Disguised binary form maybe but still binary form. [snip] > And where did those hexstrings come from ? It seems to me, that to be consistent with the argument you seem to be presenting concerning binary data in GPLd code, that you also need to be demanding the "source" hardware design for binary register values. Why not consider the binary firmware in the same category as binary register programming information? You poke these magic bytes into these memory locations and it works. Where do you draw the lines between "write this byte to set the input gate here and the output gate to there" and "write this byte sequence to send the input byte through this loop, into this buffer, add it to the last byte entered, and output it over there"? -- Zan Lynx <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz wrote: >>David Schwartz wrote: >> >>> 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. > > >>The only way to *create* a derivative work is with >>permission of the copyright owner of the original work. >>Period. This permission can come implicitly *if* you agree >>with licensing terms, but not under first sale or fair use >>*limitations*. (First sale / fair use are statutory >>limitations on copyrights, not rights). > > >Would you agree that compiling and linking a program that >uses a library creates a derivative work of that library? No. Compiling and linking are mechanical, non-intellectually-novel acts. At most, you have a collective work where the real intellectually-novel work was to select what goes into the collective. >Wouldn't you agree that this is the normal form of use of a >library? And doesn't first sale give you the right to normal >use of a work you have legally acquired? Yes. And yes, if you buy a copy of the library, yes (but notice: not if you downloaded it for free from the Net). > >There are many ways you can lawfully create a derivative work >without explicit permission of the copyright holder. One No. The copyright law states that the copyright owner has the monopolistic right to create derivative works. >clear case is when you lawfully possess the work, there is no >EULA or shrink-wrap agreement, and you need to produce a >derivative work to use the work in the ordinary fashion. No... Try writing a book with Harry Potter as your main character and JKR's lawyers will be at your door soon. >This is, by the way, the FSF's own position. It's not >something I'm making up or guessing at. Please send us some pointers to this statements for the FSF. >"The license does not require anyone to accept it in order to >acquire, install, use, inspect, or even experimentally modify >GPL'd software. All of those activities are either forbidden Wrong again. GPL, section 0, para 1: "Activities other than copying, distribution, and *modification* are not covered by this License". Emphasis mine. >or controlled by proprietary software firms, so they require >you to accept a license, including contractual provisions >outside the reach of copyright, before you can use their >works. The free software movement thinks all those >activities are rights, which all users ought to have; we >don't even want to cover those activities by license." Except for the modification part, which *is* the scope of regular, Berne-convention-molded copyrights law. >Now we draw different conclusions based on this, but we agree >on this. You do not need to agree to the GPL to create >derivative works. No, we disagree on this too. >>If you will keep your copy and registration # of windows, >>yes, you *must* wipe out the machine before selling it. > > >Since there is no copy or registration number of a GPL'd work >to keep, this actually argues the reverse of what I said. If >I legally acquire ten copies of Windows, I can perform normal >use on those ten copies and then transfer those copies to >someone else. This is not the point: you still would have to wipe your ten computers clean if you want to sell the ten copies you have. In the GPL'd case, if you disregard the terms of the license, you can still keep, use, etc. You can *not* copy it, distribute it, or modify it tough. >>The point is moot, anyway, because the image is *not* a >>derivative work: It is a copy of the work, made by automated >>and automatable processes. It's not a creation of the >>spirit. > > >I don't think this makes a difference. If it's a derivative >work, it's one created in the course of ordinary use. In any >event, first sale would be the same either way. The point is: it's *not* a derivative work. period. Yes, first sale would apply to the same extent that it applies to the original software. >>So, no, when you get a WinXP CD from Microsoft, you have >>absolutely *no* rights to create derivative works. If a >>person creates a derivative work, even if it does not >>distribute it, it would be infringing on MS's copyrights and >>I would not want to be in said person's shoes, if someone in >>the legal department of MS wakes up in the wrong side of the >>bed. > > >But you do have the right to create derivative works if such >derivative works are necessarily created in the process of >the ordinary use of the work. Ok, let's repeat ourselves: A derivative work is a novel intellectual creation (of the spirit) that results from some transformation of another work, said the "original" work. There is a similar (identical?) definition on 17 USC, but I am quoting (bad translation mine) our "Lei 9610/98 -- Lei de Direitos Autorais" (1998 Brazilian Author's Rights Act), art. 5º, VIII, 'g'. I can't think of any example where to use a wor
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 06:14:17PM +0200, Marco Colombo wrote: > No one will ever do that. If you are distributing the software I released > under GPL, be sure I _will_ sue you if you break the licence. What do you > want from me? A promise I won't sue you if you don't? That is implicit > in the existance of the licence. > > Are you implying debian will stop distributing _any_ software unless > the all the copyright holders of GPL software "explicitly say" they > won't sue you? Well, we won't distribute binaries placed under the GPL, definitively not. And if there is a dubious case, we ask for clarification of the author. > >As an example, i package the unicorn driver for the bewan soft-ADSL pci and > >usb modems. These being soft-ADSL modems which use a non-free binary-only > >ADSL > >emulating library, but are otherwise GPL, i discussed the matter with > >upstream, and after council from debian-legal, and possibly the FSF people > >themselves, we got to use this as GPL exception : > > > > In addition, as a special exception, BeWAN systems gives permission > > to link the code of this program with the modem SW library > > (modem_ant_PCI.o, modem_ant_USB.o), and distribute linked combinations > > including the two. You are also given permission to redistribute the > > modem SW library (modem_ant_PCI.o, modem_ant_USB.o) with the rest of the > > code. > > You must obey the GNU General Public License in all respects for all of > > the code used other than the modem SW library. > > This is different. They are not giving the source at all. The licence > for those object files _has_ to be different. _They_ want it to be > different. Sure, but in this case, the binary firmware blob is also a binary without sources. If they really did write said firmware directly as it is, then they should say so, but this is contrary to everyone's expectation, and a dangerous precedent to set. > >So, really, i doubt any manufacturer distributing non-free firmware would > >really have trouble in adding to their licence something like this : > > > > In addition, , considers the firmware blob, identified as > > <...>, as > > a non-derivative piece of work, and thus not covered by the GPL of the > > rest > > of it. gives permission to distribute said firmware blob as > > part of the linux kernel module driver for their hardware. The actual > > syntax > > of the inclusion of the code is still covered by the GPL, as is the rest > > of > > the driver code. > > This is fine with me. It is the existance of legal threats versus > debian I don't agree upon. Notice that debian can't afford to be sued even if they are right, so ... > >>Yes, but it does not apply to our case here. There's no "all other > >>copyright holders". _You_ stated that the firmware is included by mere > >>aggregation, so there's no other holders involved. We're talking > >>about the firmware case. A is one or two well identified subjects. > >>And A wrote it is GPL'ed. Whether you agree or not, that's the licence > >>A chose. A placed the copyright notice. > > > >This is where i would need legal counsel, as to whether this means C or > >someone else may stop you from distributing unless you provide the source. > >And > >the real problem is that A didn't state anything, so we are only working on > >the assumption that this may be the case, and A can change its mind later, > >and > >the costs to defend ourselves in front of a judge, even if your > >interpretations are right, are enough prohibitive for debian not to > >distribute > >said files. > > A did put a GPL notice on it. He can't change his mind later. Then he should give us the source. > >>The licence is a matter between A and D. A may sue D and D may (less > >>likely) sue A, if conditions are not met. I'm not sure at all GPL > >>is enforceable by D upon A. Let's assume it is, for sake of discussion, > >>anyway. > > > >Ah, but the licence is transitive, and if D may sue A, then C may also sue > >D, > >since the GPL makes no distinction between who makes the distribution, > >apart > >from the fact that A may relicence its code. But if he distributes it as > >part > >of the GPL ... > > Pardon me, I have no idea of what a "transitive" licence could be. > Sublicencing or relicencing is _explicitly_ not covered by GPL anyway. You give away the source to someone, he has the same rights you had, except relicencing, this is what i meant by transitive. > Also I have no idea of what you mean "GPL makes no distinction between > who makes the distribution". GPL for sure places no restrictions on > how A can distribute his software. A needs no license for exercising No, it gives A the choice to distribute its software under the GPL, or under another licence. > rights on the software. He is the _owner_ of rights. A cannot "break" > the GPL. A needs no GPL to distribute. Are you saying A may sue himself? Yes, he can break the commonly accepted expectation of a GPLed software, which is what happens h
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> David Schwartz wrote: > > > 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. > The only way to *create* a derivative work is with permission of the > copyright owner of the original work. Period. This permission can come > implicitly *if* you agree with licensing terms, but not under first sale > or fair use *limitations*. (First sale / fair use are statutory > limitations on copyrights, not rights). Would you agree that compiling and linking a program that uses a library creates a derivative work of that library? Wouldn't you agree that this is the normal form of use of a library? And doesn't first sale give you the right to normal use of a work you have legally acquired? There are many ways you can lawfully create a derivative work without explicit permission of the copyright holder. One clear case is when you lawfully possess the work, there is no EULA or shrink-wrap agreement, and you need to produce a derivative work to use the work in the ordinary fashion. This is, by the way, the FSF's own position. It's not something I'm making up or guessing at. "The license does not require anyone to accept it in order to acquire, install, use, inspect, or even experimentally modify GPL'd software. All of those activities are either forbidden or controlled by proprietary software firms, so they require you to accept a license, including contractual provisions outside the reach of copyright, before you can use their works. The free software movement thinks all those activities are rights, which all users ought to have; we don't even want to cover those activities by license." Now we draw different conclusions based on this, but we agree on this. You do not need to agree to the GPL to create derivative works. > If you will keep your copy and registration # of windows, yes, > you *must* wipe out the machine before selling it. Since there is no copy or registration number of a GPL'd work to keep, this actually argues the reverse of what I said. If I legally acquire ten copies of Windows, I can perform normal use on those ten copies and then transfer those copies to someone else. > The point is moot, anyway, because the image is *not* a > derivative work: It is a copy of the work, made by automated > and automatable processes. It's not a creation of the spirit. I don't think this makes a difference. If it's a derivative work, it's one created in the course of ordinary use. In any event, first sale would be the same either way. > So, no, when you get a WinXP CD from Microsoft, you have > absolutely *no* rights to create derivative works. If a person > creates a derivative work, even if it does not distribute it, > it would be infringing on MS's copyrights and I would not want > to be in said person's shoes, if someone in the legal > department of MS wakes up in the wrong side of the bed. But you do have the right to create derivative works if such derivative works are necessarily created in the process of the ordinary use of the work. I think that if I write software that runs under Windows, an argument can be made that that software is a derivative work of Windows. That argument is as strong as the argument that a driver with linked in firmware is a single work. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 12 Apr 2005, David Schwartz wrote: > > If you buy a W*nd*ws install CD, you can create a derived work, > > e.g. an image > > of your installation, under the fair use rights (IANAL). Can you > > distribute > > that image freely? > > I would say that if not for the EULA, you could transfer ownership of > the > image to someone else. The EULA is irrelevant in germany and in many parts of the USA. > And if you legally acquired two copies of Windows, > you could install both of them and transfer them. Otherwise, you could not > sell a machine with the Windows OS installed unless you were a Microsoft > OEM. Then it would be stupid to become a OEM. Just buy one CD and install it on each computer you sell, combined with a pre-installed ghost. > Does Microsoft take the position that if you want to sell your PC, you > must wipe the OS? Not that I know of. They say it's forbidden do pass even the boot loader you put on disks, they just won't sue you for just the boot loader. -- Funny quotes: 36. You never really learn to swear until you learn to drive. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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.
> > > The EULA is irrelevant in germany and in many parts of the USA. > > Really? I was under the impression EULA's were routinely > > upheld in the USA. > > If you have any references for that, I'd love to hear them. > http://www.freibrunlaw.com/articles/articl22.htm This wasn't a copyright case. The court only refused to uphold the agreement because there was no oppurtunity to review the agreement before purchase. So it certainly wouldn't apply to a click-through type agreement. This is also one ruling by a district court, and the ruling is in the process of being appealed. Anyone relying on this and ignoring a EULA would be foolish indeed. There are several other shrink-wrap cases where courts have enforced the agreements. See, for example, Hill v. Gateway 2000 and Mortgage Plus v. DocMagic. It is reasonable to describe this area as somewhat uncertain. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Tue, Apr 12, 2005 at 09:44:29AM -0700, David Schwartz wrote: > > I would say that if not for the EULA, you could transfer ownership > > of the image to someone else. And if you legally acquired two copies of > > Windows, you could install both of them and transfer them. Otherwise, > > you could not sell a machine with the Windows OS installed unless you > > were a Microsoft OEM. Does Microsoft take the position that if you want > > to sell your PC, you must wipe the OS? Not that I know of. > [1] I think you've confused Microsoft's Original Equipment Manufacturer > License with Microsoft's End User License Agreement. I wasn't talking about the specific terms of any agreement. I was just saying that to make this analogous to the GPL situation (which was the point of this example), you would have to ignore any shrink-wrap agreement because the GPL is not a shrink-wrap agreement and the rules for shrink-wrap agreements are totally different from the rules for license. > [2] The grounds for Microsoft's EULA are much weaker than the grounds > for the GPL restrctions on the production of derivative works. That doesn't matter, the GPL doesn't set the scope of its own authority. None of what I'm saying has anything to do with the text of the GPL because the GPL can only add new rights. I'm talking strictly about the rights you automatically have if you legally possess the work under fair use and first sale. > At least with the GPL, you're getting something you didn't already have > (rights restricted to the copyright holder -- for example, in the states, > under 17 USC 106). Yes, the GPL can give you rights you wouldn't otherwise have. A EULA can take away rights you would otherwise have. > With Microsoft's EULA, it's not clear that you're getting anything > in exchange for complying with the copyright -- at least not in the > U.S. which is where Microsoft is based. You already have a number of > rights (17 USC 107, 17 USC 117), and while the DMCA has put into law > that you can't bypass copyright protection (17 USC 1201), it seems to > allow bypassing technological defects which would prevent actions allowed > under copyright. > It's probably worth noting that legal actions based on Microsoft's > EULA are settled out of court -- Microsoft has a history putting a > lot of direct and indirect pressure on people charged with violating > the agreement and, in the rare case where someone has stood up to the > pressure, of cutting their losses and settling out of court. In the few court cases that have directly addresses shrink-wrap and click-wrap type agreements, I've seen them consistently upheld. However, this is not relevent to the GPL issue at all because the GPL can only give you rights you wouldn't otherwise have, it cannot take away any rights. If you legally acquire a work free of any shrink-wrap agreement, and this goes for all GPL'd works, you can use it. This includes any steps necessary for ordinary use, including making derivative works if that's part of the ordinary, expected use. You can also transfer any legally-acquired copy you might have, along with any and all derivative works you made in the process of ordinary use. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote: > Yes, the GPL can give you rights you wouldn't otherwise have. A > EULA can take away rights you would otherwise have. What compels you to agree with an EULA? > In the few court cases that have directly addresses shrink-wrap and > click-wrap type agreements, I've seen them consistently upheld. However, > this is not relevent to the GPL issue at all because the GPL can only give > you rights you wouldn't otherwise have, it cannot take away any rights. The GPL offers you certain rights if you agree to be bound by certain conditions. You are not compelled to agree to those conditions, but those who do not gain no rights from the GPL. -- Raul - 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.
On Tue, Apr 12, 2005 at 12:01:15PM -0700, David Schwartz wrote: > Would you agree that compiling and linking a program that uses > a library creates a derivative work of that library? No, I would not. Creating a derivative work requires creativity, and a linker is not creative. The copyright issues for the linked program are the copyright issues for the unlinked program. Of course, you might have evidence in the form of a linked program where you don't have evidence in the form of an unlinked program. But that's a practical issue, not a copyright issue. > And doesn't first sale give you the right to normal use of a work you > have legally acquired? The first sale doctrine (basically, 17 USC 109) doesn't really say that. > There are many ways you can lawfully create a derivative work without > explicit permission of the copyright holder. One clear case is when you > lawfully possess the work, there is no EULA or shrink-wrap agreement, and > you need to produce a derivative work to use the work in the ordinary > fashion. I don't think the words you're using mean what you think they mean. I'm just going to quote part of 17 USC 106 at you. "... the owner of copyright ... has the exclusive rights to ... prepare derivative works ...". Go look it up yourself if you think the text I've omitted makes it mean something different. -- Raul - 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.
On Tue, 12 Apr 2005, David Schwartz wrote: > > The EULA is irrelevant in germany and in many parts of the USA. > > Really? I was under the impression EULA's were routinely upheld in the > USA. > If you have any references for that, I'd love to hear them. http://www.freibrunlaw.com/articles/articl22.htm -- Top 100 things you don't want the sysadmin to say: 90. Wowthat seemed _fast_. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - 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.
> On Tue, 12 Apr 2005, David Schwartz wrote: > > > If you buy a W*nd*ws install CD, you can create a derived work, > > > e.g. an image > > > of your installation, under the fair use rights (IANAL). Can you > > > distribute > > > that image freely? > > I would say that if not for the EULA, you could transfer > > ownership of the > > image to someone else. > The EULA is irrelevant in germany and in many parts of the USA. Really? I was under the impression EULA's were routinely upheld in the USA. If you have any references for that, I'd love to hear them. > > And if you legally acquired two copies of Windows, > > you could install both of them and transfer them. Otherwise, > > you could not > > sell a machine with the Windows OS installed unless you were a Microsoft > > OEM. > Then it would be stupid to become a OEM. Just buy one CD and > install it on > each computer you sell, combined with a pre-installed ghost. You can only transfer each legally acquired copy once. The nice thing about GPL'd works is you can easily legally acquire as many copies as you want. But for works that are sold for a price, you have to legally acquire one copy for each one you transfer. *You* cannot increase the number of copies of the work, only a lawful distributor of the work can. If you don't want to be bound by the GPL and you want to give ten friends copies of a Linux install disk, you could download ten copies of that disk from an FTP site, transfer them each to a floppy and destroy all other copies. You could then give those copies away under first sale rights. However, technically, if you gave out eleven copies and only legally acquired nine, you are exceeding your rights under first sale. > > Does Microsoft take the position that if you want to sell your PC, you > > must wipe the OS? Not that I know of. > They say it's forbidden do pass even the boot loader you put on disks, > they just won't sue you for just the boot loader. Right, but in these cases the number of copies of the work is increased by the person. In the case of most GPL'd work, you can find any number of web sites that will do this for you. They have to comply with the GPL but you don't. (You don't have to agree to the GPL to lawfully acquire as many copies of the work as you want. Each copy can be lawfully transferred to another under first sale rights.) If you acquire a copy of a GPL'd work that is sold for a price, and you only buy one copy, you cannot make and distribute additional copies without complying with the GPL. Each lawfully-acquired copy can be transferred, however. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 12, 2005 at 09:44:29AM -0700, David Schwartz wrote: > I would say that if not for the EULA, you could transfer ownership > of the image to someone else. And if you legally acquired two copies of > Windows, you could install both of them and transfer them. Otherwise, > you could not sell a machine with the Windows OS installed unless you > were a Microsoft OEM. Does Microsoft take the position that if you want > to sell your PC, you must wipe the OS? Not that I know of. [1] I think you've confused Microsoft's Original Equipment Manufacturer License with Microsoft's End User License Agreement. [2] The grounds for Microsoft's EULA are much weaker than the grounds for the GPL restrctions on the production of derivative works. At least with the GPL, you're getting something you didn't already have (rights restricted to the copyright holder -- for example, in the states, under 17 USC 106). With Microsoft's EULA, it's not clear that you're getting anything in exchange for complying with the copyright -- at least not in the U.S. which is where Microsoft is based. You already have a number of rights (17 USC 107, 17 USC 117), and while the DMCA has put into law that you can't bypass copyright protection (17 USC 1201), it seems to allow bypassing technological defects which would prevent actions allowed under copyright. It's probably worth noting that legal actions based on Microsoft's EULA are settled out of court -- Microsoft has a history putting a lot of direct and indirect pressure on people charged with violating the agreement and, in the rare case where someone has stood up to the pressure, of cutting their losses and settling out of court. -- Raul - 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 wrote: >>David Schwartz <[EMAIL PROTECTED]> wrote: If you buy a >>W*nd*ws install CD, you can create a derived work, e.g. an >>image of your installation, under the fair use rights >>(IANAL). Can you distribute that image freely? >> > >I would say that if not for the EULA, you could >transfer ownership of the image to someone else. And if you >legally acquired two copies of Windows, you could install >both of them and transfer them. Otherwise, you could not sell >a machine with the Windows OS installed unless you were a >Microsoft OEM. Does Microsoft take the position that if you >want to sell your PC, you must wipe the OS? Not that I know >of. > >DS If you will keep your copy and registration # of windows, yes, you *must* wipe out the machine before selling it. The point is moot, anyway, because the image is *not* a derivative work: It is a copy of the work, made by automated and automatable processes. It's not a creation of the spirit. So, no, when you get a WinXP CD from Microsoft, you have absolutely *no* rights to create derivative works. If a person creates a derivative work, even if it does not distribute it, it would be infringing on MS's copyrights and I would not want to be in said person's shoes, if someone in the legal department of MS wakes up in the wrong side of the bed. HTH, Massa - 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 <[EMAIL PROTECTED]> wrote: > > >>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. > If you buy a W*nd*ws install CD, you can create a derived work, > e.g. an image > of your installation, under the fair use rights (IANAL). Can you > distribute > that image freely? I would say that if not for the EULA, you could transfer ownership of the image to someone else. And if you legally acquired two copies of Windows, you could install both of them and transfer them. Otherwise, you could not sell a machine with the Windows OS installed unless you were a Microsoft OEM. Does Microsoft take the position that if you want to sell your PC, you must wipe the OS? Not that I know of. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, 12 Apr 2005, Sven Luther wrote: On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote: Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. The main problem is that i feel that those binary firmware copyright holders may have put it under the GPL, but i doubt they realize that this means they have to release the source code of said firmware blobs. They released it not in object format, but in the C language. An hexstring, agreed, but still C. The copyright holders can release their work how they please. If you think GPL can place restrictions on what they can do, please see below. Also, i believe you are wrong in the above, the only interpretation that is important is the one the judge will take in case someone goes to suing. Agreed, let me rephrase then. The only interpretation that is important _to the judge_ is the one of the parties involved. In any agreement, the parties express their will. Here, the holders "wrote" the agreement alone, so _their_ interpretation counts. That is, their interpretation as it was when they licenced the software. Not as is it after later thinking (or acquisition by some bad guy). And finally, if anyone could claim that a binary is the prefered form of modification, which is most of the time obviously false, then the GPL would be worthless. And anyway, the GPL states this (first paragraph after subclause c in clause 3) : I don't care about GPL being worthless. This is not the GPL advocacy list. I'm just saying that if you distribute the source in the form the author published it, you can't be sued by him for breaking GPL. That's what any linux distro and its mirrors are doing. The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. So, this is not some interpretation of the GPL by the FSF, and since it is written black on white in the actual GPL text, i don't think there is any doubt what a judge will decice : judge : so, to create this piece of work, what do you use to make modifications ? A (having sworn on the bible to say the truth and only the truth) : euh, some C or asm code, and a compiler or assembler to compile it. judge : and you did voluntarily place said code and distribute it under the GPL ? A : yes, it was going into the linux kernel, so ... judge : so you should distribute the source code to your work also, and distributing it under GPL is a breach of expectation from whoever you distribute it to. Or something such. Again, I'm not following. The author release the source under GPL. You can't release a binary under GPL, it makes no sense. So there's no "so you should distribute the source code to your work _also_". You released a software, it the form you claimed to be the source. You like LISP, you release it in LISP. You like C, you release it in C. You like hexcode, you release it in hexcode. No one can ask you to change it. You seems to keep forgetting what GPL is. It's a licence. The copyright holders grant some rights to third parties, _if_ they comply to some conditions. Conditions are all placed on the third parties, including the source disclosure one (source of _modifications_). There is no condition the _holders_ have to meet. It'd be a nonsense. The GPL says: "I grant you a right if you do this." and not: "I grant you a right if _I_ do this.". GPL doesn't backfire. Again, IANAL, but I see little room for "interpretation" here. If A is going to say that he is the only author, and that he would never sue because of this breach of the GPL, he could just as well have put it under a different licence, or put a small disclaimer about it, since we cannot really act as if we believed that A would never sue us, if he doesn't explicitly say so. No one will ever do that. If you are distributing the software I released under GPL, be sure I _will_ sue you if you break the licence. What do you want from me? A promise I won't sue you if you don't? That is implicit in the existance of the licence. Are you implying debian will stop distributing _any_ software unless the all the copyright holders of GPL software "explicitly say" they won't sue you? As an example, i package the unicorn driver for the bewan soft-ADSL pci and usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL emulating library, but are otherwise GPL, i discussed the matter with upstream, and after council from debian-legal, and possibly the FSF people themselves, we got to use this as GPL exception : In addition, as a special exception, BeWAN systems gives perm
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz wrote: 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. The only way to *create* a derivative work is with permission of the copyright owner of the original work. Period. This permission can come implicitly *if* you agree with licensing terms, but not under first sale or fair use *limitations*. (First sale / fair use are statutory limitations on copyrights, not rights). Massa - 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 <[EMAIL PROTECTED]> wrote: >>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. If you buy a W*nd*ws install CD, you can create a derived work, e.g. an image of your installation, under the fair use rights (IANAL). Can you distribute that image freely? -- Friendly fire isn't. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - 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.
On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote: > Which reminds me. The only reason why this thread belongs here, IMHO, > it's because when it comes to GPL, it really doesn't matter what > FSF's interpretation is, or anyone else's. The authors are choosing > GPL as a license, so _thier_ interpretation is what really matters. The main problem is that i feel that those binary firmware copyright holders may have put it under the GPL, but i doubt they realize that this means they have to release the source code of said firmware blobs. Also, i believe you are wrong in the above, the only interpretation that is important is the one the judge will take in case someone goes to suing. And finally, if anyone could claim that a binary is the prefered form of modification, which is most of the time obviously false, then the GPL would be worthless. And anyway, the GPL states this (first paragraph after subclause c in clause 3) : The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. So, this is not some interpretation of the GPL by the FSF, and since it is written black on white in the actual GPL text, i don't think there is any doubt what a judge will decice : judge : so, to create this piece of work, what do you use to make modifications ? A (having sworn on the bible to say the truth and only the truth) : euh, some C or asm code, and a compiler or assembler to compile it. judge : and you did voluntarily place said code and distribute it under the GPL ? A : yes, it was going into the linux kernel, so ... judge : so you should distribute the source code to your work also, and distributing it under GPL is a breach of expectation from whoever you distribute it to. Or something such. If A is going to say that he is the only author, and that he would never sue because of this breach of the GPL, he could just as well have put it under a different licence, or put a small disclaimer about it, since we cannot really act as if we believed that A would never sue us, if he doesn't explicitly say so. As an example, i package the unicorn driver for the bewan soft-ADSL pci and usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL emulating library, but are otherwise GPL, i discussed the matter with upstream, and after council from debian-legal, and possibly the FSF people themselves, we got to use this as GPL exception : In addition, as a special exception, BeWAN systems gives permission to link the code of this program with the modem SW library (modem_ant_PCI.o, modem_ant_USB.o), and distribute linked combinations including the two. You are also given permission to redistribute the modem SW library (modem_ant_PCI.o, modem_ant_USB.o) with the rest of the code. You must obey the GNU General Public License in all respects for all of the code used other than the modem SW library. So, really, i doubt any manufacturer distributing non-free firmware would really have trouble in adding to their licence something like this : In addition, , considers the firmware blob, identified as <...>, as a non-derivative piece of work, and thus not covered by the GPL of the rest of it. gives permission to distribute said firmware blob as part of the linux kernel module driver for their hardware. The actual syntax of the inclusion of the code is still covered by the GPL, as is the rest of the driver code. If we where to get something as nicely pu as this, provide a patch, asking the manufacturer to sign it of, then all issues would be void, i believe. > >>says so and it's A granting D the right to distribute. There's no way C > >>can prevent D from distributing A's software, if A is fine with it. > >>It's up to A to decide if GPL conditions are met by D. > > > >Even in that case, you still need explicit permission of A, and all the > >other > >copyright holders of the rest of the GPLed work, to give you an explicit > >exception to link with this non-free bit of code. > > Yes, but it does not apply to our case here. There's no "all other > copyright holders". _You_ stated that the firmware is included by mere > aggregation, so there's no other holders involved. We're talking > about the firmware case. A is one or two well identified subjects. > And A wrote it is GPL'ed. Whether you agree or not, that's the licence > A chose. A placed the copyright notice. This is where i would need legal counsel, as to whether this means C or someone else may stop you from distributing unless you provide the source. And the real problem is that A didn't state anything, so we are only working on the assumption that this may be the case, and A can change its mind later, and the costs to defe
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005, Sven Luther wrote: On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote: In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. Well, i am not sure with your interpretation, but even if you where right, we have no guarantee that A will continue being lenient, and no guarantee that A will not start suing D or whoever for illegally distributing his stuff without sources. Let's keep things separated. I'm saying that the only one that may sue D is A, not C. If we agree on this, we may abandon the case of a third party sueing D. As for threats coming from A, IMHO D is safe as long as he distributes what A claims the source is, even if it's a hex string. In no world A can publicly state "this is the source" and then sue D because "no, that's not the source" (assuming D is copying it verbatim). So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A So, i get some random bit of GPLed software, i add a module or some code to it, i distribute that code in binary format only, and claim that i have used an hex editor to write it, or simply that it is the 'right' source. I have some serious doubts that i will not get sued by all the authors of the original GPLed work if i were to do that, and rightly so. No. Please don't throw irrelevant matters in. D is not modifing the software at all. D is a mere distributor. We're not addressing issues related to modification, since no one is going to modify the firmware anyway. This is not a general discussion on GPL. Issues related to modification do not belong to this thread, which already very close to off topic on l-k. Which reminds me. The only reason why this thread belongs here, IMHO, it's because when it comes to GPL, it really doesn't matter what FSF's interpretation is, or anyone else's. The authors are choosing GPL as a license, so _thier_ interpretation is what really matters. says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Even in that case, you still need explicit permission of A, and all the other copyright holders of the rest of the GPLed work, to give you an explicit exception to link with this non-free bit of code. Yes, but it does not apply to our case here. There's no "all other copyright holders". _You_ stated that the firmware is included by mere aggregation, so there's no other holders involved. We're talking about the firmware case. A is one or two well identified subjects. And A wrote it is GPL'ed. Whether you agree or not, that's the licence A chose. A placed the copyright notice. The licence is a matter between A and D. A may sue D and D may (less likely) sue A, if conditions are not met. I'm not sure at all GPL is enforceable by D upon A. Let's assume it is, for sake of discussion, anyway. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. No. The source code is clearly the prefered form of modification, not some random intermediate state A may be claiming is source. In this context, it is. Only A may sue D for not distributing the source. Whatever D distributes, D has to make A happy. If A is happy with D distributing `dd if=/dev/random count=1` as source, no one can stop D from doing that. Keep in mind A is the copyright holder. He grants rights to third parties. No one but A can remove them. [...] I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in t
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote: > In this case, A is clearly the author (onwer of rights) of the firmware. > D is fine on respect of the other A's, since their source is actually > (and clearly) there. It's the missing source case we're considering > and the number of A's is quite small, the copyright owners of firmware > images. Those A's are easily identified, and perfectly able to act. Well, i am not sure with your interpretation, but even if you where right, we have no guarantee that A will continue being lenient, and no guarantee that A will not start suing D or whoever for illegally distributing his stuff without sources. > > > So, even if C comes to think D is breaking GPL, all C can do is notify > > > A. The GPL D is supposedly breaking is an agreement between A and D > > > only. On which basis may C sue D? For breaking what agreement? It's up > > > to A to sue D for breaking GPL. > > > > This is indeed an interpretation. I am not sure myself if a user receiving > > GPLed software in binary only fashion as is the case here can sue either D > > or > > A to get access to that source code. > > The point is, if A states (even implicitly) D is distributing the right > source, there's nothing C can do to D. D is not breaking GPL, as long A So, i get some random bit of GPLed software, i add a module or some code to it, i distribute that code in binary format only, and claim that i have used an hex editor to write it, or simply that it is the 'right' source. I have some serious doubts that i will not get sued by all the authors of the original GPLed work if i were to do that, and rightly so. > says so and it's A granting D the right to distribute. There's no way C > can prevent D from distributing A's software, if A is fine with it. > It's up to A to decide if GPL conditions are met by D. Even in that case, you still need explicit permission of A, and all the other copyright holders of the rest of the GPLed work, to give you an explicit exception to link with this non-free bit of code. > Maybe mine it's only one interpretation. But I can't see any other. > > > Now you could argue that any number of authors of GPLed bits of the linux > > kernel could sue D for distributing their software as a derived work of the > > binary-only bit, and the fact that D doesn't distribute the source code to > > the > > binary bit voids any other right allowed him by the GPL, and thus he has no > > right to do the distribution at all. The GPL is very clear on this topic. > > We're not talking of that case. D _is_ actually distributing the right > source, according to A. It's C that is unsatisfied with it. No. The source code is clearly the prefered form of modification, not some random intermediate state A may be claiming is source. > > > What is the risk for D, if D is distributing the source of the software > > > _exactly_ in the form A publicly provides it? It's not up to D to > > > produce the source, all D has to do is to provide verbatim copies of > > > it to anyone D distributes the software to, on request. > > > > Imagine one of those companies got bought up by some predatory company who > > wishes us (linux, debian, redhat/suse, whoever) harm. They would then be > > able > > to sue for damage or prejudice or whatever. And given what i have heard > > about > > the uncertainities of the Alteon ownership, this seems indeed like a > > plausible > > scenario, which could result in a SCO bis case. > > I'm not following. Are you saying what if A is bought? That is > different. Well GPL is quite clear: > > 1. You may copy and distribute verbatim copies of the Program's source > code as you receive it, ... > > If D is distributing the source as received from A, D is in full > compliance. How could A sue D? If A distributed incomplete source > in the first place, it's not D's fault for sure. Do you really think > the following scenario is likely: > > A to D: you must distribute the complete source, or the license will be > terminated! > D to A: gimme the complete source, and I'll distribute it. > A to D: no, I'm not willing to give you the full source of my firmware, > but you must distribute it anyway! The result is that the code in question has to be stopped from being distributed by D. But the case here is different, since A is not the sole copyright owner, so he doesn't get to set random interpretations of what is source code. > That, in court? Is this really what you're afraid of? > The outcome is, very likely A will be forced to release the full source. > (and D forced to distribute it, but all D's we're talking of here are > very happy with the full disclosure scenario, aren't they?) Imagine A refusing to give away the source code, and D is ordered to remove the incriminated code it is illegally distributing from all its servers, and recall all those thousands of CD and DVD isos containing the code it distributed, and being fined for each day it
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 2005-04-11 at 18:25 +0200, Sven Luther wrote: > On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote: [...] > > A - is the Author (or rights owner) of the software (GPL'ed); > > B - is an user, who got the a copy of the software from A; > > C - is another user, who got a copy indirectly, that is from a > > distributor; > > D - is the distributor C got the copy from. [...] > > Now. It seems to me that the relationship between D (distributor) and C > > (target of the distribution) is _not_ regulated by GPL at all. GPL is a > > license, the _owner_ of the rights (A) and the recipient of some rights > > (C, as an user) are the only subjects. D _owns_ no rights on the > > software, so can't grant any to C. There's no GPL between D and C. > > I think you are missing the point. D get's a licence from A, the GPL, and this > licence includes a licence, not on use, but on redistribution, and the act of > D distributing the copy to C is covered by it. In a sense A allows D to > distribute the software under the GPL to C. Now, D is only allowed to do this > distribution if he also distribute the source code of it, which he can't do > for the firmware. I think only a lawyer can answer here. What I'm saying is that the license always comes from the copyright owner, that is A. Sublicensing is not covered by GPL. Distribution is not sublicensing. Quoting GPL itself: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. ... The wording is clear, the license is between A and C. There's no license between D and C. There's no way C can enforce anything on D (well, not on GPL basis). > Notice also the fact that there are so many contributors to the linux kernel > in effect means that there is nobody with the full rights as A, but only a > multitude of people in the D case. In this case, A is clearly the author (onwer of rights) of the firmware. D is fine on respect of the other A's, since their source is actually (and clearly) there. It's the missing source case we're considering and the number of A's is quite small, the copyright owners of firmware images. Those A's are easily identified, and perfectly able to act. > > So, even if C comes to think D is breaking GPL, all C can do is notify > > A. The GPL D is supposedly breaking is an agreement between A and D > > only. On which basis may C sue D? For breaking what agreement? It's up > > to A to sue D for breaking GPL. > > This is indeed an interpretation. I am not sure myself if a user receiving > GPLed software in binary only fashion as is the case here can sue either D or > A to get access to that source code. The point is, if A states (even implicitly) D is distributing the right source, there's nothing C can do to D. D is not breaking GPL, as long A says so and it's A granting D the right to distribute. There's no way C can prevent D from distributing A's software, if A is fine with it. It's up to A to decide if GPL conditions are met by D. Maybe mine it's only one interpretation. But I can't see any other. > Now you could argue that any number of authors of GPLed bits of the linux > kernel could sue D for distributing their software as a derived work of the > binary-only bit, and the fact that D doesn't distribute the source code to the > binary bit voids any other right allowed him by the GPL, and thus he has no > right to do the distribution at all. The GPL is very clear on this topic. We're not talking of that case. D _is_ actually distributing the right source, according to A. It's C that is unsatisfied with it. > > What is the risk for D, if D is distributing the source of the software > > _exactly_ in the form A publicly provides it? It's not up to D to > > produce the source, all D has to do is to provide verbatim copies of > > it to anyone D distributes the software to, on request. > > Imagine one of those companies got bought up by some predatory company who > wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able > to sue for damage or prejudice or whatever. And given what i have heard about > the uncertainities of the Alteon ownership, this seems indeed like a plausible > scenario, which could result in a SCO bis case. I'm not following. Are you saying what if A is bought? That is different. Well GPL is quite clear: 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, ... If D is distributing the source as received from A, D is in full compliance. How could A sue D? If A distributed incomplete source in the first place, it's not D's fault for sure. Do you really think the following scenario is likely: A to D: you must distribute the complete source, or the license will be terminated! D to A: gimme the complete source, and I'll distribute it. A to D: no, I'm not willing t
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 11:24:10AM +0200, Giuseppe Bilotta wrote: > 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. This point is a controversial point. Different people make different claims. For example, http://www.answers.com/software -- the Computer Desktop Encyclopedia asserts that you are correct, while Wikipedia asserts that you are incorrect. The American Heritage Dictionary implies you are correct, and WordNet implies that you're incorrect. Usage is still evolving, so who knows where this issue will stand in five years. In the context of the linux kernel (which I presume you're talking about, given the message headers), I don't think it's plausible to suggest that the occasional use of the term "software" in the license means that the stuff under Documentation/ isn't covered by the license. -- Raul - 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.
On Mon, Apr 11, 2005 at 12:31:53PM -0700, David Schwartz wrote: > Perhaps you could cite the law that restricts to the copyright > holder the right to restrict the distribution of derivative works. I can > cite the laws that restrict all those other things and clearly *don't* > mention distribution of derivative works. 17 USC 103 17 USC 106 -- Raul - 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.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, 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. While you are may be reporting your thoughts accurately, this problem doesn't seem to be a legal issue. The GPL explicitly discusses this issue (section 5), and a number of people have already posted with similar commentary. Anyways, one thing to keep in mind here is that if copyright law doesn't allow the GPL's grant of permission to be conditional then copyright law would not allow other copyright grants to be conditional. Another way of looking at this is that the GPL is a copyright license -- it represents the terms and conditions under which copyrights are granted, and it also represents those permissions. -- Raul - 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.
> > 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). Perhaps you could cite the law that restricts to the copyright holder the right to restrict the distribution of derivative works. I can cite the laws that restrict all those other things and clearly *don't* mention distribution of derivative works. [from another post] >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. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote: > [I'm not subscribed, so this in not a real reply - sorry if it breaks > threading somehow.] > > Sven Luther wrote: > > The ftp-master are the ones reviewing the licencing problems, and they > are the > > ones handling the infrastructure, and putting their responsability on the > > stake. If they feel that some piece of software has dubious legal issues > > which > > come at a risk of having them personally come on the receiving end of a > > legal > > case, then they will say, no, we don't distribute this software, and that is > > the end of it. > > I've been following the whole discussion (including later messages), > but I'm still missing one point. You seem to have investigated a lot > on the subject, so I'll ask you. I don't get what real legal issues > distributors may have. > > Let me explain with an example. Lets say: > > A - is the Author (or rights owner) of the software (GPL'ed); > B - is an user, who got the a copy of the software from A; > C - is another user, who got a copy indirectly, that is from a > distributor; > D - is the distributor C got the copy from. > > Now, IANAL at all. But it seems to me that B has the right to _use_ the > software by means of GPL. As long as A thinks B doesn't break GPL, B is > fine. All B needs to do is to fulfill GPL conditions (as a user, there's > little to do). > > C also has the right to use the software, in a very similar way. As long > as A thinks C doesn't break GPL, C is fine. > > D has the right to distribute the software, under GPL terms. As long as > A thinks D doesn't break GPL, D is fine. > > Now. It seems to me that the relationship between D (distributor) and C > (target of the distribution) is _not_ regulated by GPL at all. GPL is a > license, the _owner_ of the rights (A) and the recipient of some rights > (C, as an user) are the only subjects. D _owns_ no rights on the > software, so can't grant any to C. There's no GPL between D and C. I think you are missing the point. D get's a licence from A, the GPL, and this licence includes a licence, not on use, but on redistribution, and the act of D distributing the copy to C is covered by it. In a sense A allows D to distribute the software under the GPL to C. Now, D is only allowed to do this distribution if he also distribute the source code of it, which he can't do for the firmware. Notice also the fact that there are so many contributors to the linux kernel in effect means that there is nobody with the full rights as A, but only a multitude of people in the D case. > So, even if C comes to think D is breaking GPL, all C can do is notify > A. The GPL D is supposedly breaking is an agreement between A and D > only. On which basis may C sue D? For breaking what agreement? It's up > to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. > What is the risk for D, if D is distributing the source of the software > _exactly_ in the form A publicly provides it? It's not up to D to > produce the source, all D has to do is to provide verbatim copies of > it to anyone D distributes the software to, on request. Imagine one of those companies got bought up by some predatory company who wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able to sue for damage or prejudice or whatever. And given what i have heard about the uncertainities of the Alteon ownership, this seems indeed like a plausible scenario, which could result in a SCO bis case. This is the scenario i want to avoid by explicitly stating the relationships of all copyright issues of those firmware blobs. > Does is really matter if C thinks the source being incomplete, > or missing? C can take the issue up with A (by means of the GPL that > exists between A and C), but not with D, since there's no GPL between > D and C. C is in the same position of B. If the source is incomplete, > they may ask A to comply to the GPL, but not D. D made no promises to > them. /me wonders if C then holds an illegal copy of the software, and can then be prosecuted for piracy :) Friendly, Sven Luther - 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.
[I'm not subscribed, so this in not a real reply - sorry if it breaks threading somehow.] Sven Luther wrote: > The ftp-master are the ones reviewing the licencing problems, and they are the > ones handling the infrastructure, and putting their responsability on the > stake. If they feel that some piece of software has dubious legal issues which > come at a risk of having them personally come on the receiving end of a legal > case, then they will say, no, we don't distribute this software, and that is > the end of it. I've been following the whole discussion (including later messages), but I'm still missing one point. You seem to have investigated a lot on the subject, so I'll ask you. I don't get what real legal issues distributors may have. Let me explain with an example. Lets say: A - is the Author (or rights owner) of the software (GPL'ed); B - is an user, who got the a copy of the software from A; C - is another user, who got a copy indirectly, that is from a distributor; D - is the distributor C got the copy from. Now, IANAL at all. But it seems to me that B has the right to _use_ the software by means of GPL. As long as A thinks B doesn't break GPL, B is fine. All B needs to do is to fulfill GPL conditions (as a user, there's little to do). C also has the right to use the software, in a very similar way. As long as A thinks C doesn't break GPL, C is fine. D has the right to distribute the software, under GPL terms. As long as A thinks D doesn't break GPL, D is fine. Now. It seems to me that the relationship between D (distributor) and C (target of the distribution) is _not_ regulated by GPL at all. GPL is a license, the _owner_ of the rights (A) and the recipient of some rights (C, as an user) are the only subjects. D _owns_ no rights on the software, so can't grant any to C. There's no GPL between D and C. So, even if C comes to think D is breaking GPL, all C can do is notify A. The GPL D is supposedly breaking is an agreement between A and D only. On which basis may C sue D? For breaking what agreement? It's up to A to sue D for breaking GPL. What is the risk for D, if D is distributing the source of the software _exactly_ in the form A publicly provides it? It's not up to D to produce the source, all D has to do is to provide verbatim copies of it to anyone D distributes the software to, on request. Does is really matter if C thinks the source being incomplete, or missing? C can take the issue up with A (by means of the GPL that exists between A and C), but not with D, since there's no GPL between D and C. C is in the same position of B. If the source is incomplete, they may ask A to comply to the GPL, but not D. D made no promises to them. So, as long as they don't modify the source, distributors are safe. No one can ask them to provide the "right" source, but A. And "right" means "right for A", of course, when it's A asking, by definition. What am I missing? TIA, .TM. - 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.
Michael Poole wrote: 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 Conceded. Altough .br's "computer programs" law explicitly says that you can reserve, in a license to create derivative works, all the rights over the derivative works. Massa - 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 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). HTH, Massa - 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.
Giuseppe Bilotta wrote: 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. AFAIK "software" is just the complementary concept of "hardware". Hardware is hard, ie, the parts of anything you can touch. Software is the *information* part of anything. In the case of a table, hardware are the wood, nails, nuts and bolts that make the table and software is the design of the table, the recipy of the resin used to coat it, etc. In the case of a computer, hardware is the boards, case, monitor and software is all the information used to make the thing work, including all programs and all data contained in it. [] Massa - 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.
Adrian Bunk wrote: Even RedHat with a stronger financial background than Debian considered the MP3 patents being serious enough to remove MP3 support. Actually, they did it to spite the patent holders. []s Massa - 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.
Glenn Maynard wrote: I've heard the claim, several times, that that creating a derivative work requires creative input, that linking stuff together with "ld" is completely uncreative, therefore no derivative work is created. (I'm not sure if you're making (here or elsewhere) that claim, but it seems like it.) What's the basis for this claim? (If you're not making it, anybody that does believe this is free to respond.) It's based on Title 17 USC, Sec. 101, where "derivative work" is defined: A âderivative workâ is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an ORIGINAL WORK OF AUTHORSHIP, is a âderivative workâ. (emphasis added) - 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.
> 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 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.
> > 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 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.
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 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.
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!" - 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.
> 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 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.
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 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.
(Henning Makholm, I assume; I seem to be missing the actual message and David's mailer forgot to put a quote header on the original reply): > > >> 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 The two parts are not derivatives of each other, of course; that's obvious. (If I take your firmware, David's firmware loader, and link them together, I havn't change either of your works.) The resulting linked binary, however, is a derivative work of both. I've heard the claim, several times, that that creating a derivative work requires creative input, that linking stuff together with "ld" is completely uncreative, therefore no derivative work is created. (I'm not sure if you're making (here or elsewhere) that claim, but it seems like it.) What's the basis for this claim? (If you're not making it, anybody that does believe this is free to respond.) The case David referred to[1] says "A derivative work may itself be copyrighted if it has the requisite originality." This seems to imply that something can be a derivative work without creative input (though no new copyright would exist beyond that of the source objects). It seems that while "creative input" is required for copyright to exist, it is not required for creating a derivative work. [1] http://caselaw.lp.findlaw.com/data2/circs/8th/033112p.pdf 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. 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. (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.) -- Glenn Maynard - 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.
> Scripsit "David Schwartz" <[EMAIL PROTECTED]> > >> 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. > > If the thing distributed is not the covered work and not a > > derivative work, why does the GPL apply to it at all? > You are free to not apply the GPL to it. > 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. 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 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. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > It's impossible to treat patents consistently. On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote: > Even RedHat with a stronger financial background than Debian considered > the MP3 patents being serious enough to remove MP3 support. It's silly to treat financial risk as being a one dimensional quantity. It could easily be that Red Hat decided that the mp3 patent owners would be going after people with deep pockets. If this is the risk model, Red Hat's risk would be much much higher than Debian's. > Note that this is a respose to Josselin's statement: > < When there are several possible interpretations, you have to pick up the < more conservative one, as it's not up to us to make the interpretation, < but to a court. Sure, if you have several plausible interpretations, you pick the one you feel is likely to be the most important, and if all of them seem likely you pick the one that seems worst. But, ultimately, you can't treat software patents consistently. There's no reasonable way to do so. > It's simply silly to be extremely picky on copyright issues while being > extremely liberal on patent issues - the risk of a Debian distributor > being sued for patent violations (no matter how the lawsuit might end) > is definitely present. Anything to do with software patents is silly. Being liberal about software patents is silly. Being conservative about software patents is silly. Copyright, while far from perfect, can at least be reasoned about. > > As for this particular patent, I'm not really sure what's being patented. > >... > Which one of the 23 patents they list do you call "this particular > patent"? What makes you think I'm sure about what's being patented in 22 of those patents? I should probably have said "As for patent claims applying to mp3, ...", but the issue is thorny enough that even that might not have been accurate enough. But, treating "this particular patent" as a meta-syntactic variable should be adequate for you to understand what I was saying. Bottom line, though: softare patents generally make very little sense. -- Raul - 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.
On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote: > On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: > > If Debian was at least consistent. > > > > Why has Debian a much more liberal interpretation of MP3 patent issues > > than RedHat? > > It's impossible to treat patents consistently. > > The U.S. patent office, at least, has granted patents on natural laws, > on stuff that's already patented, on stuff with clear prior art, on > trivial math operations and so on. Patents are being granted so quickly > there's no way of even knowing what's patented. > > Or were you hoping that Debian would follow Red Hat's lead? Even RedHat with a stronger financial background than Debian considered the MP3 patents being serious enough to remove MP3 support. Yes, Debian can choose to put a higher risk on their distributors and mirrors - there's nothing wrong with this. Note that this is a respose to Josselin's statement: <-- snip --> When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. <-- snip --> It's simply silly to be extremely picky on copyright issues while being extremely liberal on patent issues - the risk of a Debian distributor being sued for patent violations (no matter how the lawsuit might end) is definitely present. > As for this particular patent, I'm not really sure what's being patented. >... Which one of the 23 patents they list do you call "this particular patent"? > Raul cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> >> 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. > If the thing distributed is not the covered work and not a > derivative work, why does the GPL apply to it at all? You are free to not apply the GPL to it. However, then you cannot legally copy it at all, because it contains part of the original author's copyrightedwork and therefore can only legally be copied with the permission of the author. -- Henning Makholm "The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning." - 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.
On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: > If Debian was at least consistent. > > Why has Debian a much more liberal interpretation of MP3 patent issues > than RedHat? It's impossible to treat patents consistently. The U.S. patent office, at least, has granted patents on natural laws, on stuff that's already patented, on stuff with clear prior art, on trivial math operations and so on. Patents are being granted so quickly there's no way of even knowing what's patented. Or were you hoping that Debian would follow Red Hat's lead? As for this particular patent, I'm not really sure what's being patented. Trial and error? Spectral quantization? The specific data format? Addition, multiplication, and exponentiation? In many respects, mp3 is similar to jpeg. Does that mean that any use of the techniques used by jpeg in the domain of audio is covered by this patent? Does that mean that jpeg is in violation of this patent? If I use the same kind of math with a time dimension, am I violating some other mpeg patents? What about the other hundreds of thousands of patents? How many of them am I violating when I use lossy compression based on spectral quantization? -- Raul - 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.
> 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. If the thing distributed is not the covered work and not a derivative work, why does the GPL apply to it at all? DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Adrian Bunk <[EMAIL PROTECTED]> writes: > On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote: >> Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit : >> GFDL documentation will still be available in the non-free archive. > > Assuming you have an online connection and a friend told you how to > manually edit your /etc/apt/sources.list for non-free. You *do* know that current versions of the installer ask you if you want non-free, don't you? > But where's the documentation if you don't have an online connection but > only the dozen binary CDs of Debian? Clearly, since the judgement is "it can't be legally distributed as part of a package of Debian CD's", it isn't on a package of Debian CD's. cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml - 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.
Le vendredi 08 avril 2005 Ã 20:01 +0200, Adrian Bunk a Ãcrit : > > Because we already know that patents on MP3 decoders are not > > enforceable. Furthermore, the holders of these patents have repeatedly > > How do you know the patents aren't enforceable? Because decoding a MP3 is a trivial operation. > > stated they won't ask for fees on MP3 decoders. > > http://www.mp3licensing.com/royalty/index.html > > talks about 0.75 Dollar for a decoder. I can't find the reference, but IIRC it was stated later that they don't want to apply this to free (as in beer) software. > > > Documentation is "software"? > > > > Sure. > > Every book in my book shelf is software? If you digitalize it, yes. > That doesn't match how people outside of Debian use the word "software". When we tried to define what is "software", the only acceptable definitions we found were things like "every kind of numeric stuff" or "everything that can be included in Debian". You can try to come up with your own, you'll see it's not that easy. > > GFDL documentation will still be available in the non-free archive. > > Assuming you have an online connection and a friend told you how to > manually edit your /etc/apt/sources.list for non-free. > > But where's the documentation if you don't have an online connection but > only the dozen binary CDs of Debian? Without the GFDL documentation, you'll have the right to lock the room in which you put the CDs. The GFDL forbids that, because you'd be "using technical measures to obstruct further copying" of the documentations. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote: > Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit : > > > When there are several possible interpretations, you have to pick up the > > > more conservative one, as it's not up to us to make the interpretation, > > > but to a court. > > > > If Debian was at least consistent. > > > > Why has Debian a much more liberal interpretation of MP3 patent issues > > than RedHat? > > Because we already know that patents on MP3 decoders are not > enforceable. Furthermore, the holders of these patents have repeatedly How do you know the patents aren't enforceable? > stated they won't ask for fees on MP3 decoders. http://www.mp3licensing.com/royalty/index.html talks about 0.75 Dollar for a decoder. > > How do you install Debian on a harddisk behind a SCSI controller who's > > driver was removed from the Debian kernels due to it's firmware? > > Which SCSI controller are you talking about? Quoting README.Debian of the Debian kernel sources: <-- snip --> * QLA2XXX firmware, driver disabled: . drivers/scsi/qla2xxx/*_fw.c <-- snip --> There are a few other SCSI controllers where even the Debian kernel sources still ship both the drivers and the firmware. I do not claim to understand the latter... > > > Being careless in the definition of "free software" is a real disservice > > > to users. It makes them rely on e.g. non-free documentation for everyday > > > use. > > >... > > > > Documentation is "software"? > > Sure. Every book in my book shelf is software? That doesn't match how people outside of Debian use the word "software". > > Non-free documentation is better than no documentation. > > > > Non-free software has several problems, but some of them like the right > > to do modifications are less important for documentation, since e.g. > > fixes for security bugs are not an issue. > > > > Removing the available documentation without an equal replacement is a > > real disserve for your users. > > GFDL documentation will still be available in the non-free archive. Assuming you have an online connection and a friend told you how to manually edit your /etc/apt/sources.list for non-free. But where's the documentation if you don't have an online connection but only the dozen binary CDs of Debian? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
Le vendredi 08 avril 2005 Ã 19:34 +0200, Adrian Bunk a Ãcrit : > > When there are several possible interpretations, you have to pick up the > > more conservative one, as it's not up to us to make the interpretation, > > but to a court. > > If Debian was at least consistent. > > Why has Debian a much more liberal interpretation of MP3 patent issues > than RedHat? Because we already know that patents on MP3 decoders are not enforceable. Furthermore, the holders of these patents have repeatedly stated they won't ask for fees on MP3 decoders. > How do you install Debian on a harddisk behind a SCSI controller who's > driver was removed from the Debian kernels due to it's firmware? Which SCSI controller are you talking about? > > Being careless in the definition of "free software" is a real disservice > > to users. It makes them rely on e.g. non-free documentation for everyday > > use. > >... > > Documentation is "software"? Sure. > Non-free documentation is better than no documentation. > > Non-free software has several problems, but some of them like the right > to do modifications are less important for documentation, since e.g. > fixes for security bugs are not an issue. > > Removing the available documentation without an equal replacement is a > real disserve for your users. GFDL documentation will still be available in the non-free archive. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 09:22:00AM +0200, Josselin Mouette wrote: > Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit : > > > You are mixing apples and oranges. The fact that the GFDL sucks has > > > nothing to do with the firmware issue. With the current situation of > > > firmwares in the kernel, it is illegal to redistribute binary images of > > > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > > > be willing to distribute such binary images, but it isn't our problem. > > > > It's a grey area. > > > > debian-legal did pick one of the possible opinions on this matter. > > When there are several possible interpretations, you have to pick up the > more conservative one, as it's not up to us to make the interpretation, > but to a court. If Debian was at least consistent. Why has Debian a much more liberal interpretation of MP3 patent issues than RedHat? >... > Instead of babbling, some people have started to discuss this with > upstream, and are trying to come up with a GPLed documentation for GCC. > This is much more constructive than repeating again and again "Bleh, > Debian are a bunch of bigots who don't care of the compiler being > documented." Will the replacement documentation for all affected software be available before the GFDL documentation gets removed? At least theoretically, the users are a priority for Debian equally to free software. > > Is it true, that Debian will leave users with hardware affected by the > > firmware problem without a working installer in Debian 3.1? > > The case of hardware really needing a firwmare to work *and* needed at > installation time is rare. I've only heard of some tg3-based cards. Most > of them will work without the firmware, and for the few remaining ones, > it only means network installation won't work. How do you install Debian on a harddisk behind a SCSI controller who's driver was removed from the Debian kernels due to it's firmware? > > The point is simply, that Debian does more and more look dogmatic at > > it's definition of "free software" without caring about the effects to > > it's users. > > Being careless in the definition of "free software" is a real disservice > to users. It makes them rely on e.g. non-free documentation for everyday > use. >... Documentation is "software"? Non-free documentation is better than no documentation. Non-free software has several problems, but some of them like the right to do modifications are less important for documentation, since e.g. fixes for security bugs are not an issue. Removing the available documentation without an equal replacement is a real disserve for your users. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
On Fri, Apr 08, 2005 at 08:54:40AM +0200, Sven Luther wrote: > On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote: > > On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: > > > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: > > >... > > > > If your statement was true that Debian must take more care regarding > > > > legal risks than commercial distributions, can you explain why Debian > > > > exposes the legal risks of distributing software capable of decoding > > > > MP3's to all of it's mirrors? > > > > > > I don't know and don't really care. I don't maintain any mp3 player (err, > > > actually i do, i package quark, but use it mostly to play .oggs, maybe i > > > should think twice about this now that you made me aware of it), but in > > > any > > > case, i am part of the debian kernel maintainer team, and as such have a > > > responsability to get those packages uploaded and past the screening of > > > the > > > ftp-masters. I believe the planned solution is vastly superior to the > > > current > > > one of simply removing said firmware blobs from the drivers, which caused > > > more > > > harm than helped, which is why we are set to clarifying this for the > > > post-sarge kernels. > > > > > > Debian doesn't seem to care much about the possible legal problems of > > patents. > > patents are problematic, and upto recently there where no software patents in > europe, so i don't really care. I am not sure about the details of the above > problem you mention, could you provide me some link to the problem at hand. I http://www.mp3licensing.com/ The patent problems in the USA alone should impose enough legal risks. IANAL, but even RedHat considers them to be serious problems. And note that most of their patents are also valid in the EU. If they are enforcible is a different question, but it might be enough to become a legal risk that a lawsuit might be started against e.g. a mirror. > also believe that in the larger scheme restriction of this kind, as is the US > restriction on distribution to cuba and everything else, is not-right and even > immoral, and *I* personally would fight back if i was ever sued for such > things, and there may be higher courts involved than just the US judicial > system, which is for sale anyway, where redhat is dependent on. I cannot talk Which court is "higher ... than just the US judicial system"? If you are in the USA, there's no legal instance between the US supreme court and god. > about the whole of debian on this though, and i feel it is for someone else to > tackle and handle. If you feel strongly about this, you are free to go take it > over with whoever handles this, post to debian-legal and debian-project about > it, and help get the issue solved. > > (/me believes such restrictions of the above are a violation of the elemental > human rights to go where one wants and run what operating system on wants). >... Unfortunately, life isn't fair. It's Debian's choice how cautiously or brave they are regarding legal risks. But it has to be consistent. Debian simply needs an overall policy for this. But if you say that you want to avoid any legal risks in one area while saying "these are not my packages" about perhaps even more likely legal risks in other areas doesn't help anyone. > Friendly, > > Sven Luther cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
On Fri, Apr 08, 2005 at 09:41:35AM +0200, Sven Luther wrote: > BTW, have any of you read the analysis i made, where i claim, rooted > in the GPL FAQ and with examples, why i believe that the firmware can > be considerated a non derivative of the linux kernel. I hadn't. I did just now. Here's my opinions, after reading it: [1a] It's pretty long, and some of the redundancy is not really relevant to the issue at hand. This might be less of an issue, except [1b] It has some grammar problems that should be fixed. [2] The presented arguments all look plausible. Maybe I should study it more, but I didn't see any significant logical flaws. [3] It focuses on debian issues more than kernel issues (though a dedicated reader could see some issues relevant to the linux-kernel mailing list). I agree with both you and the gpl faq writers that "communicates at arms length" is probably a good measure of whether or not the kernel and the module are the same program. I can think of cases where this wouldn't hold (GPLed documentation, for example), but those kinds of issues don't seem to be relevant here. > I further argumented that taking any different stance would bring us worlds of > hurt as we would consider the bios as being a derivative work of the kernel > they are running, or the bootloader, or the firmware present in proms on > devices loaded into the system and so on. Here, you've confused two issues: "Are A and B part of the same program?" and "Are A and B together part of a derivative work under copyright law?" Sometimes one is true, sometimes the other is true. You have a GPL issue when both are true. One question has to do with the function of A and B. The other question is whether the combination is eligible for copyright protection. Copyright protection is not granted or denied because of functionality. The functional issues are relevant only because they're written into the license. Of course there can be other GPL issues (e.g. it's bad to put a GPL notice on something which isn't GPLed). And, of course, there can be non-GPL issues (pulling the blobs out of the kernel lets people update their firmware without having to compile the kernel or a kernel module). > I think only the fact that if you consider firmware as being a derivative > work, you should consider it a derivative work also when it is flashed on the > prom of a pci card or what not, is decisive enough to make those firmware > blobs not derivative works of the kernel they are under. Uh... not precisely. You have your facts straight, but your logic is bad. This fact alone isn't enough to decide whether or not firmware is a derivative work. Fortunately this thought isn't a big deal for the cases we're currently talking about. -- Raul - 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.
On Fri, 2005-04-08 at 09:08 -0300, Humberto Massa wrote: > Adrian Bunk wrote: > >Debian doesn't seem to care much about the possible legal problems of > >patents. You have lots of "possible legal problems" of any kind. Basically everyone can sue you for (almost) whatever he wants almost all ofth time. > The possible legal problem of software patents is, up to the present > time, AFAICT, not producing effects yet in Europe, and is a non-problem It is starting now. Basically the corporations with the masses of software patents and patent lawyers are probably waiting for the settling of the discussion and the ratification of the relevant to-be-accepted laws. And the war is not over yet ... In fact software patents are real in EUrope and they exist (though illegally). Up to now it was a question of whether you can succeed in court with them and which courts to go > in jurisdictions like mine (down here neither business methods nor > software are patentable). I suspect that .br is commercially not relevant enough for this ATM. Or the legislation is already USPTO-conform in place and nobody knows . Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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.
Adrian Bunk wrote: Debian doesn't seem to care much about the possible legal problems of patents. The possible legal problem of software patents is, up to the present time, AFAICT, not producing effects yet in Europe, and is a non-problem in jurisdictions like mine (down here neither business methods nor software are patentable). The firmware issues are an urgent real problem? OTOH, the firmware issues *is* a legal real problem (copyright infringement is even a criminal offense in a lot of juristictions -- down here, 6 months to 2 years of soft jail + fine for non-commercial and 2 to 4 years of hard-jail + fine for commercial intents). Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. You are right, but as I told you, the mirrors are really worse when there is a chance of copyrights infringement than of patents infringement -- even on those jurisdictions that *have* software patents, things are more difficult to prosecute in the patent field. But ignoring some areas while being more religious than RMS in other areas is simply silly. Conceded. You are right on this. HTH, Massa - 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.
On Thu, Apr 07, 2005 at 11:07:23PM +0200, Adrian Bunk wrote: > On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote: > > Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit : > > > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: > > > > On Apr 04, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > What if we don't want to do so? I know I personally posted a solution > > > > Then probably the extremists in Debian will manage to kill your driver, > > > > like they did with tg3 and others. > > > > > > And as they are doing with e.g. the complete gcc documentation. > > > > > > No documentation for the C compiler (not even a documentation of the > > > options) will be neither fun for the users of Debian nor for the Debian > > > maintainers - but it's the future of Debian... > > > > You are mixing apples and oranges. The fact that the GFDL sucks has > > nothing to do with the firmware issue. With the current situation of > > firmwares in the kernel, it is illegal to redistribute binary images of > > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > > be willing to distribute such binary images, but it isn't our problem. > >... > > > It's a grey area. > > debian-legal did pick one of the possible opinions on this matter. > > The similarities between the GFDL and the firmware discussion can be > described with the following two questions: > > Is it true, that the removal of much of the documentation in Debian is > scheduled soon because it's covered by the GFDL, that this is called an > "editorial change", and that Debian doesn't actually care that this will > e.g. remove all documentation about available options of the standard C > compiler used by and shipped with Debian? Notice though that the GFDL problematic is part of a much older issue between debian and the FSF on this, and i believe discussions to solve this issues have been under discussions since more than a year without real progress that i know of. > Is it true, that Debian will leave users with hardware affected by the > firmware problem without a working installer in Debian 3.1? Yes, probably. not my fault though, and the current discussion is part of the plan to fix this, through availability of non-free installer components. > The point is simply, that Debian does more and more look dogmatic at > it's definition of "free software" without caring about the effects to > it's users. I reject this affirmation. > As a contrast, read the discussion between Christoph and Arjan in a part > of this thread how to move firmware out of kernel drivers without > problems for the users. This might not happen today, but it's better for > the users. It is indeed, but it is something that involves kernel development which i don't really have time to do right now, and even if we where to do that, the legal problem of the messed licencing situation would remain. The current short term solution is simply to move the affected drivers to non-free, and provide mechanisms for the user to load these installer modules with the free installer, or have a couple of builds of a non-free installer which include these non-free modules. Saying that we are dogmatic, without even caring to understand what the current reality is doesn't strike me at the most reasonable way to discuss such issues. Friendly, Sven Luther - 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.
On Fri, 8 April 2005 09:22:00 +0200, Josselin Mouette wrote: > Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit : > > > As a contrast, read the discussion between Christoph and Arjan in a part > > of this thread how to move firmware out of kernel drivers without > > problems for the users. This might not happen today, but it's better for > > the users. > > Some Debian developers have been writing such patches so that we can > still run Linux on this hardware, long before the topic was raised on > the LKML. I can point you to dozens of patches I have written that were never merged. Not because Linus is a d*ckhead (he's not), but because they were not good enough then and I didn't spend the time to improve them, so far. "Someone's written some patches" is a long way from "we have a good solution". Jörn -- You cannot suppose that Moliere ever troubled himself to be original in the matter of ideas. You cannot suppose that the stories he tells in his plays have never been told before. They were culled, as you very well know. -- Andre-Louis Moreau in Scarabouche - 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.
Hi, Humberto Massa wrote: > First, there is *NOT* any requirement in the GPL at all that requires > making compilers available. Otherwise it would not be possible, for > instance, have a Visual Basic GPL'd application. And yes, it is > possible. >From section 3 of the GNU GPL, version 2: The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. 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. I take that to mean the compiler's exempted if it's the normal one available on the platform, but if the software distributor had to modify gcc to produce the binaries it's distributing then you're entitled to the compiler too. So a Visual BASIC application uses a standard VB compiler, but that's not necessarily the case for a Linux kernel running on an embedded box. Cheers, Ralph. - 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.
On Tue, Apr 05, 2005 at 12:50:14PM -0600, Chris Friesen wrote: > Josselin Mouette wrote: > > >The fact is also that mixing them with a GPLed software gives > >an result you can't redistribute - although it seems many people > >disagree with that assertion now. > > This is only true if the result is considered a "derivative work" of the > gpl'd code. > > The GPL states "In addition, mere aggregation of another work not based > on the Program with the Program (or with a work based on the Program) on > a volume of a storage or distribution medium does not bring the other > work under the scope of this License." > > Since the main cpu does not actually run the binary firmware, the fact > that it lives in main memory with the code that the cpu *does* run is > irrelevent. In this case, the Debian stance is that the kernel proper > and the binary firmware are "merely aggregated" in a volume of storage ( > ie. system memory). The problem is that you can only argue it is mere agregation, if the copyright notice doesn't de-facto put said firmware blobs under the GPL, thus making them undistributable by the selfsame definition of the GPL. Friendly, Sven Luther - 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.
On Thu, Apr 07, 2005 at 04:15:45PM +0200, Josselin Mouette wrote: > Le jeudi 07 avril 2005 à 09:03 -0400, Richard B. Johnson a écrit : > > Well it doesn't make any difference. If GPL has degenerated to > > where one can't upload microcode to a device as part of its > > initialization, without having the "source" that generated that > > microcode, we are in a lot of hurt. Intel isn't going to give their > > designs away. > > The GPL doesn't forbid that. The GPL forbids to put this microcode > directly in the same binary as the GPL code. Of course, nothing forbids > some GPL'ed code to take a binary elsewhere and to upload it into the > hardware. No, i am arguing, that we can consider here the binary as a media distribution, in the same way as we would clearly separate the compressor from the compressed data in a auto-uncompressing executable, or the firmware from the firmware flasher in a all-in-one firmware upgrade binary. > At least that's my opinion; AIUI, Sven Luther believes it is possible if > the firmware has a decent (but not necessarily free) license. Indeed, the sole problem is that the current copyright and licencing attributions de-facto sets those firmware blobs under the GPL, which of course makes them undistributable since the GPL clearly claims that we need source code for it, and if any condition of the GPL fails, the program becomes undistributable as a whole. Friendly, Sven Luther - 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.
On Thu, Apr 07, 2005 at 09:15:07AM -0300, Humberto Massa wrote: > This is where you are wrong IMMHO. All that is needed for you > to distribute the hexdump blob under the GPL is a declaration > from the copyright holder saying "this, to me, is the > preferred form for modification of the firmware and hence the > source code under the GPL." I strongly disagree. This could be an open door to to anyone claiming that whatever binary is the prefered form of modification. Friendly, Sven Luther - 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.
On Fri, Apr 08, 2005 at 04:56:50AM +0100, Henning Makholm wrote: > Scripsit "David Schwartz" <[EMAIL PROTECTED]> > [quoting me] > > >> No, it is completely wrong to say that the object file is merely an > >> aggregation. The two components are being coupled much more tightly > >> than in the situation that the GPL discribes as "mere aggregation". > > > Would you maintain this position even if the firmware is identical > > across operating systems and the Linux driver is identical across different > > firmware builds for different hardware implementations? > > 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 ? > 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. > > 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". 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. Friendly, Sven Luther - 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.
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 and : http://lists.debian.org/debian-legal/2005/03/msg00283.html and the following thread. These where linked from the original mail in this thread. > > No-one is saying that the linker "merely aggregates" object > > code for the driver; what *is* being said is: in the case of > > firmware, especially if the firmware is neither a derivative > > work on the kernel (see above) nor the firmware includes part > > of the kernel (duh), it is *fairly* *safe* to consider the > > intermixing of firmware bytes with kernel binary image bytes > > in an ELF object file as mere aggregation. > > No, it is completely wrong to say that the object file is merely an > aggregation. The two components are being coupled much more tightly > than in the situation that the GPL discribes as "mere aggregation". So read the analysis and comment on it if you disagree, but let's take it to debian-legal alone, ok ? Friendly, Sven Luther - 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.
On Tue, Apr 05, 2005 at 11:50:54AM -0400, Richard B. Johnson wrote: > On Tue, 5 Apr 2005, Humberto Massa wrote: > > >Josselin Mouette wrote: > > > >>You are mixing apples and oranges. The fact that the GFDL sucks has > >>nothing to do with the firmware issue. With the current situation of > >>firmwares in the kernel, it is illegal to redistribute binary images of > >>the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > >>be willing to distribute such binary images, but it isn't our problem. > >> > > Wrong! It is perfectly legal in the United States, and I'm pretty > sure in your country, to distribute or redistribute copyrighted > works. Otherwise there wouldn't be any bookstores or newspaper > stands. Mmm, so you are claiming it is perfectly right to make copies of the windows installation CD, or for that matter to duplicate music CDs ? I would be rather interested in knowing how you came to that conclusion :) Friendly, Sven Luther - 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.
On Thu, Apr 07, 2005 at 11:55:44PM -0400, Raul Miller wrote: > > > Also, "mere aggregation" is a term from the GPL. You can read what > > > it says there yourself. But basically it's there so that people make > > > a distinction between the program itself and other stuff that isn't > > > the program. > > On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: > > It's also there because the GPL can only apply to either works > > placed under it by their authors and works that are legally classified > > as derivative. If you merely aggregate two works, there is no > > derivation. The GPL is making clear that it's not trying to exceed the > > scope of its authority (which is copyright law). > > The issue of whether or not the combined work is a derivative under > copyright law is a copyright law issue. The GPL does concern itself > with that issue, but not in the "mere aggregation" clause. > > The "mere aggregation" clause holds regardless of whether or not the > combined work is a derivative under copyright law. > > [P.S. I've set the Reply-To: header on this message because I think this > thread has drifted away from kernel issues.] Thanks. BTW, have any of you read the analysis i made, where i claim, rooted in the GPL FAQ and with examples, why i believe that the firmware can be considerated a non derivative of the linux kernel. The main points is that the firmware is not aimed to run in the same address space, even not the same cpu, as the rest of the linux kernel, and that there is a clearly defined communication channel between the GPLed driver and the target processor running the firmware. I further argumented that taking any different stance would bring us worlds of hurt as we would consider the bios as being a derivative work of the kernel they are running, or the bootloader, or the firmware present in proms on devices loaded into the system and so on. I think only the fact that if you consider firmware as being a derivative work, you should consider it a derivative work also when it is flashed on the prom of a pci card or what not, is decisive enough to make those firmware blobs not derivative works of the kernel they are under. Friendly, Sven Luther - 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.
Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit : > > You are mixing apples and oranges. The fact that the GFDL sucks has > > nothing to do with the firmware issue. With the current situation of > > firmwares in the kernel, it is illegal to redistribute binary images of > > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > > be willing to distribute such binary images, but it isn't our problem. > > It's a grey area. > > debian-legal did pick one of the possible opinions on this matter. When there are several possible interpretations, you have to pick up the more conservative one, as it's not up to us to make the interpretation, but to a court. > Is it true, that the removal of much of the documentation in Debian is > scheduled soon because it's covered by the GFDL, that this is called an > "editorial change", and that Debian doesn't actually care that this will > e.g. remove all documentation about available options of the standard C > compiler used by and shipped with Debian? The situation changed only in the mind of the person who was the release manager at that time. The "old" wording is "Debian will remain 100% free software", and he understood that as "100% of software in Debian will remain free". The common interpretation is that this wording doesn't allow GFDL documentation either. The fact these documents are very useful is irrelevant: the GFDL is a real piece of crap, only a few fools at the FSF are really arguing it is a free license. Instead of babbling, some people have started to discuss this with upstream, and are trying to come up with a GPLed documentation for GCC. This is much more constructive than repeating again and again "Bleh, Debian are a bunch of bigots who don't care of the compiler being documented." > Is it true, that Debian will leave users with hardware affected by the > firmware problem without a working installer in Debian 3.1? The case of hardware really needing a firwmare to work *and* needed at installation time is rare. I've only heard of some tg3-based cards. Most of them will work without the firmware, and for the few remaining ones, it only means network installation won't work. > The point is simply, that Debian does more and more look dogmatic at > it's definition of "free software" without caring about the effects to > it's users. Being careless in the definition of "free software" is a real disservice to users. It makes them rely on e.g. non-free documentation for everyday use. > As a contrast, read the discussion between Christoph and Arjan in a part > of this thread how to move firmware out of kernel drivers without > problems for the users. This might not happen today, but it's better for > the users. Some Debian developers have been writing such patches so that we can still run Linux on this hardware, long before the topic was raised on the LKML. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote: > On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: > > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: > >... > > > If your statement was true that Debian must take more care regarding > > > legal risks than commercial distributions, can you explain why Debian > > > exposes the legal risks of distributing software capable of decoding > > > MP3's to all of it's mirrors? > > > > I don't know and don't really care. I don't maintain any mp3 player (err, > > actually i do, i package quark, but use it mostly to play .oggs, maybe i > > should think twice about this now that you made me aware of it), but in any > > case, i am part of the debian kernel maintainer team, and as such have a > > responsability to get those packages uploaded and past the screening of the > > ftp-masters. I believe the planned solution is vastly superior to the > > current > > one of simply removing said firmware blobs from the drivers, which caused > > more > > harm than helped, which is why we are set to clarifying this for the > > post-sarge kernels. > > > Debian doesn't seem to care much about the possible legal problems of > patents. patents are problematic, and upto recently there where no software patents in europe, so i don't really care. I am not sure about the details of the above problem you mention, could you provide me some link to the problem at hand. I also believe that in the larger scheme restriction of this kind, as is the US restriction on distribution to cuba and everything else, is not-right and even immoral, and *I* personally would fight back if i was ever sued for such things, and there may be higher courts involved than just the US judicial system, which is for sale anyway, where redhat is dependent on. I cannot talk about the whole of debian on this though, and i feel it is for someone else to tackle and handle. If you feel strongly about this, you are free to go take it over with whoever handles this, post to debian-legal and debian-project about it, and help get the issue solved. (/me believes such restrictions of the above are a violation of the elemental human rights to go where one wants and run what operating system on wants). > The firmware issues are an urgent real problem? It is a problem that concerns me and the debian kernel team, thus we are out to fix it. If you have a problem at hand, even if it is not as important as others, would you sit back and not do anything just because others didn't solve other problems ? > Debian should define how much legal risk they are willing to impose on > their mirrors and distributors and should act accordingly in all areas. That is for the ftp-masters to decide, i am not in best speaking term with them, so you are free to go ask the question directly. > But ignoring some areas while being more religious than RMS in other > areas is simply silly. Come on, i am just asking for a damn explicit declaration that the firmware is not something covered by the GPL, and that we should have explicit distribution licence for it. We all agree that these are not covered by the GPL for various reasons, so why not have the copyright holder state it explicitly ? I don't see how do you jump to "more religious than RMS" from that, given that my analysis making the firmware aggregate works are a wee bit different from what they explicitly write in their GPL FAQ. > > That said, i was under the understanding that after the SCO disaster, > > clarification of licencing issues and copyright attributions was a welcome > > thing here, but maybe i misunderstood those whole issues. > > "SCO disaster"? > > It is a disaster for SCO. Now, yes. but we did strengthen our admission of patches policy for more tracability, didn't we, and there where companies who paid SCO for fear of retribution, and they where project who post-poned their linux adoptions, and what not. If nothing else, be it only for all the time we all lost following that story over the past tree years. Friendly, Sven Luther - 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.
On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > > It sounds like you are now looking at the question of are the > > > huge string of hex characters the preferred form for making > > > modifications to firmware. Personally I would be surprised > > > but those hunks are small enough it could have been written > > > in machine code. > > > > Yep, i also think it is in broadcom's best interest to modify the licencing > > text accordyingly, since i suppose someone could technicaly come after them > > legally to obtain said source code to this firmware. Unprobable though. > > Possibly. It sounds like that is what you want to do. No, i am making them aware of the possibility, and hoping they fix the issue, but we will see. If they fail to act on this, i don't understand why though, since it is just addition of a clarification. It is not as if i am asking for the release of all their chip specs or something such. > > since there should be at least some kind of executable code in it, > > independenlty of the fact that we claim that data is also software. > > Do you have any evidence that ``software'' was not written directly in > machine code? Software is written directly in machine code when a programmer So what, i seriously doubt they where written using an vi in C, as the code currently stands, so we do need an additional level of source code, being it only some asm code or something. > looks at the instruction set and writes down the binary representation > of the instructions. I know ISC dhcpd has packet filter code that was written > in that manner, so it is not a lost art. And it is done often enough when > an assembler will not cooperate, and generate the correct instruction. But again, this is not the common assumption, so if this is so, they should write it down black on white in the copyright notice, and everyone would be happy. > Without evidence that we don't have the preferred form of the software > for making modifications I don't see how you can complain. No, it goes the other way around. Without evidence that all is clean, we have no right to distribute that code, and if what you describe was the case, a couple of lines telling us that fact would solve the issue, and not even need the involvement of their legal department. I would be somewhat suspisious though if all these guys came up and said they just wrote said firmware in binary directly though. Friendly, Sven Luther - 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.
On Thu, Apr 07, 2005 at 08:05:31PM -0700, David Schwartz wrote: > I think we have a real problem, however, in cases where the source > file that holds only the firmware data contains a GPL notice. Sure: the GPL notice isn't completely valid. But I think people have already decided that this is an issue that needs to be fixed. And, I think most of the approach for fixing these is fairly clear. That said... perhaps it's worth going over a hierarchy of copyright issues: First, there's the issue of whether or not work is protected by copyright. I think we're talking about stuff that's protected by copyright. If it is protected by copyright, there's the question of whether the things being done with that work are regulated by copyright law. I think we're talking about activities (making copies of linux and distributing it) which are regulated by copyright law. If both hold, the next question is whether or not the copyright license allows this use. As you've indicated, we do have some real issues here. Finally, if you're dealing with regulated activity and the license doesn't allow it, it's up to the copyright holder to decide whether or not to prosecute. So far, the copyright holders haven't said much about these issues. We probably have some issues where what we're doing is only by the good graces of the copyright holder(s). We should fix those things, of course, but currently there aren't any deadlines we have to meet. -- Raul - 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.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> [quoting me] >> No, it is completely wrong to say that the object file is merely an >> aggregation. The two components are being coupled much more tightly >> than in the situation that the GPL discribes as "mere aggregation". > Would you maintain this position even if the firmware is identical > across operating systems and the Linux driver is identical across different > firmware builds for different hardware implementations? 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. 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". > Note that the issue is not whether the GPL describes this as "mere > aggregation" because the GPL doesn't get to set its own scope. The scope of the copyright of the original work includes situation where part of that original work is being copied (excluding fair use and other jurisdiction-specific exceptions). In order to do such copying, you need permission from the copyright holder of the original work. If all the permission you have is the GPL, the copyihg you are doing had better fall into the class of copying that the GPL provides a permission for. 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. > The issue is whether the resulting binary is a single work (that is > derivative of the GPL'd driver) or whether it's two works with a > license boundary between them. A reasonable person can disagree about whether the word "work" in GPL #2(b) is meant to exclude non-trivial aggregations that do not add creative choice to that already expressed in the components. However, I don't think a reasonable person can argue that even if 2(b) had said "byte stream" instead of "work" it would not have been legally potent to demand GPL-compatible licensing of the firmware as a condition for the permission to copy the GPL-covered part of the byte stream. > It would not be obviously unreasonable to argue that the NE2000 API > constitutes a license boundary between the two works, each of which stays on > its own side of that API. 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. > Lacking clear court guidance, I see it as a threshold issue. One > primary issue (I think) is to what extent that firmware and the driver have > been customized for each other. A work that is carefully designed to mesh > tightly with another work is analogous to a sequel, which is a derivative > work. 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. -- Henning Makholm "... and that Greek, Thucydides" - 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.
> > Also, "mere aggregation" is a term from the GPL. You can read what > > it says there yourself. But basically it's there so that people make > > a distinction between the program itself and other stuff that isn't > > the program. On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: > It's also there because the GPL can only apply to either works > placed under it by their authors and works that are legally classified > as derivative. If you merely aggregate two works, there is no > derivation. The GPL is making clear that it's not trying to exceed the > scope of its authority (which is copyright law). The issue of whether or not the combined work is a derivative under copyright law is a copyright law issue. The GPL does concern itself with that issue, but not in the "mere aggregation" clause. The "mere aggregation" clause holds regardless of whether or not the combined work is a derivative under copyright law. [P.S. I've set the Reply-To: header on this message because I think this thread has drifted away from kernel issues.] -- Raul - 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 <[EMAIL PROTECTED]> writes: > > It sounds like you are now looking at the question of are the > > huge string of hex characters the preferred form for making > > modifications to firmware. Personally I would be surprised > > but those hunks are small enough it could have been written > > in machine code. > > Yep, i also think it is in broadcom's best interest to modify the licencing > text accordyingly, since i suppose someone could technicaly come after them > legally to obtain said source code to this firmware. Unprobable though. Possibly. It sounds like that is what you want to do. > > So I currently have no reason to believe that anything has been > > done improperly with that code. > > Well, it all depends if you consider this firmware blob as software, which i > feel it is without doubt, or we have not the same definition of software, > i.e., the program which runs on the hardware, or not. We cannot claim this is > data, > > since there should be at least some kind of executable code in it, > independenlty of the fact that we claim that data is also software. Do you have any evidence that ``software'' was not written directly in machine code? Software is written directly in machine code when a programmer looks at the instruction set and writes down the binary representation of the instructions. I know ISC dhcpd has packet filter code that was written in that manner, so it is not a lost art. And it is done often enough when an assembler will not cooperate, and generate the correct instruction. Without evidence that we don't have the preferred form of the software for making modifications I don't see how you can complain. Eric - 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.
> > No-one is saying that the linker "merely aggregates" object > > code for the driver; what *is* being said is: in the case of > > firmware, especially if the firmware is neither a derivative > > work on the kernel (see above) nor the firmware includes part > > of the kernel (duh), it is *fairly* *safe* to consider the > > intermixing of firmware bytes with kernel binary image bytes > > in an ELF object file as mere aggregation. > No, it is completely wrong to say that the object file is merely an > aggregation. The two components are being coupled much more tightly > than in the situation that the GPL discribes as "mere aggregation". Would you maintain this position even if the firmware is identical across operating systems and the Linux driver is identical across different firmware builds for different hardware implementations? Say, for example, Intel comes out with a new super-smart and sophisticated network card. They also offer firmware that makes it look just like an NE2000. They don't create this firmware for Linux, they create it for any set of operating systems that don't have specific drivers for this card. Similarly, the NE2000 driver wasn't specifically designed to use this firmware. Both the firmware and the driver were independently developed to implement the same de facto standard. Now, someone combines the firmware and the driver into a package that checks what card you are using, and if it has the appropriate firmware to make the card work with the driver, uploads it. Note that the issue is not whether the GPL describes this as "mere aggregation" because the GPL doesn't get to set its own scope. The issue is whether the resulting binary is a single work (that is derivative of the GPL'd driver) or whether it's two works with a license boundary between them. It would not be obviously unreasonable to argue that the NE2000 API constitutes a license boundary between the two works, each of which stays on its own side of that API. Lacking clear court guidance, I see it as a threshold issue. One primary issue (I think) is to what extent that firmware and the driver have been customized for each other. A work that is carefully designed to mesh tightly with another work is analogous to a sequel, which is a derivative work. I think we have a real problem, however, in cases where the source file that holds only the firmware data contains a GPL notice. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. > No-one is saying that the linker "merely aggregates" object > code for the driver; what *is* being said is: in the case of > firmware, especially if the firmware is neither a derivative > work on the kernel (see above) nor the firmware includes part > of the kernel (duh), it is *fairly* *safe* to consider the > intermixing of firmware bytes with kernel binary image bytes > in an ELF object file as mere aggregation. No, it is completely wrong to say that the object file is merely an aggregation. The two components are being coupled much more tightly than in the situation that the GPL discribes as "mere aggregation". -- Henning Makholm "Hør, hvad er det egentlig der ikke kan blive ved med at gå?" - 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.
On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: >... > > If your statement was true that Debian must take more care regarding > > legal risks than commercial distributions, can you explain why Debian > > exposes the legal risks of distributing software capable of decoding > > MP3's to all of it's mirrors? > > I don't know and don't really care. I don't maintain any mp3 player (err, > actually i do, i package quark, but use it mostly to play .oggs, maybe i > should think twice about this now that you made me aware of it), but in any > case, i am part of the debian kernel maintainer team, and as such have a > responsability to get those packages uploaded and past the screening of the > ftp-masters. I believe the planned solution is vastly superior to the current > one of simply removing said firmware blobs from the drivers, which caused more > harm than helped, which is why we are set to clarifying this for the > post-sarge kernels. Debian doesn't seem to care much about the possible legal problems of patents. The firmware issues are an urgent real problem? Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. But ignoring some areas while being more religious than RMS in other areas is simply silly. > That said, i was under the understanding that after the SCO disaster, > clarification of licencing issues and copyright attributions was a welcome > thing here, but maybe i misunderstood those whole issues. "SCO disaster"? It is a disaster for SCO. > Friendly, > > Sven Luther cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
> On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote: > > If you believe the linker "merely aggregates" the object code for the > > driver with the data for the firmware, I can't see how you can argue > > that any linking is anything but mere aggregation. In neither case can > > you separate the linked work into the two separate works and in both > > cases the linker provides one work direct access to the other. > You can indeed separate the firmware and the kernel into two separate > works. That's what people have been proposing as the solution to this > problem. > Also, "mere aggregation" is a term from the GPL. You can read what > it says there yourself. But basically it's there so that people make > a distinction between the program itself and other stuff that isn't > the program. It's also there because the GPL can only apply to either works placed under it by their authors and works that are legally classified as derivative. If you merely aggregate two works, there is no derivation. The GPL is making clear that it's not trying to exceed the scope of its authority (which is copyright law). > Without that mere aggregation clause, people might be claiming that > text on a disk has to be GPLed because of emacs, or that postscript > files have to be GPLed because of ghostscript, or more generally that > arbitrary object FOO has to be GPLed because of gpled program BAR. They could, but they would still be wrong. Because if you "merely aggregate" two works, the result is still two works that can each be under their own license. The GPL is only making clear what is outside its authority, but it does not set the scope of its own authority anyway. > Put another way, what the linker does or doesn't do isn't really the > issue. Well it is. The question is whether you can link two object files together and distribute the result under the license of each independent file, treating it like a disk with two files on it, rather than as a single work. > People like to think that the linker is somehow special for copyright, > but it's not. Either the stuff being linked is protected by copyright > even when it's not linked or it's not protected by copyright after it is > linked. If the license says something about linking then that matters, > but only for cases where the code was protected by copyright even before > it was linked. And then linking only matters in the specific way that > that license says it matters. Regardless of what the GPL says, there is a genuine question of whether linking together file A and file B results in a file C that contains the two separate works or is a single work that is derivative of both A and B. This is important because of aspects of copyright law that the GPL acknowledges explicitly but does not get to decide. 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: > On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote: > >... > > The other point is that other entities, like redhat, or suse (which is now > > novel and thus ibm) and so have stronger backbones, and can more easily > > muster > > the ressources to fight of a legal case, even one which is a dubious one, > > especially given the particularities of the US judicial system, where it is > > less important to be right, and more important to have lot of money to throw > > at your legal machine. Debian has nothing such, and SPI which would stand > > for > > this, is not really upto it either, so in this case, apart from all ideology > > and fanatism, it is for purely pragmatic reasons that they don't distribute > > undistributable files from the non-free part of our archive. You would do > > the > > same in their case. > >... > > > There are many possible legal risks for a Linux distribution. > > > This thread is about one. > > Another one is that RedHat removed MP3 support in their distribution > from programs like xmms ages ago because of the legal risks due to > patents. The Debian distribution still contains software that is capable > of playing MP3's. > > > I'd say of the two above cases, the MP3 patents are far more likely to > cause a lawsuit. > > YMMV. Yes, possibly, especially in these troubled times. > If your statement was true that Debian must take more care regarding > legal risks than commercial distributions, can you explain why Debian > exposes the legal risks of distributing software capable of decoding > MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. That said, i was under the understanding that after the SCO disaster, clarification of licencing issues and copyright attributions was a welcome thing here, but maybe i misunderstood those whole issues. Friendly, Sven Luther - 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.
On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote: > Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit : > > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: > > > On Apr 04, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > What if we don't want to do so? I know I personally posted a solution > > > Then probably the extremists in Debian will manage to kill your driver, > > > like they did with tg3 and others. > > > > And as they are doing with e.g. the complete gcc documentation. > > > > No documentation for the C compiler (not even a documentation of the > > options) will be neither fun for the users of Debian nor for the Debian > > maintainers - but it's the future of Debian... > > You are mixing apples and oranges. The fact that the GFDL sucks has > nothing to do with the firmware issue. With the current situation of > firmwares in the kernel, it is illegal to redistribute binary images of > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > be willing to distribute such binary images, but it isn't our problem. >... It's a grey area. debian-legal did pick one of the possible opinions on this matter. The similarities between the GFDL and the firmware discussion can be described with the following two questions: Is it true, that the removal of much of the documentation in Debian is scheduled soon because it's covered by the GFDL, that this is called an "editorial change", and that Debian doesn't actually care that this will e.g. remove all documentation about available options of the standard C compiler used by and shipped with Debian? Is it true, that Debian will leave users with hardware affected by the firmware problem without a working installer in Debian 3.1? The point is simply, that Debian does more and more look dogmatic at it's definition of "free software" without caring about the effects to it's users. As a contrast, read the discussion between Christoph and Arjan in a part of this thread how to move firmware out of kernel drivers without problems for the users. This might not happen today, but it's better for the users. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote: >... > The other point is that other entities, like redhat, or suse (which is now > novel and thus ibm) and so have stronger backbones, and can more easily muster > the ressources to fight of a legal case, even one which is a dubious one, > especially given the particularities of the US judicial system, where it is > less important to be right, and more important to have lot of money to throw > at your legal machine. Debian has nothing such, and SPI which would stand for > this, is not really upto it either, so in this case, apart from all ideology > and fanatism, it is for purely pragmatic reasons that they don't distribute > undistributable files from the non-free part of our archive. You would do the > same in their case. >... There are many possible legal risks for a Linux distribution. This thread is about one. Another one is that RedHat removed MP3 support in their distribution from programs like xmms ages ago because of the legal risks due to patents. The Debian distribution still contains software that is capable of playing MP3's. I'd say of the two above cases, the MP3 patents are far more likely to cause a lawsuit. YMMV. If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? > Friendly, > > Sven Luther cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.
On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote: > If you believe the linker "merely aggregates" the object code for the > driver with the data for the firmware, I can't see how you can argue > that any linking is anything but mere aggregation. In neither case can > you separate the linked work into the two separate works and in both > cases the linker provides one work direct access to the other. You can indeed separate the firmware and the kernel into two separate works. That's what people have been proposing as the solution to this problem. Also, "mere aggregation" is a term from the GPL. You can read what it says there yourself. But basically it's there so that people make a distinction between the program itself and other stuff that isn't the program. Without that mere aggregation clause, people might be claiming that text on a disk has to be GPLed because of emacs, or that postscript files have to be GPLed because of ghostscript, or more generally that arbitrary object FOO has to be GPLed because of gpled program BAR. Put another way, what the linker does or doesn't do isn't really the issue. People like to think that the linker is somehow special for copyright, but it's not. Either the stuff being linked is protected by copyright even when it's not linked or it's not protected by copyright after it is linked. If the license says something about linking then that matters, but only for cases where the code was protected by copyright even before it was linked. And then linking only matters in the specific way that that license says it matters. -- Raul - 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.
On Thu, Apr 07, 2005 at 05:46:27AM -0600, Eric W. Biederman wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: > > > For tg3 a transition period shouldn't be needed as firmware loading > > > is only needed on old/buggy hardware which is not the common case. > > > Or to support advanced features which can be disabled. > > > > > > I am fairly certain in that case the firmware came from the bcm5701 > > > broadcom driver for the tg3 which I think is gpl'd. So the firmware > > > may legitimately be under the GPL. > > > > So, where is the source for it ? > > The GPL'd driver that broadcom distributes. The history of tg3.c > is that broadcom's bcm57xx driver drove the hardware correctly but > not linux so it was rewritten from scratch. Ok, thanks for that clarification. > Beyond that you need to talk to Broadcom. But if the originator > of the bits distributes them gpl from a redistribution point the > kernel is fine. As you may know, i have contacted Broadcom about this issue, the information passed from the driver support contact to their linux developers, but i have not heard from them yet. > It sounds like you are now looking at the question of are the > huge string of hex characters the preferred form for making > modifications to firmware. Personally I would be surprised > but those hunks are small enough it could have been written > in machine code. Yep, i also think it is in broadcom's best interest to modify the licencing text accordyingly, since i suppose someone could technicaly come after them legally to obtain said source code to this firmware. Unprobable though. > So I currently have no reason to believe that anything has been > done improperly with that code. Well, it all depends if you consider this firmware blob as software, which i feel it is without doubt, or we have not the same definition of software, i.e., the program which runs on the hardware, or not. We cannot claim this is data, since there should be at least some kind of executable code in it, independenlty of the fact that we claim that data is also software. Thanks for the info, i will add it to the Wiki. Friendly, Sven Luther - 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 <[EMAIL PROTECTED]> writes: > On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: > > For tg3 a transition period shouldn't be needed as firmware loading > > is only needed on old/buggy hardware which is not the common case. > > Or to support advanced features which can be disabled. > > > > I am fairly certain in that case the firmware came from the bcm5701 > > broadcom driver for the tg3 which I think is gpl'd. So the firmware > > may legitimately be under the GPL. > > So, where is the source for it ? The GPL'd driver that broadcom distributes. The history of tg3.c is that broadcom's bcm57xx driver drove the hardware correctly but not linux so it was rewritten from scratch. Beyond that you need to talk to Broadcom. But if the originator of the bits distributes them gpl from a redistribution point the kernel is fine. It sounds like you are now looking at the question of are the huge string of hex characters the preferred form for making modifications to firmware. Personally I would be surprised but those hunks are small enough it could have been written in machine code. So I currently have no reason to believe that anything has been done improperly with that code. Eric - 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.
Am Donnerstag, 7. April 2005 17:01 schrieb Humberto Massa: > Oliver Neukum wrote: > > > > > As this has been discussed numerous times and consensus never > > achieved and is unlikely to be achieved, I suggest that you keep this > > discussion internal to Debian until at least you have patches which > > can be evaluated and discussed. Until then Debian may do to its > > kernel whatever it pleases and should be prepared to explain to its > > users why it removed or altered drivers. > > > > Regards Oliver > > > > Hi, Oliver. > > You seemed to answer my e-mail without reading it; what I was explaining > in it was: this is not a matter of patches, but of asking Where are the > copyrights notices, Who are the copyright owners, and Which license are > the firmwares under, and AFTER that, patching what should be patched. > > Those three questions (Where, Who, Which) can only be answered by the > kernel maintainers, and this is in *NO* way a Debian-only discussion. As > I mentioned before, kernel.org kernel tree is, as of today, non-free and > undistributable IMHO. Those who care got you after the second message at the latest. Anything more just annoys people. Some even pay for their online time. Who doesn't care will not start caring. Your oppinion on that matter frankly is exactly that. If you care that deeply about it you'll have to track down copyright holders yourself. Good luck. Regards Oliver - 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.
Oliver Neukum wrote: As this has been discussed numerous times and consensus never achieved and is unlikely to be achieved, I suggest that you keep this discussion internal to Debian until at least you have patches which can be evaluated and discussed. Until then Debian may do to its kernel whatever it pleases and should be prepared to explain to its users why it removed or altered drivers. Regards Oliver Hi, Oliver. You seemed to answer my e-mail without reading it; what I was explaining in it was: this is not a matter of patches, but of asking Where are the copyrights notices, Who are the copyright owners, and Which license are the firmwares under, and AFTER that, patching what should be patched. Those three questions (Where, Who, Which) can only be answered by the kernel maintainers, and this is in *NO* way a Debian-only discussion. As I mentioned before, kernel.org kernel tree is, as of today, non-free and undistributable IMHO. HTH, Massa - 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/
