[Click] Click License Questions

[Beyers Cronje]

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
> 
>