Fedora Freedom and linux-libre

[Les Mikesell]

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