On 21 March 2013 10:41, Axel F. [email protected] wrote:
The truth is, I didn’t want to bother with license. But I felt, I need
one, and GPL was one I often saw together with software. That’s the only
reason why I took GPL. - Saying, “license is same as Ruby’s”, would that
be enough? Or, can the most important advantages/disadvantages of
ruby/mit/bsd be told in a few easy sentences? I need not to have it
perfect.
One of the concerns people have with the GPL is that it is copyleft,
meaning you cannot add “restrictions” later on: any rights granted to
the software through the GPL cannot be removed in any derivatives. It
is in some sense “viral”. If you use GPL’d derived code in your work,
it cannot be proprietary and closed, it must be as free as the GPL.
In contrast, the more “permissive” licenses like MIT/BSD/ISC place
very few restrictions beyond attribution (through maintaining the
copyright notice), so that, say, MIT-licensed code can be included in
proprietary software, or the license on the code itself changed
(sublicensing). (For this reason, MIT is shorter and doesn’t require a
lot of legalese.) It turns the “keep it free” aspect into a social,
contribute-back-to-the-community issue.
You should pick whichever license covers your intent of the code. Do
you want it to be free “permanently” (GPL or another copyleft
license), or do you want to be more permissive (MIT/BSD/ISC or
similar)?
As a mini aside, you can also look at the Apache license, which
includes other clauses like assuming contributions are also under the
Apache license. Note this is different from copyleft, like the GPL.
I’d actually really like to see a license that is MIT-style + this
clause. I actually did a write-up1 of this kinda stuff, if you’re
curious, where I also looked at taking contributions and including
those in the copyright notice. Some projects have a lot of
contributions but this never gets fed back into the copyright notice,
which is a bit of a shame if there are significant contributors.