Subject: RE: OSI Approval process
From: "Mike Milinkovich" <mike.milinkovich@eclipse.org>
Date: Thu, 27 Sep 2007 21:43:58 -0400
Thu, 27 Sep 2007 21:43:58 -0400
Matthew, 

 

Have you considered the Eclipse Public License
<http://www.eclipse.org/org/documents/epl-v10.php> ? It meets the set of
constraints you have set out, including widespread commercial adoption.

 

From: Daniel Corbe [mailto:daniel.junkmail@gmail.com] 
Sent: Thursday, September 27, 2007 11:08 AM
To: Matthew Flaschen
Cc: License Discuss
Subject: Re: OSI Approval process

 

Ultimately we were advised by legal counsel NOT to use the LGPL due to the
extended use of the term "Library" throughout the license agreement and how
that can potentially be misconstrued in court due to the fact that the
software in question is actually not a library but rather a full blown
application. 

 

I personally think this fear is unfounded; however, my lawyers aren't
technical people and I don't have a law degree so I'm going to accept the
advice at face value. 

 

-Daniel

On 9/19/07, Matthew Flaschen <matthew.flaschen@gatech.edu
<mailto:matthew.flaschen@gatech.edu> > wrote:

Daniel Corbe wrote:
> Once I have a usable systems framework I'll want to concentrate on writing

> applications which can make use of this work.  For this I will want to be
a
> lot less permissive about sub-licensing code.  Mainly because it will be
in
> a user-facing context as opposed to a developer-facing context. 
>
> I want the code to remain open,

Exactly what do you mean by "open" here?

> and I want the intent of the license to
> reflect free and unrestricted distribution of my code (which includes 
> incorporation into commercial offerings).  This rules out the GPL as it
> violates the spirit of my intentions.

Of course, GPL allows interpretation into commercial offerings.  It
doesn't allow incorporation into proprietary offerings.  Which do you mean? 

> I want something
>
> A) Less permissive than the MIT/BSD license
> B) Something that is certainly a great deal clearer than the BSD license
> C) Something more permissive than the GPL. 

Have you considered the LGPL?  It will allow you to keep the "library"
code open, but the overall work using the library can still be proprietary.

Matt Flaschen


 



Matthew,

 

Have you considered the Eclipse Public License? It meets the set of constraints you have set out, including widespread commercial adoption.

 

From: Daniel Corbe [mailto:daniel.junkmail@gmail.com]
Sent: Thursday, September 27, 2007 11:08 AM
To: Matthew Flaschen
Cc: License Discuss
Subject: Re: OSI Approval process

 

Ultimately we were advised by legal counsel NOT to use the LGPL due to the extended use of the term "Library" throughout the license agreement and how that can potentially be misconstrued in court due to the fact that the software in question is actually not a library but rather a full blown application.

 

I personally think this fear is unfounded; however, my lawyers aren't technical people and I don't have a law degree so I'm going to accept the advice at face value.

 

-Daniel

On 9/19/07, Matthew Flaschen <matthew.flaschen@gatech.edu > wrote:

Daniel Corbe wrote:
> Once I have a usable systems framework I'll want to concentrate on writing
> applications which can make use of this work.  For this I will want to be a
> lot less permissive about sub-licensing code.  Mainly because it will be in
> a user-facing context as opposed to a developer-facing context.
>
> I want the code to remain open,

Exactly what do you mean by "open" here?

> and I want the intent of the license to
> reflect free and unrestricted distribution of my code (which includes
> incorporation into commercial offerings).  This rules out the GPL as it
> violates the spirit of my intentions.

Of course, GPL allows interpretation into commercial offerings.  It
doesn't allow incorporation into proprietary offerings.  Which do you mean?

> I want something
>
> A) Less permissive than the MIT/BSD license
> B) Something that is certainly a great deal clearer than the BSD license
> C) Something more permissive than the GPL.

Have you considered the LGPL?  It will allow you to keep the "library"
code open, but the overall work using the library can still be proprietary.

Matt Flaschen