A prototype License Wizard up and running

John Cowan jcowan at reutershealth.com
Sat Apr 9 15:43:06 UTC 2005


Chuck Swiger scripsit:

> I know of people who want to release their software and ensure that 
> other people who modify that source to make derivative works are 
> required to also make their changes publicly available-- in which case, 
> the GPL is a good choice.  I'd suggest rewording Q2 based on that.

I considered that wording but rejected it.  The GPL does more than
restrict the behavior of people who modify the GPLed source, it
(purports to) restrict the behavior of people who reuse the source
unmodified.

I've changed it to "Do you want to ensure that your code is only used in 
Open Source programs?"

> Likewise, Q3 strikes me as somewhat strange, too.  If I release a 
> program as open source, then that version of the software is always 
> going to be available as open source, even if some people are free to 
> create private modifications without publishing their changes.  For 
> that matter, the original work would still be open source even if the 
> license permitted people to create modifications, release them in 
> binary form publicly, but not make the source available.
> 
> Being able to create private modifications of a program without 
> releasing your changes strikes me as a privacy issue which can be 
> important, but many licenses permit that, not just the BSD license.  
> I'd mention the MIT/X11 license there, as well.

I have added language about private modifications, and changed the
BSD recommendation to a BSD or MIT recommendation.

> A grid of "is license X compatible with license Y" would be more useful 
> and less obviously biased than asking people about the degree of GPL 
> compatibility they need in every other question.

The GPL is the dominant license in the FLOSS ecosystem, and compatibility
with it, for good or bad, is a very important consideration.  I love
the AFL, and I'd like to see every "copycenter" license switch to it
tomorrow, but the FSF has declared it incompatible with the GPL, and it
ain't gonna happen.

> Also, something that's missing is a question about whether people are 
> using specific languages: ie, if you are using Perl, recommending that 
> people use the same license that Perl is under (ie, Artistic or GPL, 
> user's choice) makes it easier to integrate their changes with CPAN and 
> roll them into Perl itself if so desired.  One ought to recommend the 
> Python license for people writing code in that language, too, for the 
> same reasons.

An excellent point.

-- 
XQuery Blueberry DOM                            John Cowan
Entity parser dot-com                           jcowan at reutershealth.com
    Abstract schemata                           http://www.reutershealth.com
    XPointer errata                             http://www.ccil.org/~cowan
Infoset Unicode BOM                                 --Richard Tobin



More information about the License-discuss mailing list