3:29 a.m.
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
7:27 a.m.
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
2:04 a.m.
On Apr 26, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
7:13 a.m.
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
12:19 p.m.
On Apr 29, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
12:42 p.m.
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
2:06 p.m.
On Apr 29, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
2:47 p.m.
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
4:29 p.m.
On Apr 29, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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)
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
5:09 p.m.
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
9:26 p.m.
On Apr 29, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
9:55 p.m.
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
12:09 a.m.
On Apr 29, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
7:57 a.m.
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
8:08 a.m.
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
8:15 p.m.
On Apr 30, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
8:53 p.m.
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...
But no, everything seems okay there.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f...
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(a)broadcom.com>). Have you reached out to him about your concerns?
See how useful specific details are? :/
~spot
9:23 p.m.
On May 4, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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(a)oliva.athome.lsd.ic.unicamp.br>
[...] it's a driver under a license that's not even compatible with
GPLv2?
Message-ID: <or4ow7nzrj.fsf(a)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(a)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(a)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(a)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? :-(
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
6:20 a.m.
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(a)broadcom.com>). Have you reached out to him about your
> > concerns?
Nope.
Perhaps you should do that as the logical next step.
~spot
9:11 a.m.
On May 5, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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(a)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,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
8:29 a.m.
On Apr 29, 2009, Alexandre Oliva <aoliva(a)redhat.com> wrote:
On Apr 26, 2009, "Tom \"spot\" Callaway"
<tcallawa(a)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?revisi...
+/* 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?
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
7:15 a.m.
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
2:49 p.m.
On May 6, 2009, "Tom \"spot\" Callaway" <tcallawa(a)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, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
5469
days inactive
5479
days old
22 comments
3 participants
participants (3)
-
Alexandre Oliva -
Rahul Sundaram -
Tom Callaway