Re: How long is it acceptable to leave *undistributable* files in the kernel package?
> Brian Thomas Sniffen <firstname.lastname@example.org> writes:
>> Michael Poole <email@example.com> writes:
>>> I expect that if a contributor has an uncommon interpretation of the
>>> license requirements, he should check.
>> I suspect that few people think a GPL'd installer of Microsoft Word
>> would be compliant with the GPL. That's a reasonable analogy, right?
>> A hardcoded string, copied to some device which runs it, and maybe
>> with some additional setup.
> The installer can be GPLed, sure. Why shouldn't it be? You will
> likely run into other copyright issues because you do not have
> permission to redistribute Microsoft Word like that, but it is
> irrelevant to the GPLness of the installer.
But why do I have permission to distribute the GPL'd installer that
way (let's say it incorporates Emacs for some reason)? This isn't
mere aggregation -- it would be if the files were next to each other
on a CD and otherwise unrelated, but it's clear that there are
dependencies between them.
>>> On top of that, one of the earliest places I can find that Richter
>>> contributed code was in ... reworking the USB serial device support
>>> (the very thing he complained infringed his copyrights). It makes me
>>> wonder if he took debate lessons from debial-legal -- or vice versa.
>> Your repeated insults to the people here are not convincing anyone.
>> Do they help you reason better? If not, I suggest that they are
> They are calculated to try to get the people here to apply reasoning
> rather than their usual patterns of assuming they are the governing
They govern their own actions. The Debian developers here are
reasonably well-respected by the actual authorities.
> Andrew declined to back up his legal procedure claims and
> misquoted me in a way he should have known I did agree with; Joe
> rejected an analytical tool I suggested without offering a
> replacement. In both cases it was after I suggested ways they could
> further the debate in a way I thought would be productive. There is
> only so far I will go to support rational argument when others refuse.
>> To put this in more concrete terms: the copyright holder for some of
>> the code Debian distributes claims that his license is being
>> violated. What do you suggest we do? It appears that you suggest we
>> ignore him or tell him that his interpretation of copyright law is
>> incorrect. That doesn't seem very nice.
> It is not his interpretation of copyright law, but his interpretation
> of the license, that is incorrect.
It's a unilateral license. It can't mean anything but what he intends
it to mean.
> Telling him that may not be nice, but nobody suggested the right way
> to deal with SCO was being nice to them, either. If someone insists
> that his copyright is being infringed, we should stop distributing
> *his* code. It is not fair to other parties that his complaints
> should cause the removal of their code.
I think the UW is the right comparison, not SCO -- who are incorrect
in their understanding of the law. But I, and others here, are
persuaded by the arguments that non-free firmware in the kernel is
unacceptable. I'm further persuaded by the arguments that
GPL-incompatible firmware in the kernel is unacceptable, and a
violation of the license under which Debian distributes most of the
kernel source. I see code written to load that firmware specifically,
with curlicues and features designed to work with that
GPL-incompatible code. That says to be pretty strongly that the
kernel containing the firmware is a derivative work of the firmware.
Sure, you can clip the firmware out and use it separately, and that's
not derivative of the kernel -- but I don't think that's important.
I am prepared to be convinced otherwise, but, well, I'm a
consequentialist. If your thesis guts the GPL, then your thesis is
Can I put a GPL-incompatible icon into Emacs, then, such that it's
displayed by X as the minimized form? Or would that violate the GPL?
Can I include a GPL-incompatible elisp script with Emacs?
Brian Sniffen firstname.lastname@example.org