OSI Approval process

[Lawrence Rosen]

Daniel,

 

Take a look at Academic Free License (AFL 3.0,
http://opensource.org/licenses/afl-3.0.php). It is already OSI-approved, and
already does what I think you want to do, clearly and without ambiguity. 

 

AFL 3.0 is a permissive companion to the reciprocal (copyleft) Open Software
License (OSL 3.0) and Non-Profit OSL 3.0. 

 

I agree with you that the old BSD license is not clear enough. But I don't
understand why people and companies keep submitting permissive licenses to
OSI when there are several licenses, including the generic and tested AFL
3.0, already OSI-approved, that do the job. Whatever else you do with your
life, don't waste it writing yet another permissive license.

 

/Larry

 

Lawrence Rosen

Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)

3001 King Ranch Road, Ukiah, CA 95482

707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243

Skype: LawrenceRosen

Author of "Open Source Licensing: Software Freedom and 

                Intellectual Property Law" (Prentice Hall 2004)

  _____  

From: Daniel Corbe [mailto:daniel.junkmail at gmail.com] 
Sent: Monday, September 17, 2007 10:27 AM
To: license-discuss at opensource.org
Subject: OSI Approval process

 

Is there a way for the average layman to submit a license to the OSI for
approval?

 

I've been following the debate between the OpenBSD community and SFLC/Linux
community for some time now and I've come to the following conclusions: 

 

1) The BSD license isn't clear on intent when it comes to sublicensing

2) The main objection seems to be that sublicensing BSD code to a GPLed
project produces a one way stream of contributions 

3) There's not a solution for this issue.

 

I've elected to go with the MIT license over the BSD license for some of my
projects because it clearly states the intent on sublicensing in the first
paragraph 

 

 * Permission is hereby granted, free of charge, to any person obtaining a

 * copy of this software and associated documentation files (the

 * "Software"), to deal in the Software without restriction, including 

 * without limitation the rights to use, copy, modify, merge, publish,

 * distribute, sublicense, and/or sell copies of the Software, and to

 * permit persons to whom the Software is furnished to do so, subject to 

 * the following conditions:

 

I've elected to be very permissive on sublicensing because my code is very
system-specific and non-portable.  I hope that with work my code may be
adapted for use in other environments other than the ones I have elected to
target, so I don't mind being so permissive with all the issues that come
with it (such as the current hot-topic) 

 

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

 

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.

 

In that case I'm very tempted to author my own license.  I will (of course)
retain counsel to advise on how legally sound it is, but I also want to make
sure the license is OSI compliant and I'm willing to work towards that. 

 

Regards,

Daniel

 

 

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