OSI Approval process

[Mike Milinkovich]

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 at 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 at gatech.edu
<mailto:matthew.flaschen at 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


 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20070927/d295bea3/attachment.html>