Re: Why are mkisofs ISO's so large?

On 2012-01-26, Richard Kettlewell <rjk@xxxxxxxxxxxxxxx> wrote:
unruh <unruh@xxxxxxxxxx> writes:
Richard Kettlewell <rjk@xxxxxxxxxxxxxxx> wrote:

The idea that the kernel's licence *would* cover user programs is
bizarre, but in this case, there's no need to entertain that idea,
since the owners have explicitly ruled it out. End of.

How is it bizarre?

For instance: if running a program under Linux makes it a derivative
work of the Linux kernel, then a Windows program run for the first time
using WINE, or a CIL program run using Mono, or a shell script written
in 1885 and run today under Bash, would suddenly become a derivative
work of Linux.

That may be something you do not want, but it is hardly bizarre.
In your case, the derivative program would be the program which was
linked with Linux kernel-- it is the whole thing which would then be
derivative, not the original program itself. "derivative work" is a
statement about the work, not about anything the work depends on.


Derivative works are precisely that, works which rely in some ill
defined way on other works. Would a court regard a user program which
uses kernel calls as derivative works?

The usual interpretation (for instance, the one adopted in US law) is
that a derivative work is one based on another. User programs are not
(in general) based on the kernel.

Well, that is the question. Is the work reliant on the other work? For
example it is almost certainly the case that a linux distribution is a
derivative work of the kernel, since clearly the distribution would not
work at all without the kernel.
"Based on" can be incredibly vague. Thus a movie "based on" a book, but
totally different from the book can still be a derivative work with
respect to the book. Totally different medium, different story...

Remember that the "work" in this case is the whole thing, the program as
linked with the kernel routines. The program itself may not be
derivative, but the thing actually run, the program linked with the
kernel, could be. (Part of the problem is exactly that "derivative work"
is so badly defined by the act that what is and is not a derivative work
is extremely unclear. This means that the courts would have to decide
it. And because it is so unclear the precidents are all over the
place,and may well contridict each other.



I hope not, but it could well do so. At the same time the Debian
people claim that cdrtools is incompatible with the GPL and thus
cannot be included in the distribution? Under what legal theory? The
only one is that of "derivtive work". Ie, it is Debian which it seems
to me is expanding the definition of derivative work way beyond where
I would want it to apply ( and where Jorg thinks it applies).

I don't in any way speak for Debian but their position as I understand
it is that distributing the executable would require complying with both
the GPL and CDDL simultaneously. That's not possible.


The same is true of GPL3 and GPL2, and most other licenses with respect
to each other, if the licenses are read strictly enough. Schilling would
claim that one can in fact comply with both because those features of
the GPL which would be problematic are in fact beyond the right of the
license to control. For example, if a software license said that the
licensee had to sacrifice his firstborn to use the program, and the CDDL
said that the firstborn had to be the one to run the program, this might
seem in conflict, but would not be, because those terms in the licenses
were illegal and thus of no force. The licenses would not in legal fact
be in conflict as licenses.


.

Relevant Pages

  • Re: Newbe -Linux - licensiing & hardware
    ... It is certainly the case that if you use something that is not covered by the header files, then you are creating a derivative work and need to put it under the GPL. ... Thus a normal Linux application can happily #include system headers while using whatever license it wants. ... But Linux kernel modules are a special case - they are their own unique shade of grey. ... In particular, it is a perfectly reasonable interpretation of the GPL to say that since modules form part of the same address space as the rest of the kernel, they are combined together to form a single executing program. ...
    (comp.arch.embedded)
  • Re: GPL vs non-GPL device drivers
    ... proprietary modules loaded into the kernel. ... written specifically for linux but distributed as ... If they are a derivative work, they are illegal under the GPL. ...
    (Linux-Kernel)
  • Re: Why are mkisofs ISOs so large?
    ... if running a program under Linux makes it a derivative ... I don't know of too many apps that link with the kernel except glibc. ... that a derivative work is one based on another. ... The same is true of GPL3 and GPL2, and most other licenses with respect ...
    (comp.os.linux.misc)
  • Re: Open Source License Question
    ... IMO the problem with the licenses ... What is a derivative work? ... Istvan. ...
    (comp.lang.python)
  • Re: just SCO but look at FSF....
    ... >licenses included a clause demanding that any derivative work ... >(enhancements and bug fixes) performed by the licensee must be ...
    (comp.unix.sco.misc)