dual licensing for libbusybox

[Jim Thompson]

Kevin Dankwardt wrote:

>In my experience, the generally accepted view, and the whole reason and distinction of LGPL vs. GPL is that when an application links against a GPL library it is considered to be derived from that library. Thus, linking against a library whose only license you have is GPL, means you must GPL your application. 
>  
>
Just saying "linking" isn't clear.   proprietary programs staticly
linked against GPL licensed libraries will be considered a derived
work.   Those same programs *dynamically linked* against GPL licensed
libraries are not.  (Otherwise, Oracle would be 100% open source now.)

>The LGPL is interpreted to mean that if you merely link against it (and dynamically, not statically at that), you need not GPL your application. This distinction is commonly used throughout industry and prevents the use of GPL libraries by many.
>  
>
I think you're incorrect in the paragraph above.

>The inclusion of header files, (kernel or otherwise) is a point of contention. Merely referencing types and prototypes seems to be widely acknowledged to merely programing to the API - it implies no derivation. However, when one includes a header file that has an inline function or macro there is debate over whether your application is derived from that. Some say that header files should be LGPL for that reason. However, I don't think that would make any difference because if you include LGPL'd code (as opposed to just linking against it) you are obliged to LGPL your code.
>  
>
Correct.

>Linus has explicitly marked some header macros as not being GPL. For example, in asm-i386/string.h he specifically says there is no copyright and they are to be considered "PD" - (which I read as "public domain"). In linux/jhash.h the macros are declared by the author to be public domain as well. 
>  
>
Linus has also made statements that #including the header files in a
binary-only driver may subject that drive to the GPL (since he thinks
its a derived work.)

>Thus, these examples are both available via GPL since they are linked into the kernel but with the Public Domain designation as well. Thus, because we have this second license, in effect, we are not bound to GPL code that includes those functions. 
>  
>
I'm not sure if this follows or not.

>My whole point, however, I am finally getting to it ... is that any library, including a BusyBox library that is licensed only with the GPL is going to severely limit its usage. Folks do notice and the license does really make a difference. Many organizations, and I personally work with dozens each year, do really pay attention to the license on a library.
>  
>
There are strong commercial (and non-commercial) reasons that I prefer
to work on GPL code bases.   I think there are others like me.

>I also agree that the copyright holder must grant the license. Thus if someone contributed code as GPL - someone else can't just now say that the code will be available with a different, say LGPL, license. When someone contributes code to a GPL or LGPL source they are tacitly allowing their code to have that license. After the fact changing a license is completely different. Of course. As was already stated in the email thread.
>  
>
the problem here is that they might not have the "right" do have
contributed the code.   The best example (in the US, anway) is work
covered under a "work for hire" doctorine.  If you make changes to
busybox in the course of your employment, and then hand the changes back
without permission, the "busybox" authors *may* have a problem *if* your
(assumed soon to be ex-) employer decides that they didn't want you to
do that, and the code (or even changes) is still "theirs".

If they haven't distributed the code/changes outside the organization,
then I can't see *any* resource that the authors of Busybox would
have.   If the company has distributed outside the org, then presumably
one of the people who got the derivitive work could submit the request
for the code (including any changes 'owned' by the employer), and the
busybox project could then get them in-turn.

There are several other, somewhat similar situations.  

Jim