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
