Scenario:
Joe manufactures and sells a product, lets say a firewall, around an x86
CPU or whatever, and a flash-rom disk containing software. The software
consists of the linux-kernel (maybe with some changes), some
kernel modules containing drivers for hardware in the box, some
applications he got from the net under GPL, and some of his own
applications (not based on anything else).
Joe obviously makes his kernel changes public, and any changes in GPL'ed
applications he has used.
However that leaves ambiguity regarding the modules, and his own
applications.
Lets say that he really cannot make OSS of one of his own applications
because he got it for use in his product under a restrictive license.
And he cannot make OSS out of one of the kernel modules because he got the
driver under a weird license from the guys he bought one of the HW
interfaces from, and added some linux wrapping code around it. This is
unfortunately a realistic scenario, speaking from own experience.
Is Joe in trouble ? I can't see any real reason for him not to being able
to keep his application "secret", since the kernel GPL explicitely doesn't
affect applications running on top, and the other GPL'ed applications
can't contaminate because they are a "mere aggregation" (just a collection
of programs doing what they are intended to do).
As for the driver module, I know that Linus has expressed (with some
reluctancy) that drivers that can be considered sufficiently stand-alone
works (like Joe's driver) can be released in a binary fashion. HOWEVER, in
this case it's not a case of just releasing the driver, Joe is actually
shipping it in a product that runs out of the box with it. What is your
interpretation of this ?
It is also possible that someone would say that since Joe is actually
shipping a complete product with all software together on a flash disk, he
needs to make _everything_ OSS. I'd think the "aggregation" clause and
Linus exception re. applications would conflict with that interpretation
though.
Thanks for any clarifications
Bjorn W
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/