Help with license decision for "cluster" of similar projects

[Ernest Prabhakar]

Hi Chris,

Very good questions to ask.   I'll offer some starting response, but 
I'm sure you'll get almost as many opinions as there are people on the 
list.

On Mar 3, 2004, at 8:15 AM, Christopher D. Coppola wrote:

> My question, finally, is what advice can anyone on this list offer with
> regard to:
>
> 1.	Choosing a license such as OSL 2.0 or Academic Free License 2.0 VS.
> creating a license of our own or adopting one such as the Sakai license
> (below) among as many of our projects as possible.

I suspect, from what I know of educational groups, that agreement will 
be difficult.  If you can reuse an existing license, please do so.  
However, if you only get as far as all agreeing on something like the 
Sakai license, that would be an impressive accomplishment.

> 2.	Our objectives are to foster commercial involvement in these
> projects, develop a vital community of users and contributors, and make
> adoption easy for schools that would use the software and/or 
> contribute to
> it. How does a copyleft provision either help or hurt these objectives?

The way I like to think of it (personal opinion only!) is that:
- copyleft ensures the *code* always stays free (maximizing the 
original author and end-users freedom)
- BSD/AFL license ensure the *developer* using the code has as much 
freedom as possible

The real question, IMHO, is "Do you want commercial companies to build 
commercial products using this software, and not have to pay you 
anything?"   If so, then don't use a copyleft license. If you want to 
either prevent commercial products, or try to charge people for it, 
then copyleft is perfect for you.

Of course, the middle ground is something like the original Mozilla 
license, which keeps the core code free while allowing people to freely 
mix it in commercial products.

If you think your core customers are likely to voluntarily submit code 
changes back, and you don't mind if the occasional jerk keeps their 
toys to themselves, then a BSD/AFL license is usually the cleanest.

> 3.	How does the length of the license impact the project? My personal
> observation is that the shorter licenses create ambiguity, the longer 
> ones
> generally get confusing, and there seems to be some middle ground 
> (like the
> OSL 2.0) that strike a good balance. Is anyone aware of a very simple
> license causing problems because it wasn't clear enough? How about a 
> longer
> license inhibiting use because it was too complex for many people to
> understand?

A license should be long enough to accomplish your goals, but no 
longer.  Obviously if you have simple goals, a short license is usually 
sufficient.  The trick, as Einstein says, is to make things as simple 
as possible -- but no simpler.

-- Ernie P.
IANAL, TINLA, etc. etc. & so forth

--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3