Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... Wouldn't this, if true, make the GPL non-free? Requiring someone to keep names of anything in the executabe affects compatibility; what if in 2010 the newest Microsoft Windows decides to check for EXPORT_SYMBOL_GPL on all your software and shut itself down if it detects any? Or suppose you have two programs that use the symbol in different ways and both are under GPL and you're not allowed to change the name used in either one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 14, 2005 at 10:56:02PM -0700, Michael K. Edwards wrote: On 4/14/05, Glenn Maynard [EMAIL PROTECTED] wrote: [snip] The FSF FAQ says that *all* software linking against GPL libraries must GPL-compatible[1]. [2] contradicts the above even more directly. Now, it's possible that they're wrong; there's the obvious theory, for example, that they've long since realized this, but have no way of fixing it without admitting to a loophole in the GPL. I've seen lots of these derivative work arguments (and others, such as whether the GPL is a contract), and have never seen a reply from the FSF addressing them; given their potential severity, that at least raises an eyebrow. Of course, I've never raised these with them personally, since I'm not even qualified to tell which arguments have enough grounding in reality to avoid wasting their time, and I don't know whether anyone else has; so I don't place too much weight in that particular theory. (I don't believe they're unaware of the arguments, though, and dispelling misconceptions about the GPL is entirely in their interest, so I'd expect to see responses to these things.) I've engaged in an extended discussion with the person on the other end of [EMAIL PROTECTED], to whom Eben Moglen directed me, on both the derivative work and GPL is a contract points. IANAL, and neither is [EMAIL PROTECTED], but I raised many of the US legal precedents which I have previously cited on debian-legal. Suffice it to say that if the FSF has a leg to stand on, it's not visible through that mechanism of inquiry. It's frustrating that the FSF will often only talk in private, and it takes a lot of effort to even get permission from them to repost their replies. Very simply, they've convinced huge numbers of programmers to use their license based on certain claims, and refusing to publically address potential problems--while at the same time, more and more people are using it--is horribly irresponsible. I say that as something of an outsider to the GPL--I release most of my code under the X11 license, now; I don't care about preventing proprietary use of my code, and in terms of copyleft, I consider release improvements to my code so we can all use them vastly more important than the if you don't free your entire program, you can't use my code at all aspect we're discussing here, being somewhat alienated from the unneighborly our way or the highway of the GPL. But, people should be choosing licenses based on reality, and not using a license with potentially unenforcable restrictions under the belief that they're enforcable--if the FSF knows these aspects of the GPL don't really exist, and claims they do anyway, well ... (I'd like to think that this is completely off-base--after all, it's a little hard to draw conclusions from inaction--but as you say, the FSF hasn't made any public statements about these issues, so all we can do is draw what conclusions we can from that ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 4/13/05, Raul Miller [EMAIL PROTECTED] wrote: On Wed, Apr 13, 2005 at 11:26:47PM +0200, Francesco Poli wrote: US copyright italian author's right (diritto d'autore italiano) -- compilation work --- collective work (opera collettiva) derivative work --- creative elaboration (elaborazione creativa) In the USA, a compilation work is a collective work has its own copyright and thus is also a derivative work. I hope to get it right... or am I confused? Sounds right. Nope. Compilations (US) / collections (Berne) and derivative works are disjoint sets under the Berne Convention (Article 2.5 and 2.3 respectively) and its national implementations (separate definitions in 17 USC 101). (One could of course have a compilation containing a derivative work, or a derivative work of a compilation.) Both are entitled to independent copyright protection that extends only to the creative expression not present in the original work(s). Trivially obvious collections (hey, let's copyright the bundle of glibc and the Linux kernel!) are not copyrightable. Incidentally, the GPL doesn't use compilation or collection in the legal sense at all. GPL Section 2 says derivative or collective works, which is the only usage of collect. Under 17 USC 101, collective works are a subset of compilations, specifically those containing multiple, identifiable, separate works of authorship (as distinct from compilations of individually uncopyrightable data, which may still be copyrightable as a whole due to the exercise of creativity in their selection and arrangement). Other passages in the GPL refer to derived or derivative works. The derivative works category was created so that an author can authorize publication while reserving rights to the rest of a work's commercial potential (e. g., a film that uses text from a book, or even a sequel that uses characters and mise en scene). The collective works category prevents the editor of a non-trivial collection (a periodical, a themed anthology) from being ripped off by another publisher who has similar access to publication rights to the individual pieces. Other compilations of otherwise uncopyrightable data are granted copyright protection for similar reasons -- but only insofar as they are creative works, not mere sweat of the brow (although this dividing line varies by national implementation and by jurisdiction much more than most other aspects of copyright law). When the work under discussion is a software package, there's also a set of engineering relationships to separately authored works that fit none of these patterns. Copyright is in my opinion just not the right tool by which to attempt to control their creation and distribution. US courts seem to agree much of the time, disallowing the abuse of the copyright monopoly to block competition in markets where interoperation matters. There's an emerging legal consensus that copyright on a software work shouldn't grant the power to disallow competitive use of it any more than copyrighting a drill bit as an artwork should grant the power to disallow its use in other brands of drill. On a myopically textual basis, I have previously argued that the text of GPL Section 2 should be construed to apply only to derivative works, ignoring the mere aggregation clause (and certainly ignoring the FSF's FAQ). But as I've also said before, this doesn't really matter. The real distinction is that the Berne categories serve different historical and statutory purposes, grounded in the actual problems that authors, editors, and publishers face in getting a fair price for their work. The GPL software author's position resembles that of the author of a literary work, not that of a publisher of a compilation, and the scope of remedies permitted is likely to be assessed accordingly. I think it's quite clear (IANAL; cases cited earlier ad nauseam) that interoperating across a published interface is a protected use irrespective of licensing terms, and I see no reason why this shouldn't apply equally to free software. Hence the price asked by the GPL -- return of the recipient's incremental work to the software commons -- is likely to be levied on true derivative works but not on other works that use them through their documented interfaces, irrespective of engineering detail. Cheers, - Michael
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard wrote: By your argumentation, it doesn't seem that this is a decision the author of the library (or kernel, or whatever) gets to make, but rather something which is inherent in what's been created; they can offer their own opinion on what constitutes an application's use of the library being intimate enough to create a derived work, but have no special authority on the subject. In other words, nothing binding would change if they were to s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/. They simply don't have any say in whether my use of their work is a derivative work or not, and these EXPORT_SYMBOL_GPL seem like documentation that says we believe use of these symbols probably means you're creating a derivative work--the derivative-work-ness is not actually a result of these tags (and the tags might be wrong). YES. Extremely well-put. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
The FSF FAQ says that *all* software linking against GPL libraries must GPL-compatible[1]. [2] contradicts the above even more directly. Interestingly enough, neither [1] nor [2] mention linking. Which makes sense since the conditions they describe hold both before and after linking. [1] talks about adding a module to a GPL licensed program and the answer points out that the license on the program requires that the entire program be released under the GPL. [2] talks about a GPL library and points out that programs will include the library. On Thu, Apr 14, 2005 at 10:56:02PM -0700, Michael K. Edwards wrote: I've engaged in an extended discussion with the person on the other end of [EMAIL PROTECTED], to whom Eben Moglen directed me, on both the derivative work and GPL is a contract points. IANAL, and neither is [EMAIL PROTECTED], but I raised many of the US legal precedents which I have previously cited on debian-legal. Suffice it to say that if the FSF has a leg to stand on, it's not visible through that mechanism of inquiry. And there's a significant chance that you were asking questions in a way that meant the answers were irrelevant to the points you wished to discuss. Without knowing the specifics, of course, it's kind of hard to say for sure. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 4/15/05, Raul Miller [EMAIL PROTECTED] wrote: [snip response to someone else's unattributed comments] On Thu, Apr 14, 2005 at 10:56:02PM -0700, Michael K. Edwards wrote: I've engaged in an extended discussion with the person on the other end of [EMAIL PROTECTED], to whom Eben Moglen directed me, on both the derivative work and GPL is a contract points. IANAL, and neither is [EMAIL PROTECTED], but I raised many of the US legal precedents which I have previously cited on debian-legal. Suffice it to say that if the FSF has a leg to stand on, it's not visible through that mechanism of inquiry. And there's a significant chance that you were asking questions in a way that meant the answers were irrelevant to the points you wished to discuss. Without knowing the specifics, of course, it's kind of hard to say for sure. I can't very easily extract the derivative work discussion from context in order to quote it for you without FSF permission (which I haven't sought). But as regards GPL is a contract, here is the relevant section of my original mail to [EMAIL PROTECTED]: ] 1) The (L)GPL is legally an offer of contract, right? ] ] It was claimed during the debian-devel discussion that the LGPL is ] somehow a unilateral grant of rights under some legal theory other ] than contract, which doesn't make sense to me. My full message may be found at http://lists.debian.org/debian-legal/2004/12/msg00209.html . The person on the other end claimed that copyright law provided a separate legal mechanism for a unilateral grant of rights outside contract but cited no authority other than an interview with Eben Moglen containing no references to actual law. When pressed on this point, he ceased to correspond. To my knowledge, this is consistent with other people's experience with the FSF in recent years, and with their blanket refusal to discuss the failure of MySQL to obtain relief under the GPL in the Progress Software case. Cheers, - Michael
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wednesday 13 April 2005 10:13 pm, Raul Miller wrote: 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? It is enforcable and is called a rolling contract. Seminal case is ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Circut, 1996). -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] 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
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 work. Summary? You could not show me any example where you *must* create a derivative work to exert your first
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
What about cases where you pay for the software before you're allowed to see the EULA? On Wed, Apr 13, 2005 at 11:21:42PM -0700, Sean Kellogg wrote: It is enforcable and is called a rolling contract. Seminal case is ProCD, Inc. v. Zeidenberg, 86 F.3d 1447 (7th Circut, 1996). That precedent is for a case where no one objected to the terms of the EULA. SoftMan Products Co. v. Adobe Systems Inc. (3rd Circuit, 2001) is an example of what can hapen when someone objects to the terms of the EULA (the court ruled that the EULA didn't apply because the software had never been run and the EULA is not presented until it is run). Step-Saver Data Systems, Inc. v. Wyse Technology (3rd Circuit, 1991) is an earlier example (court of appeals held that the EULA printed on the box was not enforceable and did not require return of the software). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems fundamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Glenn Maynard wrote: On Thu, Apr 14, 2005 at 09:18:46AM -0300, Humberto Massa wrote: Then all the people who think that creating a binary kernel module requires creating a derivative work and hence can be restricted by the GPL are wrong. Take that argument up with them. I took. Google my name on lkml and you'll see. They ARE wrong. Linus himself studied carefully the situation and came to the conclusion they are wrong, Linus himself is, as far as I understand, a programmer, not a lawyer. So am I (altough I *am* a para, after all). This does not preclude him from being right, does it? His opinion and study of this topic has no more weight on this issue than any other armchair lawyer, and far less than Eben Moglen, for instance. (I'm not claiming he's right or wrong--just that it's not useful to cite Linus himself as a source about legal issues just because he's a well- known programmer.) I wasn't. I was simply stating that me -- as a programmer, too, but mainly as a paralegal, after doing some research on the subject -- shared his views on this. The FSF FAQ says that *all* software linking against GPL libraries must GPL-compatible[1]. [2] contradicts the above even more directly. Yeah, but the GPL does not. And that is the problem. If the GPL specifically stated any works that does link, either dynamically or not, to the Program are to be considered a work based on the Program for the effects of this license, this would be substantiated. but it's not. Now, it's possible that they're wrong; I'm glad you admit that. I admit I can be wrong, too, but I sincerely don't think so. there's the obvious theory, for example, that they've long since realized this, but have no way of fixing it without admitting to a loophole in the GPL. I think the latest GPLv2 or later debates, started by rumors of the contents of the GPLv3, mostly proves that they can't fix it at all :-) At least, not without creating (a) a license that is incompatible with the GPLv2 or (b) a license that is substitutable by the GPLv2, and hence, that adds no additional restriction, so it can't add restrictions about linking. I've seen lots of these derivative work arguments (and others, such as whether the GPL is a contract), and have never seen a reply from the FSF addressing them; given their potential severity, that at least raises an eyebrow. The at least raises an eyebrow, in my personal opinion, is translated by yeah, they are agreeing that this is a loophole, and the best they can do is shut up about it. Of course, I've never raised these with them personally, since I'm not even qualified to tell which arguments have enough grounding in reality to avoid wasting their time, and I don't know whether anyone else has; so I don't place too much weight in that particular theory. (I don't believe they're unaware of the arguments, though, and dispelling misconceptions about the GPL is entirely in their interest, so I'd expect to see responses to these things.) The most relevant response to this theory IMHO is the lack of response, that occurred when Linus (as project manager of sorts IRT the kernel) made his statement almost two years ago that he did not consider kernel modules as derivative works *in* *principle*. It's reasonable to assume that if someone (especially EM) tought he was completely off his marker, this someone would have called attention to the subject. If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems fundamentally absurd to me. But not to me. I consider EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL as specific permissions to use symbols respectively in *any* module, or in *GPL-only* modules. The existence, purpose, and even the implementation of those two macros construe each use of them as a special documentation about the intimacy of the kernel modules with the *implementation* of the kernel internals, in a way that would help determine (by filtration, abstraction, comparison) if a kernel module is a derivative work of the kernel (and hence subject to GPL terms). (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) This is not really true. To reimplment GPL'd symbols without (potentially) infringing on the kernel copyright, you would have to clean-room such implementation, which is not really easy when everybody that touched a kernel-x.y.z.tar.gz is 'dirty' :-) HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Måns Rullgård wrote: Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems undamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa [EMAIL PROTECTED] writes: Måns Rullgård wrote: Glenn Maynard [EMAIL PROTECTED] writes: If you make a kernel module that only uses something EXPORT_SYMBOL()'d from the kernel, you are NOT in principle writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d symbols, then you are incurring in (b) above and your kernel module is most certainly a derivative work. The notion that what is a derivative work changes based on whether a symbol was declared with EXPORT_SYMBOL or EXPORT_SYMBOL_GPL seems undamentally absurd to me. (If somebody is reimplementing the Linux kernel API, he might just as easily reimplement the EXPORT_SYMBOL_GPL symbols, for compatibility with drivers that need them, for example.) Someone could even take the Linux kernel, and replace all EXPORT_SYMBOL_GPL with EXPORT_SYMBOL. I see nothing in the GPL prohibiting this. Sure, it wouldn't be nice, but it's legal not to be nice. Hmmm. One can argue that the EXPORT_SYMBOL* are copyright grants, and as such can't be freely edited, just like the comments as /* this module (C) 1999 Fulana Perez */ that are in the code. Removing such comments *is* illegal, and editing EXPORTs can be, too... It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Måns Rullgård wrote: It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. If EXPORT_XX are copyright notices, copyright *law* prohibit their modification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Humberto Massa [EMAIL PROTECTED] writes: Måns Rullgård wrote: It would be, if the license said it was. As it happens, the license makes no mention of this, but does give explicit permission to make any modifications desired. If EXPORT_XX are copyright notices, But are they? copyright *law* prohibit their modification. Indeed. -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 kernel module requires creating a derivative work and hence can be restricted by the GPL are wrong. Take that argument
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. See the quote from Eben Moglen above. Now, as I said, they reach different conclusions based on this, but we agree on this. DS Now
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 14, 2005 at 11:02:36AM -0300, Humberto Massa wrote: So am I (altough I *am* a para, after all). This does not preclude him from being right, does it? Nope, as I mentioned. You just seemed to put special weight on his opinion on the topic. Now, it's possible that they're wrong; I'm glad you admit that. I admit I can be wrong, too, but I sincerely don't think so. I hold the FSF's legal competence in much higher regard than my own, of course, but I don't put them on a pedestal as an organization. :) I think the latest GPLv2 or later debates, started by rumors of the contents of the GPLv3, mostly proves that they can't fix it at all :-) At least, not without creating (a) a license that is incompatible with the GPLv2 or (b) a license that is substitutable by the GPLv2, and hence, that adds no additional restriction, so it can't add restrictions about linking. The GPLv2 or later debates are a different issue. Changing the license in GPLv3 might be able to fix some problems, to adjust the license due to changed circumstances. However, even if it's completely usable and valid, it doesn't help close *loopholes* in v2, since v2 is still available for all GPLv2 or later works, since upgrading to later is not mandatory. The at least raises an eyebrow, in my personal opinion, is translated by yeah, they are agreeing that this is a loophole, and the best they can do is shut up about it. Well, I'm a bit slow to take that opinion, just because of its implications: the FSF continues to claim that the GPL applies in these ways, and continues to convince more people to put more code under the GPL based on these claims. Claiming that they know it's false is accusing them of lying, tricking people into using the GPL by deliberately giving them a false understanding of its effects. (My opinion of the FSF dropped significantly during the GFDL debacle, but it's not so low that I'm yet ready to make such claims.) But not to me. I consider EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL as specific permissions to use symbols respectively in *any* module, or in *GPL-only* modules. The existence, purpose, and even the implementation of those two macros construe each use of them as a special documentation about the intimacy of the kernel modules with the *implementation* of the kernel internals, in a way that would help determine (by filtration, abstraction, comparison) if a kernel module is a derivative work of the kernel (and hence subject to GPL terms). By your argumentation, it doesn't seem that this is a decision the author of the library (or kernel, or whatever) gets to make, but rather something which is inherent in what's been created; they can offer their own opinion on what constitutes an application's use of the library being intimate enough to create a derived work, but have no special authority on the subject. In other words, nothing binding would change if they were to s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/. They simply don't have any say in whether my use of their work is a derivative work or not, and these EXPORT_SYMBOL_GPL seem like documentation that says we believe use of these symbols probably means you're creating a derivative work--the derivative-work-ness is not actually a result of these tags (and the tags might be wrong). -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 14, 2005 at 11:47:52AM -0300, Humberto Massa wrote: If EXPORT_XX are copyright notices, copyright *law* prohibit their modification. Um, but they're *not* copyright notices, no more than this sentence is a copyright notice. You can't claim that a pizza is a copyright notice and have it be so. And regardless of whether they can be changed or not, that doesn't mean they have any binding significance, as I mentioned in my previous reply. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 4/14/05, Glenn Maynard [EMAIL PROTECTED] wrote: [snip] The FSF FAQ says that *all* software linking against GPL libraries must GPL-compatible[1]. [2] contradicts the above even more directly. Now, it's possible that they're wrong; there's the obvious theory, for example, that they've long since realized this, but have no way of fixing it without admitting to a loophole in the GPL. I've seen lots of these derivative work arguments (and others, such as whether the GPL is a contract), and have never seen a reply from the FSF addressing them; given their potential severity, that at least raises an eyebrow. Of course, I've never raised these with them personally, since I'm not even qualified to tell which arguments have enough grounding in reality to avoid wasting their time, and I don't know whether anyone else has; so I don't place too much weight in that particular theory. (I don't believe they're unaware of the arguments, though, and dispelling misconceptions about the GPL is entirely in their interest, so I'd expect to see responses to these things.) I've engaged in an extended discussion with the person on the other end of [EMAIL PROTECTED], to whom Eben Moglen directed me, on both the derivative work and GPL is a contract points. IANAL, and neither is [EMAIL PROTECTED], but I raised many of the US legal precedents which I have previously cited on debian-legal. Suffice it to say that if the FSF has a leg to stand on, it's not visible through that mechanism of inquiry. They simply don't seem to be willing to admit that, whatever may have been plausible in 198x as a strategy for legally implementing copyleft, US courts in the last couple of decades have placed limits on the pursuit of copyright infringement claims with regard to software and entertainment properties that render the FSF's position legally untenable. And to my knowledge (and a certain amount of Googling) neither Professor Moglen nor the FSF has ever publicly cited any remotely modern precedent or statute in any jurisdiction that supports their stance. Certainly not in the Progress Software v. MySQL affidavit, for instance. I understand the argument that the weight of existing Free Software ought to tilt the playing field in favor of entrants in new categories that are themselves Free Software. I even agree, to the extent that new Free Software entrants are able to rework, extend, merge, and cherry-pick from existing Free programs to meet new needs -- in precisely the ways that require copyright license as I understand it. But I draw the line at the same sort of published interface boundaries that appear to me to apply to competitive use of proprietary software interfaces. So I don't agree that the law ought to deny proprietary software the use of GPL libraries, but I understand the argument from principle, and accept it as the desire of at least a wing of the Free Software movement. But the only implementation of that ought available in current law, in any jurisdiction that I have heard named, is not a copyright license but rather a right-to-use license, which can only be sensibly enforced with regard to published (non-trade-secret) source code by means of a software patent. Make of that what you will. Cheers, - Michael
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
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]
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Not copied to the overloaded linux-kernel list On Wed, 13 Apr 2005, Raul Miller wrote: 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 Fundamental to contract law is an agreement. If there is no agreement, there is no contract. For a contract to even exist, the parties involved must have, at least at some time, agreed upon the exact specified contract, not something similar, but the exact specifications. To keep these specifications precisely known by all parties, they usually establish a written contract. Written contracts are easier to defend than others, but verbal, or even implied contracts are no less valid. For instance, if you purchase a screw-driver, there is an implied contract called fitness of use. It should be useful for manipulating screws. If it isn't, then the seller has the obligation to return the buyer's money if the buyer returns the screw driver. Just because the screw-driver was designed for manipulating screws, does not bind the purchaser to that use. The purchaser can use the screw-driver as a pry-bar or a chisel. However, any warranty is not implied for such use. A computer program that forces, or by use of coercion, requires a purchaser to agree to some terms of use cannot establish a valid contract. If you can't complete the installation of the program unless you abide by some terms shown in some menu, then some courts have held that any implied contract is invalid because one can't be forced to agree and have that agreement represent a contract. That's why so-called employment contracts where a prospective employee is forced to sign some paper or he doesn't get the job, are considered unenforceable (read invalid). It's very simple. The usual implied contract of a purchased product is that the user pays money and, in return, the user gets to use the product. Many software companies have attempted to corrupt this by requiring the user to agree to additional terms after the user has left the store with the knowledge that he is now free to use the product for which he paid. Such an agreement is coerced and, therefore, cannot represent a valid contract. Further, one is never required to use the software for its intended purpose just like you don't really need to use a screw-driver on screws. Lawyers make money by writing obfuscating contracts and then attempting to enforce or defend against them. Again, just because there is some stuff in a software screen that you have to click- through, doesn't mean that it has any validity at all. When studying Law, one must realize that there are no absolutes, unlike mathematics. One court may hold one view of a law and another may hold a completely different view. Even when actions are moved out of the local courts and into federal courts, the results of these actions are not always predictable. Judges often want to make new law, often rejecting case law. For a good book on US Computer Software Law I suggest THE LAW OF COMPUTER TECHNOLOGY Raymond T. Nimmer. ISBN 088712-355-4. There is a beginning section on Copyright Law. For instance, on page 1-16 ; ...the distinction between idea and expression in flowcharts and source code is uncertain. As a practical matter, the distinction indicates that copyright is not a viable protection for the author of a program in these forms. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wednesday 13 April 2005 06:55 am, Raul Miller wrote: 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. While I certainly appriciate the simplicity with which you view the law, I'm going to have to stand by my earlier comment and restate, once again, that the authors of the GPL claim it is NOT a contract, but rather a grant/license. Now, I've said it before, and I'll probably say it again, lots of reasonable minds differ as to whether the GPL is actually a contract or not. But if it is a contract then we need to start looking at acceptance by performace. Did the party who failed to make explicit acceptance act in a way as if he did accept? With the GPL that's a pretty easy to sustain... the limitations on the average user of GPL code is that they give up their right to a warranty. As long as they don't claim otherwise, I can't see how they could act contrary to the GPL. If you are a developer/distributor, now you NEED to have agreed to the contract in order to exercise certain rights under the copyright act. This means you have either accepted the contract and given up the right to close the source of your own work, OR, you have refused the contract and you are in breach of the copyright act. 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?] Its an unclear area of law, in my opinion. If you install an illegal version of Adobe Photoshop on your employers computer are they liable? That questions falls to a matter of agency law, not contract law. Same goes for your installation of software on behalf of your dad. When you clicked that agree button, you did so as his agent and he will be liable. -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] 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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sean Kellogg wrote: On Wednesday 13 April 2005 06:55 am, Raul Miller wrote: 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. While I certainly appriciate the simplicity with which you view the law, I'm going to have to stand by my earlier comment and restate, once again, that the authors of the GPL claim it is NOT a contract, but rather a grant/license. Now, I've said it before, and I'll probably say it again, lots of reasonable minds differ as to whether the GPL is actually a contract or not. This question pertains also to legal definitions that may differ among distinct jurisdictions. For exemple, AFAIK under Brazil's legal tradition any licence is a contract, a software user license classified as atipical and/or as of adherence (contrato de adesão). Furthermore, licences such as there GPL are better categorized as beneficial contracts (contrato benéfico), to avoid restrictions regarding adherence contracts. But if it is a contract then we need to start looking at acceptance by performace. Did the party who failed to make explicit acceptance act in a way as if he did accept? -- Prof. Pedro Antonio Dourado de Rezende /\ Ciencia da Computacao (61)3072702-212 / \ Universidade de Brasilia, DF, Brasil /\ ?http://www.cic.unb.br/docentes/pedro/sd.htm
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. On Wednesday 13 April 2005 06:55 am, Raul Miller wrote: False. For example, you can indicate acceptance of the GPL by exercising the rights it grants. On Wed, Apr 13, 2005 at 10:07:09AM -0700, Sean Kellogg wrote: While I certainly appriciate the simplicity with which you view the law, I'm going to have to stand by my earlier comment and restate, once again, that the authors of the GPL claim it is NOT a contract, but rather a grant/license. [1] Examples and counter-examples can be simple. But please don't pretend that they cover all issues. [2] I don't think you can construe this paraphrase of the GPL authors claims as meaning that a person using that grant is free to ignore the conditions imposed by the GPL. [3] You might want to take a look at Richard B. Johnson's post (he posted it a couple hours before you posted your message). Now, I've said it before, and I'll probably say it again, lots of reasonable minds differ as to whether the GPL is actually a contract or not. But if it is a contract then we need to start looking at acceptance by performace. Did the party who failed to make explicit acceptance act in a way as if he did accept? I agree. With the GPL that's a pretty easy to sustain... the limitations on the average user of GPL code is that they give up their right to a warranty. As long as they don't claim otherwise, I can't see how they could act contrary to the GPL. If you are a developer/distributor, now you NEED to have agreed to the contract in order to exercise certain rights under the copyright act. This means you have either accepted the contract and given up the right to close the source of your own work, OR, you have refused the contract and you are in breach of the copyright act. The GPL isn't intended to restrict use, so the average user isn't particularly interesting. It's the average distributor who would care or not care. (Quote: Activities other than copying, distribution and modification are not covered by this License; they are outside its scope). 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?] Its an unclear area of law, in my opinion. If you install an illegal version of Adobe Photoshop on your employers computer are they liable? I was talking about cases where the user had legally obtained the software. That questions falls to a matter of agency law, not contract law. Same goes for your installation of software on behalf of your dad. When you clicked that agree button, you did so as his agent and he will be liable. But I didn't click that agree button. He got his system with software pre-loaded. Or, the neighbor installed it for him. If someone entered into a contract on Dad's behalf, and did not disclose the contract to him, they are probably liable instead of Dad. For example, if the EULA prevents resale of the software, and Dad decides to sell the computer at a garage sale, I doubt he would be in any danger of prosecution. There would be no evidence whatsoever that Dad had entered into a contract to not sell that part of the system. In any event, it's not always the case that the existence of click-through license means that a user has accepted the license. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, 13 Apr 2005 01:53:43 -0400 Raul Miller wrote: The definitions overlap. [...] But collective works that have their own copyright are derivative works, and derivative works that have more than one original work are collective works. Thanks for the clarification. In its light, I'm coming to the following conclusion: US copyright italian author's right (diritto d'autore italiano) -- compilation work --- collective work (opera collettiva) derivative work --- creative elaboration (elaborazione creativa) In the USA, a compilation work is a collective work has its own copyright and thus is also a derivative work. I hope to get it right... or am I confused? -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpj9shROvd0r.pgp Description: PGP signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wednesday 13 April 2005 03:09 pm, Raul Miller wrote: 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. On Wednesday 13 April 2005 06:55 am, Raul Miller wrote: False. For example, you can indicate acceptance of the GPL by exercising the rights it grants. On Wed, Apr 13, 2005 at 10:07:09AM -0700, Sean Kellogg wrote: While I certainly appriciate the simplicity with which you view the law, I'm going to have to stand by my earlier comment and restate, once again, that the authors of the GPL claim it is NOT a contract, but rather a grant/license. [1] Examples and counter-examples can be simple. But please don't pretend that they cover all issues. Sounds like a reasonable request. [2] I don't think you can construe this paraphrase of the GPL authors claims as meaning that a person using that grant is free to ignore the conditions imposed by the GPL. Not quite sure what you mean hear... but I do know that a grant cannot impose active conditions. If the active conditions are enforceable, then they need to be in a contract. If my grant says you can do X, but only if you do Y then it it is a contrct. If, instead, my grant says you can do X, but not Y then its less a condition and more that I reserved Y from the list of rights I gave you, so its not a contract. The issue with the GPL is that waving right to warrenties is like saying you can do X, but only if you do Y, which is a contract. [3] You might want to take a look at Richard B. Johnson's post (he posted it a couple hours before you posted your message). Mr. Johnson's construction of the law regarding contracts of adhesion is wrong. I wish it wasn't the case, and I think there are good policy reasons for adopting Mr. Johnson's opinion, but the courts have consistently ruled the click through license are not contracts of adhesion. You'll have to address further concerns to your local legislator. Additionally, I don't think we get anywhere with the statement that some jurisdictions look at it differently. This is always going to be the case, and if we dwelled on it for too long the whole of open source software would be swallowed by lawyers trying to write exceptions for each and every jurisdiction. All I can do is tell you what I believe the U.S. law is on a subject matter. That questions falls to a matter of agency law, not contract law. Same goes for your installation of software on behalf of your dad. When you clicked that agree button, you did so as his agent and he will be liable. But I didn't click that agree button. He got his system with software pre-loaded. Or, the neighbor installed it for him. If someone entered into a contract on Dad's behalf, and did not disclose the contract to him, they are probably liable instead of Dad. For example, if the EULA prevents resale of the software, and Dad decides to sell the computer at a garage sale, I doubt he would be in any danger of prosecution. There would be no evidence whatsoever that Dad had entered into a contract to not sell that part of the system. Agency law says otherwise. If I instruct my neighbor to install software then I am instructing that neighbor to consent on my behalf. If the neighbor installs the software without my permission, and yet I have reason to know that he installed the software, then I may still be liable (this is to cover the employer who knows his employees are violating EULAs and doing nothing about it). The only clear case is when it was without my permission and I had no reason to know it was installed. But once I know, I am under a duty to figure out what happened and do something about it. Preinstalled software, if I had to take a guess, probably comes with a contractual agreement that you are said to have agreed to when you buy the thing. Although I bet you have the right to return all of that software if you don't agree. In any event, it's not always the case that the existence of click-through license means that a user has accepted the license. Thats right, if I can manage to install the software without seeing the license, then I can probably get out of it. This is why the technology requiring the click to actually happen is getting better and better. -- 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] 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
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 derivative work, even if it does not distribute it, it would be infringing on MS's copyrights and I would not
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 13, 2005 at 11:26:47PM +0200, Francesco Poli wrote: US copyright italian author's right (diritto d'autore italiano) -- compilation work --- collective work (opera collettiva) derivative work --- creative elaboration (elaborazione creativa) In the USA, a compilation work is a collective work has its own copyright and thus is also a derivative work. I hope to get it right... or am I confused? Sounds right. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
[2] I don't think you can construe this paraphrase of the GPL authors claims as meaning that a person using that grant is free to ignore the conditions imposed by the GPL. On Wed, Apr 13, 2005 at 03:49:44PM -0700, Sean Kellogg wrote: Not quite sure what you mean hear... but I do know that a grant cannot impose active conditions. If the active conditions are enforceable, then they need to be in a contract. If my grant says you can do X, but only if you do Y then it it is a contrct. If, instead, my grant says you can do X, but not Y then its less a condition and more that I reserved Y from the list of rights I gave you, so its not a contract. The issue with the GPL is that waving right to warrenties is like saying you can do X, but only if you do Y, which is a contract. Basically, I think the GPL offers a contract, but the GPL is significantly more than just a contract. The warranty disclaimer is a disclaimer regardless of whether or not you use the copyright grant, though it's undoubtedly stronger if you do use that grant. Additionally, I don't think we get anywhere with the statement that some jurisdictions look at it differently. This is always going to be the case, and if we dwelled on it for too long the whole of open source software would be swallowed by lawyers trying to write exceptions for each and every jurisdiction. All I can do is tell you what I believe the U.S. law is on a subject matter. Well... the answers.com page on first sale doctrine indicates some significantly different results from different jurisdictions, and indicates that until this is resolved by the supreme court there's good reason to be uncertain about what that eventual precedent will be. That questions falls to a matter of agency law, not contract law. Same goes for your installation of software on behalf of your dad. When you clicked that agree button, you did so as his agent and he will be liable. But I didn't click that agree button. He got his system with software pre-loaded. Or, the neighbor installed it for him. If someone entered into a contract on Dad's behalf, and did not disclose the contract to him, they are probably liable instead of Dad. For example, if the EULA prevents resale of the software, and Dad decides to sell the computer at a garage sale, I doubt he would be in any danger of prosecution. There would be no evidence whatsoever that Dad had entered into a contract to not sell that part of the system. Agency law says otherwise. If I instruct my neighbor to install software then I am instructing that neighbor to consent on my behalf. Agency law places on the agent an obligation to inform the principal of the terms of contracts the agent has entered the principal into. Until the agent informs the principal of these contracts, they are the liability of the agent. If the neighbor installs the software without my permission, ... That's not the issue. The neighbor recommended the machine in the first place, and Dad has been following the neighbor's recommendations on what to get and so on. Dad just wants something simple that he can use. Preinstalled software, if I had to take a guess, probably comes with a contractual agreement that you are said to have agreed to when you buy the thing. Although I bet you have the right to return all of that software if you don't agree. Sure, there were probably some plastic envelope with EULAs which were included with the stuff when the neighbor picked up the machine for Dad. There might even have been some click through licenses that the neighbor dealt with while getting the machine up and working. But if that neighbor is in Iraq now, it's kinda hard to ask him. In any event, it's not always the case that the existence of click-through license means that a user has accepted the license. Thats right, if I can manage to install the software without seeing the license, then I can probably get out of it. This is why the technology requiring the click to actually happen is getting better and better. And then there's 17 USC 1201. But there's other issues as well (for example, buying software under a student discount and then reselling it -- without clicking on the license). Anyways, my original point is that you cannot simply assume that the person in question has clicked on the click-through license. That's a fact that needs to be established. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Francesco Poli wrote: On Mon, 11 Apr 2005 01:47:19 +0100 Henning Makholm wrote: (I wonder what happens in jurisdications whose copyright law is not phrased in terms of derived - or that have several native words which are given different explicit meaning by the local law but would all need to be represented as a form of derive in English). The important term in this case is not the word derived nor the similar word derivative, but the word *Transformation*. See below for more... In jurisdictions such as the Italian one, for instance? In Italian author's right law (legge sul diritto d'autore), there is no use of or definition for the term derivative work, AFAICS. The law speaks about collective works (opere collettive) and creative elaborations of the work (elaborazioni di carattere creativo dell'opera). The former term refers to works that result from joining other works or parts of works in a creative way (by means of choice and coordination for a specific goal). The latter refers to substancial transformations and modifications (of a work) that have creative character. This is exactly what is translated to English (specifically to 17USC terms) as derivative works. In Brazilian Portuguese (Lei 9609/89 Lei dos Direitos Autorais = Author's Rights Act, art. 5º, VIII, 'g') they are called obras derivadas, which are closer to the English version, and defined as the work that, while is a novel intellectual creation, results from the transformation of the original work. Here in Italy, AFAIK, only those free software enthusiasts that are interested in legal aspects speak about derivative works (translating it as opere derivate). They do so just because they are exposed to common-law-centric legalese (the one used in licenses, above all) and they rightfully choose a simple short term instead of the many long phrases Italian law is full of... In Rome, do as Romans do :-) when dicussing in Italian, use the correct expression (elaborazioni di carattere creativo), preferently mentioning often where it is defined in your copyright law. IANAL, anyway. IANAL TINLA for you too :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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]
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
The 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005 22:43:20 -0400 Raul Miller wrote: [...] On Tue, Apr 12, 2005 at 12:21:40AM +0200, Francesco Poli wrote: [...] In Italian author's right law (legge sul diritto d'autore), there is no use of or definition for the term derivative work, AFAICS. The law speaks about collective works (opere collettive) and creative elaborations of the work (elaborazioni di carattere creativo dell'opera). The former term refers to works that result from joining other works or parts of works in a creative way (by means of choice and coordination for a specific goal). The latter refers to substancial transformations and modifications (of a work) that have creative character. This may just be a notational difference. I think it is: Italy *is* a member of the Berne Convention and consequently cannot have an author's right law that differs too much from other ones in the Berne Convention area (AFAIK)... In U.S. law, similar concepts exist. Yes, I knew that. The law talks about collective works and derivative works, and to a casual reader it appears as though collective works are in some way different from derivative works. Why? Are collective works and derivative works the same thing? I don't think so: Quoting http://www.copyright.gov/title17/92chap1.html#101 | A collective work is a work, such as a periodical issue, anthology, | or encyclopedia, in which a number of contributions, constituting | separate and independent works in themselves, are assembled into a | collective whole. | | A compilation is a work formed by the collection and assembling of | preexisting materials or of data that are selected, coordinated, or | arranged in such a way that the resulting work as a whole constitutes | an original work of authorship. The term compilation includes | collective works. [...] | | 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. [...] I'd be surprised if Italian law didn't have this same basic structure, though perhaps with different details. IIUC, Italian law have very similar structure, at least with respect to derivative and collective/compilation works: it just happens to use a somewhat different terminology... -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp7Znh4dZTBT.pgp Description: PGP signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Francesco Poli wrote: I think it is: Italy *is* a member of the Berne Convention and consequently cannot have an author's right law that differs too much from other ones in the Berne Convention area (AFAIK)... Italy signed Berne in 1887, and became a party to Berne 1971 in 1979. I would expect Italy's copyright law was amended in '79 for compliance with Berne '71. regards Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 13, 2005 at 01:57:29AM +0200, Francesco Poli wrote: The law talks about collective works and derivative works, and to a casual reader it appears as though collective works are in some way different from derivative works. Why? Are collective works and derivative works the same thing? The definitions overlap. Not all collective works are derivative works, because derivative work means that the work is based on some other work and yet still has enough originality to be granted separate copyright protection. Not all derivative works are collective works, because collective work means that there was more than one original work, but derivative work means that there was one or more original work. When a collective work is not a derivative work, it's not original enough to get any special copyright protection -- it's just the original works, under whatever terms. When a derivative work is not a collective work, it's because there's only one original work. But collective works that have their own copyright are derivative works, and derivative works that have more than one original work are collective works. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz writes: 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. Compiling source code is a mechanical operation, not a creative one, so copyright law (at least in the US) treats the compiled version as the original work. I suspect the law is similar for other countries that use common law. There is separate explicit provision (again, in the US) allowing a user to make de minimis changes necessary to operate software on their computer, but it is not a broad grant of permission to create derivative works, and I don't know of any case law that elaborates on how broad it is. Because of that, you still need license from the copyright holder to create a derivative work. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Henning Makholm wrote: As far as I can see you are assuming that it is either a derived work or mere aggregation, and cannot be both or neither. You then That is because copyright law classifies them this way. try to argue that because it is not a derived work, it must me a mere aggregation. I dispute the initial assumption; it appears to be logically possible [1] that it is neither derived work or mere aggregation. If it is not a derivative work nor an aggregate work, is a non-related work. Like Harry Potter and the Lord of The Rings Trilogy relate to one another. That is what copyright law says. [1] And indeed plausible if one assumes a jurisdiction with a sufficiently narrow definition of derived work. (I wonder what happens in jurisdications whose copyright law is not phrased in terms of derived - or that have several native words which are given different explicit meaning by the local law but would all need to be represented as a form of derive in English). AFAIK it would have to be a jurisdiction which copyright law is not based on the Berne convention, because such language (and the definition of derivative: a work that is based on an intelligent [=non-automatable], creative *transformation* of the original work). HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005 01:47:19 +0100 Henning Makholm wrote: (I wonder what happens in jurisdications whose copyright law is not phrased in terms of derived - or that have several native words which are given different explicit meaning by the local law but would all need to be represented as a form of derive in English). In jurisdictions such as the Italian one, for instance? In Italian author's right law (legge sul diritto d'autore), there is no use of or definition for the term derivative work, AFAICS. The law speaks about collective works (opere collettive) and creative elaborations of the work (elaborazioni di carattere creativo dell'opera). The former term refers to works that result from joining other works or parts of works in a creative way (by means of choice and coordination for a specific goal). The latter refers to substancial transformations and modifications (of a work) that have creative character. Here in Italy, AFAIK, only those free software enthusiasts that are interested in legal aspects speak about derivative works (translating it as opere derivate). They do so just because they are exposed to common-law-centric legalese (the one used in licenses, above all) and they rightfully choose a simple short term instead of the many long phrases Italian law is full of... IANAL, anyway. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpBDHMporw6l.pgp Description: PGP signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, 11 Apr 2005 01:47:19 +0100 Henning Makholm wrote: (I wonder what happens in jurisdications whose copyright law is not phrased in terms of derived - or that have several native words which are given different explicit meaning by the local law but would all need to be represented as a form of derive in English). On Tue, Apr 12, 2005 at 12:21:40AM +0200, Francesco Poli wrote: In jurisdictions such as the Italian one, for instance? In Italian author's right law (legge sul diritto d'autore), there is no use of or definition for the term derivative work, AFAICS. The law speaks about collective works (opere collettive) and creative elaborations of the work (elaborazioni di carattere creativo dell'opera). The former term refers to works that result from joining other works or parts of works in a creative way (by means of choice and coordination for a specific goal). The latter refers to substancial transformations and modifications (of a work) that have creative character. This may just be a notational difference. In U.S. law, similar concepts exist. The law talks about collective works and derivative works, and to a casual reader it appears as though collective works are in some way different from derivative works. In U.S. law, in both kinds of cases, an issue is: is there enough creativity in this derivative work for it to be granted copyright coverage as a unique work? However, for collective works there's some additional writeup to distinguish editorial work on the anthology (or whatever) from editorial work within a particular work. But, of course, it's legal to publish an anthology and also edit the stories within that anthology (as long as you have adequate copyrights). I'd be surprised if Italian law didn't have this same basic structure, though perhaps with different details. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote: Every book in my book shelf is software? If you digitalize it, yes. AFAIK software only refers to programs, not to arbitrary sequences of bytes. An MP3 file isn't software. Although it surely isn't hardware either. -- Giuseppe Oblomov Bilotta E la storia dell'umanità, babbo? Ma niente: prima si fanno delle cazzate, poi si studia che cazzate si sono fatte (Altan) (And what about the history of the human race, dad? Oh, nothing special: first they make some foolish things, then you study what foolish things have been made) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote: The way you stop someone from distributing part of your work is by arguing that the work they are distributing is a derivative work of your work and they had no right to *make* it in the first place. See, for example, Mulcahy v. Cheetah Learning. Er, that's one way, but not *the* way. I could grant you permission to create derivatives of my work, but not to redistribute them. To stop you from distributing them, I'd argue that you had no right to distribute them--you *did* have the right to make it in the first place. You could do that be means of a contract, but I don't think you could it do by means of a copyright license. The problem is that there is no right to control the distribution of derivative works for you to withhold from me. The GPL does this. Note GPL #2b: any work that you distribute or publish. If you don't distribute or publish the derivative work, the work does not need to be licensed ... under the terms of this License. It very carefully separates the permissions granted for merely creating a derivative work, and the permissions granted for distributing those works; if you distribute a linked binary in violation of the GPL, you may very well have had permission to make it in the first place. Yes, but this would be valid if and only if there was a right to restrict the distribution of derivative works that was recognized under copyright law. I can find no record of the existence of such a right. (Of course, if whether the work is a derivative is in question, that would need to be established--you would, indeed, need to argue that the work they are distributing is a derivative work--but you wouldn't necessarily further argue that they had no right to make it in the first place.) Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Humberto Massa [EMAIL PROTECTED] Henning Makholm wrote: Yes I would. Linking forms a tighter coupling than just placing the two parts side by side on a filesystem designed for general storage of byte streams. There is more to say about the situation than the naked fact that that they are aggreated on the same medium; ergo the sutiation does not constitute *only* aggregation, and the mere aggregation language of the GPL does not apply. Starting from the beginning: yes, it's true that linking forms normally a tighter (functional) coupling between some parts (caller/callee pairs, etc) of the things linked. And therefore it is not mere aggregation. In particular, the end of GPL #2 does not provide a blanket exception for all forms of aggregation; it specifically speaks about aggregation on a volume of a storage or distribution medium. And that is exactly what I argue that an ELF executable with an embedded firmware to be uploaded is, like a zip/tgz archive that happens to contain, among other stuff, the firmware. Either you are deliberately ignoring reality here, or you are really ignorant about what the function of an ELF executable is, compared to a zip/tgz archive. They are completely different things. Notice that I once have argued more completely about the hermeneutics of the GPL, explaining why I think that the mere aggregation clause 2, para 3 of the GPL is applicable to any anthology works, because of the dispositions on what is a derivative work based on the Program from clause 0. There is no valid path from the explanation about work based on the program to whether something is mere aggregation. The mere aggregation exception does not mention work based on the program at all, except in mentioning the _components_ of the aggregation. Specifically, there is _no_ implication that mere aggregation is supposed to refer generally to everything that is not a work based on the program. It *is*, therefore, relevant, whether the GPL's special conditions for works that in whole or in part contains the Program apply to the linked object files. Hmmm. I still think that the phrase that the precedes what you just cited, either the Program or any derivative work under copyright law, applies even more strongly. I do not see any argument that this explanation has any relevance here at all. No, it wouldn't be obviously unreasonable for a license to recognize such a license boundary. However, as I see it the GPL happens not to do this. I think it does, when in clause 0 it defines a work based on the Program means either the Program or any derivative work under copyright law , which is an authoritative definition, instead of the that is to say explanation that comes after it. It seems that you belive that the GPL gives you an unconditional permission to copy anything as long as you can argue that it is not a work based on the program. I cannot find any such permission in the GPL. I claim that ther is, in fact, no such permission, and your argument that the binary is not a work based in the program, can therefore not be used to conclude that you are allowed to copy the binary. I think the derivative work angle is a red herring. I do not think that either of the two parts that are being linked together (i.e. the driver and the firmware) are derivates of the other. The relevant point is that distribution of the linked _result_ is nevertheless subject to the condition in GPL #2, which is in general the only source we have for a permission to distribute a non-verbatim-source form of the driver. And what would be the consequence on this? The consequence of this is that the only way we can get permission to copy the linked binary is to follow the conditions in GPL #2 and #3. Of course, if you want to be really restrictive you could say that if I modify my copy of the program in a way that does *not*, in your opinion, create a work based in the Program, then GPL #2 does not give me permission to copy it _at all_, and I am left with no permission to distribute the result. -- Henning Makholm Det er du nok fandens ene om at mene. For det ligger i Australien! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 MakholmVi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag!
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Sven Luther [EMAIL PROTECTED] On Fri, Apr 08, 2005 at 04:56:50AM +0100, Henning Makholm wrote: Yes I would. Linking forms a tighter coupling than just placing the two parts side by side on a filesystem designed for general storage of byte streams. There is more to say about the situation than the naked So, why didn't you say it when i posted my analysis to debian-legal a month ago and asked for comments ? I have this thing called a day job which sometimes take priority over reading debian-legal postings. Occasionally I have to purge the backlog of unread postings by the catch-up command. Also, the subject has been beaten into .. well, if not death then at least very bad health, so often that it would serve no useful purpose to consistently repost old arguments each time the question was raised. Read my argumentation, comment on it, and be prepared to consider the same copy of the firmware as a derived work if shipped on a prom on the device itself. Strawman. I do not consider the firmware _itself_ to be a derived work at all. When it is distributed alone (e.g. on a prom on the device itself), it is completly independent of the copyright state of the driver that works with it. -- Henning Makholm Jeg har tydeligt gjort opmærksom på, at man ved at følge den vej kun bliver gennemsnitligt ca. 48 år gammel, og at man sætter sin sociale situation ganske overstyr og, så vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed.
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit Sven Luther [EMAIL PROTECTED] On Fri, Apr 08, 2005 at 03:10:43AM +0100, Henning Makholm wrote: Scripsit Humberto Massa [EMAIL PROTECTED] After a *lot* of discussion, it was deliberated on d-l that this is not that tricky at all, and that the mere aggregation clause applies to the combination, for various reasons, with a great degree of safety. When was this alleged conclusion reached? I remember nothing like that. http://lists.debian.org/debian-legal/2005/03/msg00273.html The point you seem to be arguing there is | My understanding of this is that neither the firmware constitute a | derived work from the flasher, nor the flasher constitute a derived | work of the firmware. which I agree with. But that is not the same thing as the above claim by Humberto that a mere aggregation results from _linking_ those two none-derived-from-the-other components. http://lists.debian.org/debian-legal/2005/03/msg00283.html Here you lose me at | First we have to consider if the mere presense of the actual | firmware non-free code in the linux driver is enough to make it a | derived work or constitute mere aggregation. As far as I can see you are assuming that it is either a derived work or mere aggregation, and cannot be both or neither. You then try to argue that because it is not a derived work, it must me a mere aggregation. I dispute the initial assumption; it appears to be logically possible [1] that it is neither derived work or mere aggregation. [1] And indeed plausible if one assumes a jurisdiction with a sufficiently narrow definition of derived work. (I wonder what happens in jurisdications whose copyright law is not phrased in terms of derived - or that have several native words which are given different explicit meaning by the local law but would all need to be represented as a form of derive in English). -- Henning Makholm Monarki, er ikke noget materielt ... Borger! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. The GPL is very clear in its implementation: it grants wider permission to create derivative works than to distribute them, implementing its virality in terms of restrictions on distribution, not creation. So, it seems that you're claiming that the GPL is broken or unenforcable in some aspects. (If you're not, I'd like to know where I'm confused.) If that's the case, it's a claim I'm not qualified to debate, but would be interested in hearing the FSF's response. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sunday 10 April 2005 01:18 pm, David Schwartz wrote: You could do that be means of a contract, but I don't think you could it do by means of a copyright license. The problem is that there is no right to control the distribution of derivative works for you to withhold from me. and then later... Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. I have no idea what the context of this thread is... its way to long and I just didn't keep up with it from the beginning, so you'll excuse me for not knowing the central issue seeking to be resolved. What I can do is comment on the above statement and try to inject a little legal reality :) First, the GPL is likely a contract, not just a license. While there are great legal debates about what that means and the benefits of the two, I think its unwise to claim parts of the GPL are unenforceable because it relies solely on copyright law. The GPL's warranty provisions are certainly not covered by copyright law... and while there are some good arguments for why that's not necessarily proof that its a contract, it can't just be dismissed. As for claim that copyright has no control over derived works. I can preface my grant that allows you to make a derived work with whatever restriction my little heart desires. If that means you can only make the derived work if I then get the complete rights to that work and you can only distribute to girls named Mary, then the copyright law empowers me to restrict that grant accordingly. If I just give you a blanket right to make a derived work, then things might be a bit more hairy. I could see a persuasive argument, but have no citable cases in front of me, that would treat a derived work similar to a joint work. This e-mail is a joint work, because I combined copyrighted work of mine and of David's. If I go out and sell this e-mail, David cannot stop me... BUT, he can sue me for an accounting and get his rightful share of the profits (Fair Use and implied license issues aside). Again, this is a right of copyright law, not just contract. -Sean -- Sean Kellogg 2nd Year - University of Washington School of Law GPSS Senator - Student Bar Association Editor-at-Large - National ACS Blog [http://www.acsblog.org] So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. The GPL is very clear in its implementation: it grants wider permission to create derivative works than to distribute them, implementing its virality in terms of restrictions on distribution, not creation. It doesn't even need to do this. First sale grants the right to use a work one lawfully possesses. One cannot use the Linux kernel source without compiling it. So one doesn't need the GPL to create at least some derivative works. So, it seems that you're claiming that the GPL is broken or unenforcable in some aspects. (If you're not, I'd like to know where I'm confused.) If that's the case, it's a claim I'm not qualified to debate, but would be interested in hearing the FSF's response. It has always been the FSF's position that you don't need to agree to the GPL to use the covered work. One cannot use the Linux kernel without compiling it and linking it. One cannot use a library without creating a work that uses the library, including the header files, and compiling/linking to form a result. So you can *create* a broad array of derivative works without invoking the GPL's restrictions (under first sale and how source code is ordinarily used). The argument that you cannot distribute a derived work unless the GPL says you can *because* you must have agreed to the GPL in order to lawfully create the derivative work is pure bunk. I don't know that the FSF relies upon the argument, however, it came up in this thread, which is why I refuted it (at least four times now). ;) DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
(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
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:03:01AM -0400, Richard B. Johnson wrote: On Thu, 7 Apr 2005, Humberto Massa wrote: David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. 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. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa 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. Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, then they need to complete the task and call it DORKware, named after themselves. There is only two things, Hardware, which is stuff you can touch, and software, which you can't and runs on it. Or can you really give any serious argumentation on why you would consider firmware or microcode as something else as software ? I doubt a judge would follow you on this, and in any case any computer language theorist will strongly disagree with this. Stuff like FGPAs are on the threshold though, but anything which is not physical hardware is software. Dropping LKML, i hope that this is ok to all concerned. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther wrote: 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. You have a right to. :-) This could be an open door to to anyone claiming that whatever binary is the prefered form of modification. It is. I mean, it *is* an open door to anyone claiming that whatever binary is the preferred form of modification. As in this door is open and there is *no* way to close it (as we cannot add restrictions to the GPL). It's the way that the GPL is written. The copyright holder gets to say, IMHO, which is the preferred form for modification. Notice that the GPL does not say the form on which the work was created. And obviously, the licensee can *not* have a say on what is the preferred form for modification, because in that case, you'll get a slippery slope on give me it in this or *that* form, at the will of the licensee. Because of this, IMHO, the licensor gets to determine what is the preferred form for modification, maybe -- and only maybe -- unless you can prove that he is lying. Friendly, Sven Luther Friendly too, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Ralph Corderoy wrote: Hi, 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. Let's put this in a line-by-line way: For an executable work, complete source code means: 1. all the source code for all modules it contains, plus 2. any associated interface definition files, plus 3. the scripts used to control compilation and installation of the executable. This means, in a normal c/c++ project, respectively: 1. *.c files; 2. *.h files; 3. autotools/Make files. That's it. 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. No, the compiler is always exempted. 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. There is no standard VB compiler, because VB does not come with Windows. You are being spoiled by your beautiful linux distro having 100+ development toolchains *included*. Cheers, Ralph. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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.
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, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, 08 Apr 2005 09:44:59 -0300 Humberto Massa wrote: Sven Luther wrote: 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 AFAIK software patents are still not effective in Europe (as in you cannot sue anyone for them yet, even if you can register some). Can anyone from EU confirm this? On 7 March 2005, the European Council Presidency (Luxembourg) sadly adopted the software patent agreement of 18 May 2004. In order to do so, the Presidency violated the Council own rules. http://wiki.ffii.org/Cons050307En This basically means that the text will go back to the European Parliament for a second reading in which there are few possibilities to reject it (if I recall correctly, a qualified majority is needed). However, the directive is still to be approved by the Parliament *and* then implemented in Eureopean Union member states. Consequently, if I understand correctly, software patents are still unenforceable in EU. P.S.: we must do something to avoid this disaster! please, help! -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpFI9MzWgODO.pgp Description: PGP signature
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: 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. Here's the best one yet: http://www.newscientist.com/article.ns?id=mg18624944.600 (Standard patent warnings apply, but this is too ludicrous to skip and the article is vague.) Elizabeth Boukis, spokeswoman for Sony Electronics, says the work is speculative. There were not any experiments done, she says. This particular patent was a prophetic invention. It was based on an inspiration that this may someday be the direction that technology will take us. Natural laws, trivial math operations, and Prophetic Patents. If somebody actually invents this, it's ours! (I'm bordering on being happy to see this level of lunacy--the further patents are pushed, the more likely it is we'll see some patent reform in our lifetimes ...) -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Matthew == Matthew Wilcox [EMAIL PROTECTED] writes: Matthew On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: Then let's see some acts. We (lkml) are not the ones with the percieved problem, or the ones discussing it. Matthew Actually, there are some legitimate problems with some of the Matthew files in the Linux source base. Last time this came up, the Matthew Acenic firmware was mentioned: Matthew http://lists.debian.org/debian-legal/2004/12/msg00078.html Matthew Seems to me that situation is still not resolved. Well whoever wrote that seems to have taken the stand that the openfirmware package was were the firmware came from. The person obviously made a lot of statements without bothering checking out the real source. Well it didn't come from there, I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. If someone wishes to post a patch adding a GPL header to the acenic_firmware.h file, fine with me. But beyond that I consider the case closed. Regards, Jes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Well whoever wrote that seems to have taken the stand that the openfirmware package was were the firmware came from. The person obviously made a lot of statements without bothering checking out the real source. Well it didn't come from there, I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. You cannot distribute anything under the GPL if you cannot also distribute the source code (the preferred form of the software for the purpose of making modifications to it). How Linux sees it is irrelevant. For any piece of software, one can imagine some processor that can only see it as data. The GPL doesn't distinguish between processors. Alteon's written agreement notwithstanding, you cannot distribute the firmware under the GPL if you cannot provide the preferred form of the firmware for the purpose of making modifications to it. The firmware does not run on Linux, so saying linux sees it as data is as absurd as saying I can distribute the x86 Linux kernel without the source because my calculator can only see it as data. You cannot distribute the firmware binary under the GPL. Period. Now, if you were trying to say that you could aggregate the firmware with another work and distribute the result under the GPL, the test would be whether the final result is mere aggregation or not. This is a fantastically tricky question and I don't think anyone on this list could give you particularly useful guidance. My own opinion is that it's a threshold issue based upon several factors. For example -- has the firmware been specifically designed to work with the Linux driver or is it generic firmware? If you can't take the thing you're distributing (the combined binary) and extract two works from it (the firmware and the work whose source you are offering), I cannot see how you can claim it's mere aggregation. 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. If you only distribute the source to the driver and don't put a GPL notice in the files that contain the firmware data, I think you're okay. I think you're asking for trouble if you distribute a combined compiled/linked driver. DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote: Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit : Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. VHDL is a hardware description language. You don't code firmware in VHDL. If the firmware, or part of it, is uploaded to a fpga you do (or Verilog instead of VHDL, same difference). OG. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Le jeudi 07 avril 2005 10:32 +0200, Olivier Galibert a crit : On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote: Le jeudi 07 avril 2005 10:04 +0200, David Schmitt a crit : Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. VHDL is a hardware description language. You don't code firmware in VHDL. If the firmware, or part of it, is uploaded to a fpga you do (or Verilog instead of VHDL, same difference). Oh yes, I was dense. Xav
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Eric W. Biederman wrote: Arjan van de Ven [EMAIL PROTECTED] writes: On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: I don't think you did get a rejection, a few people said that _they_ weren't going to do it, but if you want to then go ahead. I think people are just fed up of people bringing up the issue and then failing to do anything about it -- so prove them wrong ;-) Actually patches to add firmware loader support to tg3 got rejected. I think they will be accepted if they first introduce a transition period where tg3 will do request_firmware() and only use the built-in firmware if that fails. Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. 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. TSO firmware is commonly used these days. 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. It is. Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik 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. TSO firmware is commonly used these days. Because our TSO support has been totally broken for a long time? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schwartz wrote: Well whoever wrote that seems to have taken the stand that the openfirmware package was were the firmware came from. The person obviously made a lot of statements without bothering checking out the real source. Well it didn't come from there, I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. You cannot distribute anything under the GPL if you cannot also distribute the source code (the preferred form of the software for the purpose of making modifications to it). How Linux sees it is irrelevant. For any piece of software, one can imagine some processor that can only see it as data. The GPL doesn't distinguish between processors. I think this is undisputed. Alteon's written agreement notwithstanding, you cannot distribute the firmware under the GPL if you cannot provide the preferred form of the firmware for the purpose of making modifications to it. The firmware does not run on Linux, so saying linux sees it as data is as absurd as saying I can distribute the x86 Linux kernel without the source because my calculator can only see it as data. You cannot distribute the firmware binary under the GPL. Period. 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. Now, if you were trying to say that you could aggregate the firmware with another work and distribute the result under the GPL, the test would be whether the final result is mere aggregation or not. This is a fantastically tricky question and I don't think anyone on this list could give you particularly useful guidance. 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. (Safer than that, only after court) :-) My own opinion is that it's a threshold issue based upon several factors. For example -- has the firmware been specifically designed to work with the Linux driver or is it generic firmware? If you can't take the thing you're distributing (the combined binary) and extract two works from it (the firmware and the work whose source you are offering), I cannot see how you can claim it's mere aggregation. Now, if the firmware was specifically designed to work with the linux driver, than it *is* a derivative work on the kernel as a whole and the source code should be provided upon redistribution as per GPL section 3 etc. *BUT* this does not preclude Broadcom from stating: our engineers generated by hand the hex codes that make our hardware work. 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. 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. If you only distribute the source to the driver and don't put a GPL notice in the files that contain the firmware data, I think you're okay. I think you're asking for trouble if you distribute a combined compiled/linked driver. Disagreed. DS HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. 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. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
