[Click] Click License Questions

[Eddie Kohler]

Hi Beyers,

Well, hm.  Linus's thoughts on this matter have evolved since 
1999-2000.  (His thoughts matter as he is Linux's copyright holder.)  
Here's the most relevant text (found via 
http://kerneltrap.org/node/1735):

> And in fact, when it comes to modules, the GPL issue is exactly the 
> same.
> The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
> anything that is a derived work has to be GPL'd. It's that simple.
>
> Now, the "derived work" issue in copyright law is the only thing that
> leads to any gray areas. There are areas that are not gray at all: user
> space is clearly not a derived work, while kernel patches clearly _are_
> derived works.
>
> But one gray area in particular is something like a driver that was
> originally written for another operating system (ie clearly not a 
> derived
> work of Linux in origin). At exactly what point does it become a 
> derived
> work of the kernel (and thus fall under the GPL)?
>
> THAT is a gray area, and _that_ is the area where I personally believe
> that some modules may be considered to not be derived works simply 
> because
> they weren't designed for Linux and don't depend on any special Linux
> behaviour.
>
> Basically:
>
>  - anything that was written with Linux in mind (whether it then _also_
>    works on other operating systems or not) is clearly partially a 
> derived
>    work.
>
>  - anything that has knowledge of and plays with fundamental internal
>    Linux behaviour is clearly a derived work. If you need to muck 
> around
>    with core code, you're derived, no question about it.
>
> Historically, there's been things like the original Andrew filesystem
> module: a standard filesystem that really wasn't written for Linux in 
> the
> first place, and just implements a UNIX filesystem. Is that derived 
> just
> because it got ported to Linux that had a reasonably similar VFS 
> interface
> to what other UNIXes did? Personally, I didn't feel that I could make 
> that
> judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
> area.
>
> Personally, I think that case wasn't a derived work, and I was willing 
> to
> tell the AFS guys so.

What does this mean?  Maybe that parts of Click should be distributed 
under the GPL -- in particular, the contents of linuxmodule/, 
elements/linuxmodule/, and the parts of include/ and lib/ that 
interface directly with the kernel.  (We always intended for the kernel 
patches in etc/ to be under the GPL, although I'm not sure where this 
is written in the source.)

However, elements can be distributed under whatever license you choose, 
as long as they work within Click's warm, fuzzy C++ sandbox.  Since 
your elements will then compile and run equally well at user level or 
in the kernel, and were written with Click's interface in mind (and 
Click's interface is clearly *not* derived from Linux's), they would 
not be "derived works" of the kernel.  (Yes of course there could be 
exceptions.)

I may or may not change Click's documentation to reflect this 
closely-parsed nonsense.  Most likely not.

Eddie


On Feb 23, 2005, at 6:48 AM, Beyers Cronje wrote:

> Hi,
>
> After reading over the Click License file and Eddie's comments on post
> https://amsterdam.lcs.mit.edu/pipermail/click/2001-May/000470.html it
> seems like one is allowed to distribute Click as a product in binary
> format only.
>
> Can anyone shed some light on the legality of running a closed source
> binary-only Linux module ? I've found different views on this through
> google searches, so I'm a bit confused.
>
> Anyone on this list using Click in a commercial product that can shed
> some light on this ?
>
> Do companies like Mazu run Click under Linux or BSD ? Are their
> products open or closed source ?
>
> Kind regards
>
> Beyers
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click