Re: non-free but distributable packages and kernel firmware
Scripsit Sven Luther [EMAIL PROTECTED] dfsg-freedom-of-all-runnable-programs dfsg-freedom-of-all-main-cpu-runnable-programs Euh, what are those two last ones ? They are for users who have decided that they do not care about the freedom of documentation and/or programs that run on auxiliary processors. -- Henning Makholm No one seems to know what distinguishes a bell from a whistle. -- 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
