Alexandre Oliva wrote:
That's a different question, unrelated to how that firmware got into
the device.
I know. I don't understand why you insist on this irrelevant point.
Because I think it is the only relevent point. It is only if the
combined works form a derivative work that restrictions can apply to
the combination differently than the components and whether a
derivative work is formed does not depend on how the components were
distribtuted.
There are various possibilities here, let me summarize the ones that
occur to me, in no particular order:
a. one work is a derivative from the other, and they are distributed
together
b. one work is a derivative from the other, and they are distributed
separately
c. two unrelated works are distributed separately
d. two works are combined into a single coherent work, undoubtedly a
derivative from both, regardless of whether the two works were
originally related, and then the derivative work is distributed
e. two unrelated works are distributed together by mere aggregation in
a single volume of storage or distribution medium
If I understood your argument correctly, you appear to be proposing
that, because cases such as (a-c) exist, the case at hand can't be
(d), so it must be (e). I don't see how this conclusion can follow
from the premises. Please clue me in?
I'm proposing that in this scenario, if d is true, b would also be true
if they weren't combined, so the transient combination for distribution
is irrelevant. And if b wouldn't be true, then you are left with e.
It's about a derived work - which the FSF says is the same regardless
of the way the parts are distributed.
Err... I thought you didn't agree it was a derived work. If you
agree that it is, then the terms of the GPL are clear, and there's no
reason for us to be holding this discussion.
I don't, but there are different interpretations. I don't see how the
FSF stance on user-linked libraries would differ from code in ROM or
pre-loaded firmware.
We know the GPL imposes restrictions.
We don't. You think you do, but you're mistaken. Go read the GPL
again.
I'm not mistaken. Everything in there except the conditional grant to
use, modify, distribute is a restriction.
Like what? Tell me *anything* you could do in the absence of the GPL,
that, by accepting the GPL, you can no longer do.
Given (or knowing about) a library not covered by the GPL, I can write
and distribute original work that uses the functions provided by that
library, knowing that anyone can obtain their own copy of by my code and
the additional library and use them together. Similarly, I can write
code that uses the services of libraries covered by different licenses
in the same work, or include code covered by less restrictive licenses.
If a single line of the work is covered by the GPL, none of those
things are possible, and a near-infinite set of combinations are
prohibited from being distributed.
divisive nature of the GPL.
Another fallacy. "You can redistribute under the same license"
doesn't divide, it has quite the opposite effect. It's permitting
redistribution under any licenses that may lead to forks, including
ones that don't permit further modifications.
You can't permit redistribution of something you have prohibited from
existing in the first place. You are talking about the things that can
exist. I'm talking about the ones that could exist without the GPL
restrictions.
If you could, you would be able to add a component to a GPL'd work
that links to a commercial library that the end user is expected to
obtain separately.
But you can do that already, as long as the commercial library is
licensed under a GPL-compatible license. Or did you mean to imply
that I'm not going to get my next pay check, and that the ones that
preceded it are just a figment of my imagination? :-)
Make that s/commercial/proprietary/, pretty please. Don't feed the
FUD machine.
s/commercial/non-GPL/. The GPL is just as divisive regarding other code
that permits redistribution if its requirements are different at all,
for example the original BSD license which is about as far from
proprietary as you can get.
But whether it is aggregation or not doesn't depend on the container
or packaging for distribution - it is a separate concept.
Now you lost me. Can you try to rephrase the point you're trying to
make here in relation with my paragraph above, perhaps using other
words and more sentences? As in, what is this separate concept of
'aggregation' you're talking about, and how does it compare with 'mere
aggregation in a volume of storage or distribution media'?
How the bits are stored isn't what determines whether a derived work is
involved or not. I agree that the separation would be more obvious if
the bits were not embedded as data in the kernel in whatever format the
compiler decides to use, but it is just a technical detail if they are
in a separate file or contained within a tar/zip/jar archive or
pre-loaded by something other than the kernel. This is a mechanical
difference, not related to creativity. You could probably modify the
compiler to store data in a separate file instead of whatever embedded
memory-loading format it currently uses but it wouldn't change the
copyright status of the output.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
