[Click] Click License Questions

[Eddie Kohler]

Hi Beyers,

We'd love to see your global custom elements!  Feel free to make them 
into a package (like the others: models, unibo-qos, ...).

Eddie

On Feb 24, 2005, at 7:13 AM, Beyers Cronje wrote:

> Hi Eddie,
>
> First off, to quote you: "Click's warm, fuzzy C++ sandbox", I would
> like to applaud you with the design and implementation. Click's
> element interfaces really breaches the gap between kernel and user
> space for us.
>
> Thanks for your insights, this is more or less how I understood the
> situation. I should've noted in my original mail that I was
> specifically refering to custom elements we are implementing,
> obviously keeping "core" Click open benefits us all.
> We are even happy to provide source to some of our global
> custom elements, like our global Debug Informational Element.
>
> Kind regards
>
> Beyers
>
> On Wed, 23 Feb 2005 20:08:04 -0800, Eddie Kohler <kohler at cs.ucla.edu> 
> wrote:
>> 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
>>
>>