[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Fedora Freedom and linux-libre

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

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

b. one work is a derivative from the other, and they are distributed

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

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 gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]