Re: Is sharpzdc_cs.o not a derivitive work of Linux?

[Mark Jenkins <umjenki5@cc.umanitoba.ca>]

Rob,

It is wonderful that a day will come when most modules will need to use
a symbol with attached documentation that says, "if you this symbol,
your code will be a derivative work, and by extension you must license
it under a GNU GPL compatible license".

A cynical person would respond to this and say "if somebody comes along
and uses one of those symbols in a proprietary module, the Linux
developers will let them get away with it".

I hold no such cynicism. I believe the Linux developers would act to
enforce their license in such a case.

This high regard that I have for the Linux developers is why I'm willing
to raise questions about a "binary only" module, despite the fact that
it doesn't use any symbols labeled EXPORT_SYMBOL_GPL. Linus makes it
clear that one can not conclude that he and others will say such a
module is *not* a derivative work. His position was that modules *are*
derivative works, unless a strong counter argument is made.
(see http://people.redhat.com/arjanv/COPYING.modules)

Therefor, if the Linux developers are faced with a module like
sharpzdc_cs.o, and if they conclude that good evidence is unavailable
that it is *not* a derivative work, I believe they would be willing to
listen to a complaint that their license of choice is not being
followed, and act on that complaint if they felt it was valid.

I will reply again later with an attempt to compare the criteria
available here:
http://people.redhat.com/arjanv/COPYING.modules
against the behavior of sharpzdc_cs.o and Sharp's distribution behavior.

In particular, I would like help with this part of it,
"anything that has knowledge of and plays with fundamental internal
   Linux behavior is clearly a derived work. If you need to muck around
   with core code, you're derived, no question about it.
"
as I am not a Linux hacker.


Mark Jenkins
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/