On Thu, Apr 15, 2004 at 05:25:30PM -0400, Allan Wind wrote:
> On 2004-04-15T16:04:30+1000, Anthony Towns wrote:
> > The right thing to do is to fix the drivers so they load the firmware
> > from userspace so that the GPL is clearly not violated, using the existing
> > API to manage that. This can be done for most drivers after the system's
> > booted, and for most other drivers from the initrd.
> I do not understand why changing the dependency from compile-time to
> run-time makes any difference.
Not understanding legal issues is off-topic for -devel. Any followups
should be made to -legal. M-F-T set accordingly.
Because when you have a compile-time dependency you create a derived
work -- vmlinuz -- of both the GPLed work and the firmware. Creating
derived works is an act covered by copyright, and can only be done with
the permission of the rights holder; and if the only permission you have
comes in the form of the GPL, then you're required to make available
the complete source to the entire derived work.
By contrast, if you only make use of the firmware at runtime, you don't
create any such derived work; vmlinuz and /lib/firmware/tg3 (or wherever
it goes) remain separate works. [0]
> If we cannot distribute the source with
> the embedded firmware, then we cannot distribute the firmware alone
> either unless the licenses is clarified (GPL is no good, as it violates
> clause 3).
No, it doesn't violate clause 3, because you're providing the complete
source to the object code you're distributing.
> And to expand on aj's later thread, how can GPL cover
> derrived work when that work contradicts the license?
If a derived work of something licensed under the GPL can't be distributed
under the GPL, it can't be distributed at all.
> No one has negotiated with upstream, right?
One of the reasons I'd been avoiding this issue is that people tend not to
bother listening about these topics.
Debian's raised this issue with linux-kernel upstream years ago; and
they've followed up on it since by providing an API for dealing with the
problem. A number of upstream types have been made aware of the problem,
but in most cases there's not that much to be done; GPLing firmware
isn't that high a priority, and relicensing the kernel isn't much of an
option either.
On Thu, Apr 15, 2004 at 06:45:03PM -0500, Steve Langasek wrote:
> FWIW, this is my impression as well; but it doesn't look like there's
> still pressing concern about GPL compatibility here, just about
> DFSG-compliance,
Uh, I've no idea where you pulled that from, but as far as I'm aware
there is still a serious concern about GPL compatability. Again, if
you've got a competent lawyer who's willing to go on record as saying
otherwise, that's fine. If you're just saying "I don't care about it",
or "Red Hat doesn't care about it", that's not really good enough.
Yes, for things like this we do frequently set the bar higher than other
distributions and upstream do, and yes, there are negative consequences
to that.
Cheers,
aj
[0] An argument can be made in the case of symbolically linked libraries
that in some cases separate files aren't enough to avoid creating
a derived work, but the situation for loading firmware doesn't have
the same problems.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
Don't assume I speak for anyone but myself. GPG signed mail preferred.
Protect Open Source in Australia from over-reaching changes to IP law
http://www.petitiononline.com/auftaip/ & http://www.linux.org.au/fta/
Attachment:
signature.asc
Description: Digital signature