On Wed, Aug 19, 2015 at 8:31 AM, Jeremi Piotrowski <jeremi.piotrow...@gmail.com> wrote: > On Wed, 19 Aug 2015, Rich Freeman wrote: > >> It sounds like you not only expect them to comply with the license, >> but also with the kernel devs personal interpretation of copyright >> law. > > What is a license but a statement of the intent of the authors as to what > can and can't be done with their work? Well, it does have some legal force > too...
The only reason that licenses matter at all is that they have legal force. They only matter to the degree that they do. If I went around selling licenses to drive cars, anybody who bought one would be a fool. I have no rights to sell such licenses, and they have no legal requirements to buy one from me. Likewise, the fact that the kernel authors WANT to control linking to their code means absolutely nothing. They have no legal right to do so, any more than a shovel manufacturer has the right to dictate what kinds of holes I dig. > > If you'd try to take away their right to decide about that next thing > they'd do is modify the license to be even larger and explicitly cover all > corner cases. And that would accomplish nothing, since companies would just ignore any text which doesn't have a basis in law. > > That has always been the issue but I'll allow myself to quote an email > on the matter: > From: Linus Torvalds <torva...@osdl.org> The problem is that Linus's words mean nothing unless they're based in law. You don't need to quote Linus. You need to quote laws, court decisions, or treaties. And none of them say a word about linking creating a derived work. And would we really want to live in a world where they did? Do you really want to need permission to use a product in a manner the author didn't originally intend? > > Apparently the Linux foundation considers some pieces to be *clearly* > GPL-only and these are marked as such. And I don't see a way for vendors > around this other than to avoid the usage of such symbols Why not just write API wrappers? If somebody exposes an API called do_this() using EXPORT_SYMBOL_GPL just write a module that is licensed GPL, exposes an API called do_this_nonGPL() using EXPORT_SYMBOL, and have do_this_nonGPL() just pass through a call to do_this(). This is a trivial measure to circumvent, as far as a I can tell. It is just a PITA to deal with. What is next, randomizing all the function/variable names on each new kernel release so that it is impossible to maintain any kernel code outside of the tree? Then we'll have smart configure scripts for external modules that try to determine the right name to use and wrapper header files. > > Who wants to go court when the current scheme is effective. The whole > issue of "derivative work" is more applicable to binary kernel modules > anyway. In this case we have the source code, and the kernel module build > system will not allow a module that claims a certain license to use > certain symbols. They (vendors) can: > > a) change their license to say "GPL" but then people would be allowed to > demand full source code from them including binary blobs. All they have to do is have the human-readable license say non-GPL, and have it report GPL to the kernel, and not ship the source. The only recourse anybody has is to sue them, and it is doubtful that a court is going to force them to comply, as they clearly indicated their intent to not release the code as GPL. You might be able to get away with redistributing the blob since the situation is a bit ambiguous, but I doubt the driver manufacturers care that much if you redistribute their blobs. I remember a fiasco a few years ago when a vendor exported the license as something like "GPL\0 does not apply." > > b) apply the patch you posted - not really practical, definitely > wouldn't be popular but I don't really see how that would be illegal. > Full GPL would apply to the kernel anyway. > > c) avoid the usage of such symbols. > > and they will do c) because they really don't have a choice. > As I pointed out they can just write a wrapper that exports GPL and re-exports all the symbols. Also, you stated that the check is implemented in the build system. I don't know if that is true, but if it is, then the module can simply be built using a patched build system. I suspect the check is really in the module loader, which the module builder would not have control over. -- Rich
