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 Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote: If you believe the linker merely aggregates the object code for the driver with the data for the firmware, I can't see how you can argue that any linking is anything but mere aggregation. In neither case can you separate the linked work into the two separate works and in both cases the linker provides one work direct access to the other. You can indeed separate the firmware and the kernel into two separate works. That's what people have been proposing as the solution to this problem. Also, mere aggregation is a term from the GPL. You can read what it says there yourself. But basically it's there so that people make a distinction between the program itself and other stuff that isn't the program. It's also there because the GPL can only apply to either works placed under it by their authors and works that are legally classified as derivative. If you merely aggregate two works, there is no derivation. The GPL is making clear that it's not trying to exceed the scope of its authority (which is copyright law). Without that mere aggregation clause, people might be claiming that text on a disk has to be GPLed because of emacs, or that postscript files have to be GPLed because of ghostscript, or more generally that arbitrary object FOO has to be GPLed because of gpled program BAR. They could, but they would still be wrong. Because if you merely aggregate two works, the result is still two works that can each be under their own license. The GPL is only making clear what is outside its authority, but it does not set the scope of its own authority anyway. Put another way, what the linker does or doesn't do isn't really the issue. Well it is. The question is whether you can link two object files together and distribute the result under the license of each independent file, treating it like a disk with two files on it, rather than as a single work. People like to think that the linker is somehow special for copyright, but it's not. Either the stuff being linked is protected by copyright even when it's not linked or it's not protected by copyright after it is linked. If the license says something about linking then that matters, but only for cases where the code was protected by copyright even before it was linked. And then linking only matters in the specific way that that license says it matters. Regardless of what the GPL says, there is a genuine question of whether linking together file A and file B results in a file C that contains the two separate works or is a single work that is derivative of both A and B. This is important because of aspects of copyright law that the GPL acknowledges explicitly but does not get to decide. DS -- To UNSUBSCRIBE, 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.
No-one is saying that the linker merely aggregates object code for the driver; what *is* being said is: in the case of firmware, especially if the firmware is neither a derivative work on the kernel (see above) nor the firmware includes part of the kernel (duh), it is *fairly* *safe* to consider the intermixing of firmware bytes with kernel binary image bytes in an ELF object file as mere aggregation. No, it is completely wrong to say that the object file is merely an aggregation. The two components are being coupled much more tightly than in the situation that the GPL discribes as mere aggregation. Would you maintain this position even if the firmware is identical across operating systems and the Linux driver is identical across different firmware builds for different hardware implementations? Say, for example, Intel comes out with a new super-smart and sophisticated network card. They also offer firmware that makes it look just like an NE2000. They don't create this firmware for Linux, they create it for any set of operating systems that don't have specific drivers for this card. Similarly, the NE2000 driver wasn't specifically designed to use this firmware. Both the firmware and the driver were independently developed to implement the same de facto standard. Now, someone combines the firmware and the driver into a package that checks what card you are using, and if it has the appropriate firmware to make the card work with the driver, uploads it. Note that the issue is not whether the GPL describes this as mere aggregation because the GPL doesn't get to set its own scope. The issue is whether the resulting binary is a single work (that is derivative of the GPL'd driver) or whether it's two works with a license boundary between them. It would not be obviously unreasonable to argue that the NE2000 API constitutes a license boundary between the two works, each of which stays on its own side of that API. Lacking clear court guidance, I see it as a threshold issue. One primary issue (I think) is to what extent that firmware and the driver have been customized for each other. A work that is carefully designed to mesh tightly with another work is analogous to a sequel, which is a derivative work. I think we have a real problem, however, in cases where the source file that holds only the firmware data contains a GPL notice. DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote: The way you stop someone from distributing part of your work is by arguing that the work they are distributing is a derivative work of your work and they had no right to *make* it in the first place. See, for example, Mulcahy v. Cheetah Learning. Er, that's one way, but not *the* way. I could grant you permission to create derivatives of my work, but not to redistribute them. To stop you from distributing them, I'd argue that you had no right to distribute them--you *did* have the right to make it in the first place. You could do that be means of a contract, but I don't think you could it do by means of a copyright license. The problem is that there is no right to control the distribution of derivative works for you to withhold from me. The GPL does this. Note GPL #2b: any work that you distribute or publish. If you don't distribute or publish the derivative work, the work does not need to be licensed ... under the terms of this License. It very carefully separates the permissions granted for merely creating a derivative work, and the permissions granted for distributing those works; if you distribute a linked binary in violation of the GPL, you may very well have had permission to make it in the first place. Yes, but this would be valid if and only if there was a right to restrict the distribution of derivative works that was recognized under copyright law. I can find no record of the existence of such a right. (Of course, if whether the work is a derivative is in question, that would need to be established--you would, indeed, need to argue that the work they are distributing is a derivative work--but you wouldn't necessarily further argue that they had no right to make it in the first place.) Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. DS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On 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.
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 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.
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.
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]
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: How long is it acceptable to leave *undistributable* files in the kernel package?
But wait; firmware is *not* linking with the kernel, as the icons are *not* linking with emacs. Or are they? What is linking? If you consider linking to give names fixups and resolving them, well, the char tg3_fw[] = ... is linked with the kernel all right. If you consider that a call (as in the asm CALL opcode sense) must be made, it's not. The firmware does not execute, at least in the main CPU. Anyway, the non-GPL-compatibly-licensed icon in your previous emacs example is *most* *certainly* not linking with emacs (in the ld-or-ld.so sense) and it's OK. The (simplified) answer: the GPL do not link is weak because of the mere aggregation clause and because of the dichotomy between derivative and anthology works; it's weaker in the case of the binary kernel modules, especially if they are not distributed with the kernel (the linking is done at the end user, where many things are possible); it's even weaker in the case of firmware (because firmware does not /properly/ link in the software sense, even if it *does* link in the ld-or-ld.so sense); it's really faint in the case of an accompanying icon or image (or movie: eMovix comes to mind). I think there's a continuum here. If, for example, the firmware in the Linux kernel is identical to the firmware in the Windows driver and the Linux kernel contains no special code to talk to this firmware (in other words, the firmware makes this device look like every other similar device and the kernel contains a generic driver), then the 'mere aggregation' argument is persuasive. We have two independently derived works that happen to be combined in a single file. They each happen to implement the same interface from opposite sides, but they do so for different reasons and are not specifically designed to work as a unit. On the flip side, if the Linux kernel code were developed just to talk to this firmware and this firmware were developed just to make this device work with Linux, then the 'mere aggregation' argument seems ludicrous. Each work is specifically designed to work with the other, they aren't just combined after the fact. The two had to have been developed together and each has portions that only make sense in combination with the other. There are, of course, points in the middle of the continuum. I personally have no issues with the lack of the preferred form for the purposes of making modifications. I don't find that fight worth fighting in any case. I do, however, have major issues with use restrictions and distribution restrictions. Code that cannot be freely used, reverse engineered, modified, used on whatever hardware or with whatever software, or distributed subject only to the GPL restrictions should not be integrated into the Linux kernel. These restrictions cut to the heart of the very freedoms the GPL is supposed to protect. DS PS: Please CC me on any replies that you wish me to read and possibly reply to.
