Alexandre Oliva wrote:
The other is, is the
kernel separate from the device's firmware?
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.
See the history of the fgmp library for the FSF stance on separately
distributed components - although since it happened before internet
search engines were archiving everything it may be a little hard to find
the whole story now.
Execution is not what this is about. The GPL says running the program
is not restricted, and by this it acknowledges that copyright does not
restrict that. I'm talking about distribution.
It's about a derived work - which the FSF says is the same regardless of
the way the parts are distributed. How is using ROM/firmware code
different from adding code to link to or dynamically load a commercial
libray in a GPLed work, then letting the end user get their own copy of
the non-GPL'd library?
Or, what evidence can you provide that the kernel is
an independent work from the firmwares, against the various pieces of
evidence that it is dependent on them?
It's an interesting question, but it doesn't really relate to
copyrights or derived works except in the upside down world of the GPL
restrictions where no legal rulings exist.
1. The GPL doesn't establish restrictions.
If the GPL didn't establish restrictions, it would only be a grant to
use, copy, and redistribute. The rest of that big file consists of
harmful restrictions.
2. This is only *the* important question to tell whether what we have
is mere aggregation or a combined work. Because, again, this is not
about whether the firmware is a separate work, it's whether the GPLed
code in the linux-2.6.whatever tarballs is a separate work. (How do
you name an allegedly separate work that doesn't even have a name of
its own?)
But it is not about how it is distributed. It is whether it becomes a
derived work.
I can't think about that without remembering the time when GPL
software could not have existed without a commercial OS hosting it,
Didn't BSD start before GNU?
Yes, but not before copyright law, which is what this is about.
Sure, it wasn't entirely Free Software
back then, but it was hardly a "commercial OS" (nevermind that its
tapes were also for sale).
Unix has a rather strange history. It was developed in a research
branch of AT&T which at the time was a controlled monopoly that was
prohibited from selling products outside their specific field. They did
sell copies of the source as research projects to universities under the
guise of research. And the universities improved it by adding their own
code, notably tcp and vi. For some time, installing unix meant starting
with the AT&T tapes (at about $20K and only available to universities)
and then adding the BSD patches which were distributed freely. Then
AT&T was split into separate companies, one of which commercialized unix
and rolled in the *BSD improvements to create SysVr4, still overpricing
it to the point that no one noticed. Concurrently, the *BSD developers
were re-writing the core code to replace all original AT&T code so a
working unix could be delivered on the track that became freebsd. BSDI
was actually a commercial company selling what they claimed was an AT&T
code-free version (at a price actually feasible for use and with source
availability), which AT&T disputed.
and that history makes me believe that the GPL itself cannot prohibit
this co-existence even if it is somewhat less necessary now.
The GPL does not prohibit anything. It's copyright law that does.
Copyright law does not regulate co-existence. It regulates copying,
distribution, and the creation of derived works.
gets code from library header files
Using header files as needed to make something work was pretty much
established as fair use in AT&T's failed suit against BSDI years ago.
Yup. That's just using an interface. Not the same as getting code
from library header files, which is what I wrote. Think inline
functions, implicitly-instantiated C++ templates and the like.
Situations in which you end up with copies of significant portions of
the library code in your object files.
But they included the head files which were verbatim copies of the
original values. How do you establish that one set of values are OK but
others aren't?
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. Go read a less restricted
license to see the difference. Perl has an excellent example to counter
the harm and divisive nature of the GPL.
But it doesn't restrict against aggregating other things.
It doesn't restrict mere aggregation, indeed. Mere aggregation does
not require modification of any of the works, so it couldn't possibly
be restricted by copyright the way copyright works today. That said,
copyright law may still restrict the *distribution* of the aggregate.
And it's distribution that I'm talking about.
If the combination is interpreted as a derived work, it doesn't matter
if they are distributed together or not. You still wouldn't be able to
distribute them separately with the intent to recombine them. 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.
And then, we're not talking about mere aggregation. We're talking
about a combination in which at least one of the works had to be
modified to make room for the other, and that, if you take out the
other, it goes kaboom.
Yes, this part is the same even if the firmware is loaded by something
else or already exists in ROM.
For modification, copyright law requires
permission. So, yes, copyright law does restrict acts of aggregation
that are not mere aggregation. (And the distribution of the result,
be it mere aggregation or any other form of collective or derivative
work.)
But whether it is aggregation or not doesn't depend on the container or
packaging for distribution - it is a separate concept.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
