On Tue, 2008-06-10 at 10:43 -0400, Alan Cox wrote: > On Tue, Jun 10, 2008 at 02:24:30PM +0100, David Woodhouse wrote: > > Under copyright law, a collective work is a work in which a number of > > contributions, each constituting separate and independent works in > > themselves, are assembled into a collective whole. > > Yes I know that. I'm curious why you think the two independent works are > somehow a collective work. Because they have been assembled into a collective whole; the bzImage file which is distributed and used as a single entity, and which makes use of both the firmware and the GPL'd kernel code. Also, in the case of the source code, because they are integrated into the kernel source and into its build system, and distributed as complementary parts of a coherent whole. > > work itself. That includes the permission, or refusal of permission, to > > include that GPL'd work within a collective work. > > The GPL says: > > "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." > > Last time I checked both disk and RAM are storage media and the two works > appear to be independent. > > I can't find a rational way to interpret it otherwise. I do not find it rational to assert that the above-quoted exception exempts _all_ collective work from the preceding conditions, purely on the basis that it happens to be stored on a 'storage medium'. Such a wide-sweeping exemption would effectively render the preceding two paragraphs entirely redundant. When it speaks of 'mere aggregation on a volume of a storage or distribution medium', I take that to mean things like free and shareware software CDs on the cover of a magazine. Not a blanket exemption for _any_ work which happens to get stored on something we can call a 'storage medium', which would even cover examples like GPL'd programs using proprietary libraries. You effectively seem to be saying "you can do what you like as long as you store it on disk", which is not a reasonable interpretation of the intent of those sections of the GPL. > We get into the world of 'f the program is GPL then the icons are GPL > because they are connected with it. Or games where you'd argue the > music files magically become GPL Again, it would depend on whether the icons, or music files, are distributed as part of a collective whole which is a work based on the Program. There is no fundamental problem here. And nothing "magically becomes GPL". Either it _is_ available under a GPL-compatible licence and you are permitted to incorporate it into a collective work under the terms of the GPL, or not, and you may not do so. There's no magic involved. > Take the cases you think are a collective/derivative and the cases you think are > not and define a test by which this can be ascertained, then perhaps I can > see what you are trying to argue.. As I said, it is a grey area. There is no easy test. We understand what a collective work is, of course, and we can see that the GPL explicitly spells out its intention to extend to collective works based on the Program, and explicitly speaks of its permissions extending to sections of a collective work which are independent and separate works in themselves, but distributed as part of a collective work. The only part which is really subject to interpretation is the part you quoted above, where it grants an exception for "mere aggregation on a volume of a storage or distribution medium". You seem to believe that this exception applies to _anything_ you can store on a hard drive or in memory -- which I don't consider to be at all reasonable because it would effectively render the preceding paragraphs of the §2 entirely pointless, and is obviously not consistent with the stated intent. I believe that exception is intended for things such as magazine cover CDs, carrying a bunch of mostly unrelated software. It _might_ even (and I suspect we should hope that it does) cover Linux distributions with many programs collected together for convenient installation. But when it comes to such things as a bzImage file which contains both a driver for some hardware _and_ the firmware which drives it, and which will not operate on that hardware unless both of those fundamentally intertwined parts are present, I do not believe that is covered by the exception. The test, if a single such test were possible, would probably be something along the lines of whether the works in question were really just bundled together on a hard drive or CD as if by coincidence, or whether they're really interdependent. It would actually make more sense for me to ask the same question of _you_, since your interpretation would seem to be rendering that part of the GPL entirely void. Can you tell us under what circumstances you believe the GPL _would_ extend to something which is reasonably considered an 'independent and separate work in itself', and what _your_ 'test' would be? > Now I'd like to get to that state anyway so that firmware is nicely seperate > from the kernel sources and it is clearer about licenses and what is what. I'm > unconvinced it is neccessary, but I am not a lawyer. As I said, there's no real answer to the question of whether it's "mere aggregation on a volume of a storage or distribution medium" until/unless a court has ruled on it -- and we each seem to think that the other's position is irrational. But I think we can agree that _until_ there's a ruling, including the firmware in the kernel is just a gratuitous risk. At least, I'm _working_ on making it gratuitous, by removing the _technical_ obstacles which have historically made it suboptimal to remove the firmware from the kernel -- and when that's done, it'll just be silly for us to continue to include it. With the CONFIG_BUILTIN_FIRMWARE config option, you _can_ still include arbitrary firmware into your kernel, if you want to take that legal risk. But it'll no longer be the default. -- dwmw2 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
