Hi
Planet GNOME points to this bug now which is apparently non-redistributable firmware being included in Ubuntu for quite sometime. Just a heads up to make sure we aren't having the same problem.
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/223212
Rahul
On 04/26/2009 04:29 AM, Rahul Sundaram wrote:
Hi
Planet GNOME points to this bug now which is apparently non-redistributable firmware being included in Ubuntu for quite sometime. Just a heads up to make sure we aren't having the same problem.
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/223212
I'm 99% sure we're not carrying these firmware files. Ubuntu seems to be manually adding these firmware files (as recently as 04/02/09) to their packaging.
If we find these non-redistributable firmware bits anywhere, we'd remove them.
~spot
On Apr 26, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
If we find these non-redistributable firmware bits anywhere, we'd remove them.
What if one piece of firmware is licensed under:
* This file contains firmware data derived from proprietary unpublished * source code, [...] * * Permission is hereby granted for the distribution of this firmware data * in hexadecimal or equivalent format, provided this copyright notice is * accompanying it.
and another piece of code, copyrighted by the same party, says:
* [...] this software is licensed to you * under the terms of the GNU General Public License version 2 [...] * * Notwithstanding the above, under no circumstances may you combine this * software in any way with any other $PARTY software provided under a * license other than the GPL, without $PARTY's express prior written * consent.
Which of the two should be taken out so that the other can be redistributable? Perhaps the latter, given that it's a driver under a license that's not even compatible with GPLv2?
On 04/29/2009 03:04 AM, Alexandre Oliva wrote:
- [...] this software is licensed to you
- under the terms of the GNU General Public License version 2 [...]
- Notwithstanding the above, under no circumstances may you combine this
- software in any way with any other $PARTY software provided under a
- license other than the GPL, without $PARTY's express prior written
- consent.
Which of the two should be taken out so that the other can be redistributable? Perhaps the latter, given that it's a driver under a license that's not even compatible with GPLv2?
It depends on whether you consider firmware as software, and currently, in Fedora, we do not.
Please don't start this up again, I have minimal patience for the same tired arguments again and again.
~spot
On Apr 29, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 04/29/2009 03:04 AM, Alexandre Oliva wrote:
Which of the two should be taken out so that the other can be redistributable? Perhaps the latter, given that it's a driver under a license that's not even compatible with GPLv2?
It depends on whether you consider firmware as software, and currently, in Fedora, we do not.
You can't change what a copyright holder meant in its license by twisting the meanings of the words it chose to fit what you want them to mean. That's not how copyright works.
The copyright holder didn't permit the combination of the second piece of code (which, being driver code rather than firmware, is software even under your standards) with the other “derived from proprietary unpublished source code” (does anyone use “source code” for anything other than software, or is this enough of a give-away?)
Please don't start this up again, I have minimal patience for the same tired arguments again and again.
That you're trying to turn this into the same old argument doesn't make it so. It's a different issue. This has nothing to do with mere aggregation of firmware here, or with whether firmware is software or not.
This is about (i) combining two pieces of works of authorship in a way that doesn't comply with the licenses provided by the copyright holder, none of which are under the GPL, and (ii) combining *driver* (rather than firmware) code that's under GPL-incompatible terms with the GPLed code in the rest of the kernel.
On 04/29/2009 01:19 PM, Alexandre Oliva wrote:
The copyright holder didn't permit the combination of the second piece of code (which, being driver code rather than firmware, is software even under your standards) with the other “derived from proprietary unpublished source code”
Given that the copyright holder on BOTH works is the same, unless you have it in writing from the copyright holder that they do not permit this combination, I don't draw the same conclusion as you.
~spot
On Apr 29, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 04/29/2009 01:19 PM, Alexandre Oliva wrote:
The copyright holder didn't permit the combination of the second piece of code (which, being driver code rather than firmware, is software even under your standards) with the other “derived from proprietary unpublished source code”
Given that the copyright holder on BOTH works is the same, unless you have it in writing from the copyright holder that they do not permit this combination, I don't draw the same conclusion as you.
I don't understand your reasoning.
Say I create two works A and B.
I publish A under a permissive license.
I publish B under a license that prohibits its combination with A.
Per your reasoning, you're entitled to publish a combination of A and B.
What gives you the idea that you are?
On 04/29/2009 03:06 PM, Alexandre Oliva wrote:
Say I create two works A and B.
I publish A under a permissive license.
I publish B under a license that prohibits its combination with A.
Per your reasoning, you're entitled to publish a combination of A and B.
If you create work A that is dependent on work B (which you also created), and there is a seeming license incompatibility between A and B, I would generally assume this is not intentional and reach out to you for clarification.
Keep in mind that we're still talking hypotheticals here. If you've got a specific case, lets hear it.
~spot
On Apr 29, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 04/29/2009 03:06 PM, Alexandre Oliva wrote:
Say I create two works A and B.
I publish A under a permissive license.
I publish B under a license that prohibits its combination with A.
Per your reasoning, you're entitled to publish a combination of A and B.
If you create work A that is dependent on work B (which you also created)
False assumption. We're talking about copyright notices in two separate drivers, one unrelated with the other. Even if the drivers were somehow related, I'm pretty sure the driver B is not derived from the firmware in driver A.
The one situation in which there are derived works is that the driver B is derived from Linux, but then it sets forth an additional restriction, which is incompatible with the GPL that governs the creation and distribution of derived works.
Keep in mind that we're still talking hypotheticals here.
No, we're not. You think I made up those license snippets?
I'm talking about two specific network interface driversf
grep for the license notices I posted to find them in the Linux 2.6.29 source tree. (The firmware in driver A moved into firmware/ in 2.6.30-pre, but I haven't checked how or even whether the license notices were adjusted)
On 04/29/2009 05:29 PM, Alexandre Oliva wrote:
grep for the license notices I posted to find them in the Linux 2.6.29 source tree. (The firmware in driver A moved into firmware/ in 2.6.30-pre, but I haven't checked how or even whether the license notices were adjusted)
Look. I'm a patient guy, really, I am. Ask my wife.
That said, I don't have much patience for the "go find the license problem I've cleverly and vaguely pointed out" game. Be specific, be concise, or be ignored.
~spot
On Apr 29, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 04/29/2009 05:29 PM, Alexandre Oliva wrote:
grep for the license notices I posted to find them in the Linux 2.6.29 source tree. (The firmware in driver A moved into firmware/ in 2.6.30-pre, but I haven't checked how or even whether the license notices were adjusted)
That said, I don't have much patience for the "go find the license problem I've cleverly and vaguely pointed out" game. Be specific, be concise, or be ignored.
Given all the opinions you volunteered as to this problem, it was just reasonable for me to assume that you were (i) as aware of the issue as Red Hat legal is, and (ii) misguided as to its seriousness, for people who take legal issues seriously don't go about making guesses and dismissing issues before knowing facts.
Only now has it become clear that you're just making wild guesses, to try to deflect the issue. Wild guesses that, rather than filling in irrelevant blanks, conflict directly with the specific information I offered.
I'm ok with your not wanting my help, but do yourself a favor and, before sticking your foot in your mouth again, have a look at bnx2_fw* and bnx2x_link* in linux-2.6.2*/drivers/net, and talk to legal. I recommend contacting Richard Fontana, he was at Libre Planet where I first spoke about this issue, so he might even be aware of it already.
Good luck,
On 04/29/2009 10:26 PM, Alexandre Oliva wrote:
Given all the opinions you volunteered as to this problem, it was just reasonable for me to assume that you were (i) as aware of the issue as Red Hat legal is, and (ii) misguided as to its seriousness, for people who take legal issues seriously don't go about making guesses and dismissing issues before knowing facts.
My psychic powers not withstanding, you really shouldn't make assumptions. Something about an ass, you, and me...
I was honestly under the impression you were pitching a hypothetical scenario, which is why the "copyright holder" wasn't mentioned explicitly, and you didn't point out specific files.
As to the upstream Linux kernel having firmware, yes, it does. However, rather than hacking it to pieces in Fedora, we'd much prefer to see such cleanup efforts done upstream. But you knew that already, yet you're content to continue beating this long dead horse wherever possible.
I'm really done with it now.
~spot
On Apr 29, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
My psychic powers not withstanding, you really shouldn't make assumptions.
As I wrote, I made them based on your opinions. I honestly didn't expect you to go about making strong assertions without having the faintest clue as to what you were discussing.
I was honestly under the impression you were pitching a hypothetical scenario,
Not enough of a clue that I wrote:
What if one piece of firmware is licensed under:
(note the present tense *is*, not *was*)
and another piece of code, copyrighted by the same party, says:
Which of the two should be taken out so that the other can be redistributable? Perhaps the latter, given that it's a driver under a license that's not even compatible with GPLv2?
And then, why would I add “[...]” to indicate omission of portions from a hypothetical license?
As to the upstream Linux kernel having firmware, yes, it does.
What I don't get is why you keep returning to this point.
The issue is not about firmware.
There are two issues here:
1. combining GPLed Linux code with *driver* (!= firmware) code derived from GPLed code that adds incompatible restrictions => GPL violation, enforceable by *any* Linux copyright holder
2. combining the aforementioned code with code that is explicitly excluded by the GPL-incompatible restriction => copyright infringement enforceable by the very party who set the trap
While you keep focusing on the firmware, these two points that have to do with a driver, not with firmware, fly way over the top of your head.
It is sad that Linux upstream developers are so sloppy with licenses, but unfortunately not all of the problems they bring about revolve around firmware. I honestly wish they weren't so sloppy, it would make for far less legal risk for all of us.
Please take your head out of the sand. If you are the party responsible for looking after this kind of legal problem in Fedora, it's not responsible to declare you're done with this issue just because you don't like another unrelated issue I brought up before, and you pretend it's the same.
Now, you don't have to report anything back to the list or to myself, but please don't fail to do your job just because you can't stand me. It's an important job, and the Fedora community counts on you to do it.
Thanks,
On 04/30/2009 01:09 AM, Alexandre Oliva wrote:
Not enough of a clue that I wrote:
What if one piece of firmware is licensed under:
For what it is worth, when you begin a sentence in English with:
"What if...", it is almost always a hypothetical scenario.
Had you written:
"There is a case in the Linux 2.6.29rc3 kernel (drivers/foo/filename.c) where one piece of firmware is licensed under:"
It would have been much clearer.
~spot
On 04/30/2009 01:09 AM, Alexandre Oliva wrote:
Now, you don't have to report anything back to the list or to myself, but please don't fail to do your job just because you can't stand me. It's an important job, and the Fedora community counts on you to do it.
As to this specific point, separated out specifically, I will repeat myself, perhaps a bit more clearly:
Please point out any _specific_ cases of license issues in Fedora packages to me, bugzilla (FE-Legal), or this list, and I will look into them. When you do so, it greatly aids me when you are able to:
* Specifically point out the precise issue * Note the affected files and package
It took you several emails to accomplish this, and I just don't have enough time to chase "ghost" issues where your personal stance on licensing differs from Fedora's. I have a high degree of confidence at this point that you understand the definitions of Fedora licensing policies.
When information is presented calmly, clearly, and without rhetoric, I continue to look into it. To assert that I am either failing, or at risk of failing in that task is rather insulting, especially given a lack of evidence in that area.
It is also worth considering that the Linux kernel, like X.org and texlive, is a rather special case. We cannot simply remove the entire package without crippling the Fedora distributions, nor is it a place where we can effectively "scalpel" out licensing issues (I know that you disagree on this latter point, but for the purposes of rational discussion, please simply accept that Fedora is not interested in taking such action at this point in time). Our best recourse is to work with the upstream to address these issues. Progress continues to be made in this area.
Keep in mind that it took us YEARS to get X.org to a state where we were no longer tangled up with non-free licenses. I tracked that issue personally for 5 years, Debian tracked it for even longer than that. It will likely take me months to finish simply auditing texlive.
~spot
On Apr 30, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
It took you several emails to accomplish this, and I just don't have enough time to chase "ghost" issues where your personal stance on licensing differs from Fedora's. I have a high degree of confidence at this point that you understand the definitions of Fedora licensing policies.
I'm pretty sure the definition of Fedora licensing policies does not make room for blatant copyright violation, distributing code under GPL+restrictions that is derived from GPL code. And, again, the GPL violation is not firmware, it's driver code (stuff that runs on the primary CPU, per Fedora's definition), in case it isn't clear yet.
When information is presented calmly, clearly, and without rhetoric, I continue to look into it.
Thank you.
I'd appreciate your pointing out where you saw this thing you refer to as rhetoric. If any of us two is guilty of jumping to conclusions, abusing rhetoric and aggressive tone, it's not me. You thought I was going back to an old discussion, and overreacted. Apologies accepted :-) but please try not to do that again. I know I've failed that myself in the past, but it is possible to change. Don't react to the ghosts.
To assert that I am either failing, or at risk of failing in that task is rather insulting, especially given a lack of evidence in that area.
The “I'm done with it” in response to the specific information about the problem was quite a shocking confession of your unwillingness to deal with this particular copyright infringment issue.
Do you understand the consequences of infringing copyrights of code licensed under the GPLv2, such as Linux?
Are you comfortable with Fedora's wilfull loss of its license to distribute Linux, and its inducement for third parties that redistribute Fedora to lose theirs?
Are you comfortable with the idea of having to beg thousands of developers for a new license? And having all of our mirrors and redistributors do the same before they can be legal redistributors again?
It is also worth considering that the Linux kernel, like X.org and texlive, is a rather special case.
Neither X.org nor texlive are under the GPL.
Our best recourse is to work with the upstream to address these issues. Progress continues to be made in this area.
Good. I look forward to seeing progress in rejecting code whose copyright holders derived it from Linux, but refuse to offer it under terms that are compatible with the licensing terms of Linux, rather than becoming their hostages and supporting their attack on our communities and our values.
Best,
On 05/04/2009 09:15 PM, Alexandre Oliva wrote:
I'm pretty sure the definition of Fedora licensing policies does not make room for blatant copyright violation, distributing code under GPL+restrictions that is derived from GPL code. And, again, the GPL violation is not firmware, it's driver code (stuff that runs on the primary CPU, per Fedora's definition), in case it isn't clear yet.
So, to make sure I'm clear (I'm ignoring all of the parts where you fail to be specific, and where you put words in my mouth), the situation you're concerned about is one where:
Someone (you failed to mention who) stole copyrighted code (from someone else, again, you fail to mention who), then added restrictions to the derived work.
I thought maybe you were talking about drivers/net/bnx2_fw.h. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=dr...
But no, everything seems okay there.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=dr...
This has an odd licensing clause, specifically:
* Notwithstanding the above, under no circumstances may you combine this * software in any way with any other Broadcom software provided under a * license other than the GPL, without Broadcom's express prior written * consent.
Is this what you're talking about? (And if so, why couldn't you just &*#$ing say so?)
If it is, this isn't a copyright violation. It's very strange, and I could see the argument that it makes that piece of code non-free, but it is probably something that we could try to address with Broadcom and the owners of the code space, (specifically, Yaniv Rosner yanivr@broadcom.com). Have you reached out to him about your concerns?
See how useful specific details are? :/
~spot
On May 4, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
Is this what you're talking about? (And if so, why couldn't you just &*#$ing say so?)
Message-ID: orfxfsndp8.fsf@oliva.athome.lsd.ic.unicamp.br
[...] it's a driver under a license that's not even compatible with GPLv2?
Message-ID: or4ow7nzrj.fsf@oliva.athome.lsd.ic.unicamp.br
This is about [...] (ii) combining *driver* (rather than firmware) code that's under GPL-incompatible terms with the GPLed code in the rest of the kernel.
Message-ID: orvdonkv36.fsf@oliva.athome.lsd.ic.unicamp.br
The one situation in which there are derived works is that the driver B is derived from Linux, but then it sets forth an additional restriction, which is incompatible with the GPL that governs the creation and distribution of derived works.
Message-ID: or7i12sp6p.fsf@free.oliva.athome.lsd.ic.unicamp.br
1. combining GPLed Linux code with *driver* (!= firmware) code derived from GPLed code that adds incompatible restrictions => GPL violation, enforceable by *any* Linux copyright holder
If it is, this isn't a copyright violation.
Distributing this piece of code derived from GPLed code under any license other than the GPL is not in compliance with the conditions set forth in the GPL for the creation and distribution of derived works. As such, the distribution is unauthorized, and therefore copyright infringement.
It's very strange, and I could see the argument that it makes that piece of code non-free,
I don't know whether it's non-Free, but that's besides the point.
but it is probably something that we could try to address with Broadcom and the owners of the code space, (specifically, Yaniv Rosner yanivr@broadcom.com). Have you reached out to him about your concerns?
Nope.
See how useful specific details are? :/
Not really. All I see is how little of what I wrote in this thread you actually paid attention to before issuing your opinions :-(
The specific details were in the first post. grep is not that hard to use. Heck, even a web search for the licensing terms I quoted would have found all the specific details that, honestly, I was baffled you weren't aware of.
So much for my trying to anonimize the guilty to avoid undesirable reaction. Thanks (not) for pretty much forcing me to change that, just to feed your... What is it? Pride? Laziness? Distrust? :-(
On 05/04/2009 10:23 PM, Alexandre Oliva wrote:
but it is probably something that we could try to address with
Broadcom and the owners of the code space, (specifically, Yaniv Rosner yanivr@broadcom.com). Have you reached out to him about your concerns?
Nope.
Perhaps you should do that as the logical next step.
~spot
On May 5, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 05/04/2009 10:23 PM, Alexandre Oliva wrote:
but it is probably something that we could try to address with
Broadcom and the owners of the code space, (specifically, Yaniv Rosner yanivr@broadcom.com). Have you reached out to him about your concerns?
Nope.
Perhaps you should do that as the logical next step.
That would make sense if people in general could set apart message from messenger. In my experience, few people do :-(
My reasoning is that it would be better for someone who's less likely to evoke a hostile reaction. Because of some of my beliefs, people tend to assume I'm saying or writing things I'm not, assume everything I do is about one particular issue, and react explosively to their faulty assumptions. I've seen that stuff quite recently ;-)
So, no, I'm not going to spoil that possibility by trying to do it myself. I've already got a fix for the problem that I'm reasonably happy with. Fixing it upstream, where such fixes are not wanted, is your preference, not mine, so I'll leave that for you to pursue.
Thanks,
On Apr 29, 2009, Alexandre Oliva aoliva@redhat.com wrote:
On Apr 26, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
If we find these non-redistributable firmware bits anywhere, we'd remove them.
Now how abuot we let test your assertion above :-) with another concrete case?
drm-nouveau.patch, applied to Fedora kernels, contains GPU microcode that, according to comments in the patch, were extracted from the non-Free nVidia drivers, in spite of the non-reverse engineering provisions of the license nVidia grants its customers, and, regardless, copied in a way that is not permitted by that license, possibly without permission from the copyright holder.
http://www.nvidia.com/object/nv_swlicense.html
2.1.2 Linux/FreeBSD/OpenSolaris Exception. Notwithstanding the foregoing terms of Section 2.1.1, SOFTWARE designed exclusively for use on the Linux or FreeBSD operating systems, or other operating systems derived from the source code to these operating systems, may be copied and redistributed, provided that the binary files thereof are not modified in any way (except for unzipping of compressed files).
http://cvs.fedoraproject.org/viewvc/devel/kernel/drm-nouveau.patch?revision=...
+/* These blocks of "magic numbers" are actually a microcode that the GPU uses + * to control how graphics contexts get saved and restored between PRAMIN + * and PGRAPH during a context switch. We're currently using values seen + * in mmio-traces of the binary driver. + */
I doubt the use of mmio traces to obtain a piece of code makes the code exempt from copyright, and I don't see any grant of permission to distribute those copyrighted pieces of code on their own.
And, before you get too excited about their being so small, search for nv50_grctx.h in that same patch, and you'll see a much bigger problem.
Now, don't get me wrong. I fight for software freedoms, including the freedom to modify and distribute software, regardless of whether it's Free. I wouldn't want to oppose the freedom to distribute any software whatsoever, even such harmful software as non-Free Software.
However, if you want to abide by the unjust laws that are in effect, and by the policies the Fedora community agreed upon (and by your statement above), I don't see how you could proceed with the distribution of that software (even if you regard it as non-software, but rather firmware) once you become aware of the problem.
Now, it could be that the authors of the patch (I know nothing about them) live under jurisdictions in which prohibitions on reverse engineering are not enforceable, and in which copyright can't be used to prevent the distribution of these pieces of code.
But would this make their distribution permitted in more draconian and lawyer-ridden jurisdictions, or would Fedora be putting itself and its redistributors at the mercy of nVidia's legal department?
Hopefully the authors got any permission needed from nVidia. But there's no evidence of that in the patch, and I don't know for a fact that they did. Do you?
On 05/05/2009 09:29 AM, Alexandre Oliva wrote:
Hopefully the authors got any permission needed from nVidia. But there's no evidence of that in the patch, and I don't know for a fact that they did. Do you?
Yes. NVIDIA is aware of their usage. Red Hat Legal advises that there is no concern here.
~spot
On May 6, 2009, "Tom "spot" Callaway" tcallawa@redhat.com wrote:
On 05/05/2009 09:29 AM, Alexandre Oliva wrote:
Hopefully the authors got any permission needed from nVidia. But there's no evidence of that in the patch, and I don't know for a fact that they did. Do you?
Yes. NVIDIA is aware of their usage.
Being aware is not quite the same as granting permission for it. Like, a patent holder might be aware of usage of some of their patents, but wait a long time before lauching a patent attack, so that it becomes more difficult for the defendant to stop using the technology. I can see the same strategy would be effective with copyrights.
Red Hat Legal advises that there is no concern here.
Could we perhaps get an explicit license from nVidia, and put it in the patch so that people are aware that there's no legal trap being set?
Thanks,
-
Alexandre Oliva -
Rahul Sundaram -
Tom Callaway