MIT vs. Ruby/GPL License

[Trans]

Rails uses the MIT license. The Ruby license is essentially the GPL
(it's a dual license).

So what are the basic differences between the two and why would you
pick one over the other?

Thanks,
T.

 

[Randy Kramer]

Rails uses the MIT license. The Ruby license is essentially the GPL
(it's a dual license).

So what are the basic differences between the two and why would you
pick one over the other?

Interesting question, and one I'm tempted to answer even though others are
certainly better quailified. (I.e., IANAE(xpert)) I guess I'll consider this
a learning exercise, to see how much I do know.

(Aside: I'm curious: I'm a little surprised you haven't come across and come
to some resolution on the issues involved--do you program primarily in
Windows as opposed to Linux?)

I have trouble remembering things, I remember less about the MIT license than
the GPL license, and know (if I can remember) most about the GPL version 2.

First of all both the MIT and GPL licenses are in some sense "free".

The meaning of free in this context is freedom as opposed to free beer.

Richard Stallman, the guy who, at least in some sense, started the drive
towards a free operating system, originated and advocates the GPL license.
He lists four freedoms that could be associated with software--can I remember
them to recite them or must I look them up?

Hmm, I guess I'll refer you to the following page which contains the GNU's
"Free Software Definition" (gnu is (one of?) the organizations founded by
Richard Stallman, the other being the FSF (or are they the same
organization--I guess I don't really know)):

http://www.gnu.org/philosophy/free-sw.html

When you read over that page, pay particular attention to "copyleft"--the
primary difference between the GPL and other free (??) licenses (like the MIT
license) is the copyleft part--the GPL requires copyleft, many others (MIT,
BSD, ... do not). (Richard Stallman considers free licenses without copyleft
to be non-free.)

I anticipate releasing any software I write under the GPL license.

There are other choices like dual licenses and, hmm, I forget what they call
them, but like what Ghostscript and some others do--(iirc) they initially
release their software (i.e., current versions) under a license other than
the GPL, and then after some period of time (or at the release of the next
version) they release the older version under the GPL.

Aside: If you get into dual licenses, take any recent writings on the subject
by Theo de Raadt (the OpenBSD founder) with a grain of salt--in a fairly
recent dispute, he made the claim that dual licenses required that the terms
of both licenses be applicable, whereas most dual licenses are specified with
an "or" (you can license it this way or that way--of course a dual license
could be written with an "and"--I'm not sure that would be useful in any
way).

BTW, other issues to consider are which software can be intermixed in some way
even though they use different licenses.

Another way of looking at it the general subject is this:

With a license like the MIT (and BSD, and ...) you give away your software
(almost) unconditionally, anybody can take your software and use it for any
purpose without returning anything to you (they can make a proprietary
package from it, make a fortune, and not share anything with you).

With a license like the GPL, your software gift is conditional--the receiver
of the gift must (to use a phrase that I haven't heard in this context
before) "pay it forward". In other words, they must keep the gift available
including any improvements they may make.

You can make money with either type of license, but it is ususally by means of
a service model than a use model. To clarify, a way of making money with
free software is selling support for it, as opposed to selling a license for
its use.

Note that the GPL does allow you to charge for the software, but anyone who
buys your software can re-distribute it at a lower price, down to zero (or
negative numbers??).

There is also a (potential) different issue (??) related to selling the source
code--the intent (and words), iirc, is that you can only recoup your
(copying) costs (or a reasonable fee--I forget what it says) for the source
code.

At most, this is just a start. Do some reading and ask some questions.

regards,
Randy Kramer

 

[Alexey Verkhovsky]

MIT license does have one restriction:

QTE
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
UNQTE

Which in practice means that you should remember adding a copyright
statement at the top of the LICENSE file.

 

[Tim Hunter]

Rails uses the MIT license. The Ruby license is essentially the GPL
(it's a dual license).

So what are the basic differences between the two and why would you
pick one over the other?

Thanks,
T.

T.,

I normally enjoy your posts, and I do hate to be negative, but it feels
like ruby-talk has been plagued with a lot of
200-followup-barely-on-topic threads lately, and your post could easily
be (given this strong opinions that people can form about FOSS
licensing) the start of yet another.

Would it be too much to ask for you to go off and read some of the
commentary on these licenses that can be found on the web, form some
conclusions, and then, if necessary (and I don't think it will be)
follow up with "I've read this material and this is what I think and
here are some RUBY-SPECIFIC questions I have or conclusions I've come to
that I'd like to share?"

You can start your research with the text of the licenses. MIT is here:
http://www.opensource.org/licenses/mit-license.php. GPL here:
http://www.gnu.org. I notice several books are available on Amazon,
including _Understanding_Open_Source_and_Free_Software_Licensing_.

To the list, I apologize. I try to keep my posts positive, contributory,
and on-topic. I recognize that this one is simply cranky.

 

[Trans]

Interesting question, and one I'm tempted to answer even though others are
certainly better quailified. (I.e., IANAE(xpert)) I guess I'll consider this
a learning exercise, to see how much I do know.

(Aside: I'm curious: I'm a little surprised you haven't come across and come
to some resolution on the issues involved--do you program primarily in
Windows as opposed to Linux?)

Me too

I've been using the Ruby license. But everything I've done until now
has been purely open. That's about to change though, so the question
becomes a more important one.

I have trouble remembering things, I remember less about the MIT license than
the GPL license, and know (if I can remember) most about the GPL version 2.

First of all both the MIT and GPL licenses are in some sense "free".

The meaning of free in this context is freedom as opposed to free beer.

Richard Stallman, the guy who, at least in some sense, started the drive
towards a free operating system, originated and advocates the GPL license.
He lists four freedoms that could be associated with software--can I remember
them to recite them or must I look them up?

Hmm, I guess I'll refer you to the following page which contains the GNU's
"Free Software Definition" (gnu is (one of?) the organizations founded by
Richard Stallman, the other being the FSF (or are they the same
organization--I guess I don't really know)):

http://www.gnu.org/philosophy/free-sw.html

When you read over that page, pay particular attention to "copyleft"--the
primary difference between the GPL and other free (??) licenses (like the MIT
license) is the copyleft part--the GPL requires copyleft, many others (MIT,
BSD, ... do not). (Richard Stallman considers free licenses without copyleft
to be non-free.)

I anticipate releasing any software I write under the GPL license.

There are other choices like dual licenses and, hmm, I forget what they call
them, but like what Ghostscript and some others do--(iirc) they initially
release their software (i.e., current versions) under a license other than
the GPL, and then after some period of time (or at the release of the next
version) they release the older version under the GPL.

Aside: If you get into dual licenses, take any recent writings on the subject
by Theo de Raadt (the OpenBSD founder) with a grain of salt--in a fairly
recent dispute, he made the claim that dual licenses required that the terms
of both licenses be applicable, whereas most dual licenses are specified with
an "or" (you can license it this way or that way--of course a dual license
could be written with an "and"--I'm not sure that would be useful in any
way).

BTW, other issues to consider are which software can be intermixed in some way
even though they use different licenses.

Another way of looking at it the general subject is this:

With a license like the MIT (and BSD, and ...) you give away your software
(almost) unconditionally, anybody can take your software and use it for any
purpose without returning anything to you (they can make a proprietary
package from it, make a fortune, and not share anything with you).

So MIT is more akin to BSD --less restrictive.

With a license like the GPL, your software gift is conditional--the receiver
of the gift must (to use a phrase that I haven't heard in this context
before) "pay it forward". In other words, they must keep the gift available
including any improvements they may make.

You can make money with either type of license, but it is ususally by means of
a service model than a use model. To clarify, a way of making money with
free software is selling support for it, as opposed to selling a license for
its use.

Note that the GPL does allow you to charge for the software, but anyone who
buys your software can re-distribute it at a lower price, down to zero (or
negative numbers??).

There is also a (potential) different issue (??) related to selling the source
code--the intent (and words), iirc, is that you can only recoup your
(copying) costs (or a reasonable fee--I forget what it says) for the source
code.

At most, this is just a start. Do some reading and ask some questions.

Very helpful thank you. For the moment I will hone in on one question:

If a gem is released under GPL and your app depends on it, does that
mean your source must also be freely available in a way compatible to
the GPL? If not, then what about if you drop the same library into
your vendor/ directory and redistribute it along with your app?

Thanks,
T.

 

[Randy Kramer]

I've been using the Ruby license. But everything I've done until now
has been purely open. That's about to change though, so the question
becomes a more important one.

Thanks!

I should point out that *after* I pressed send, I read the page that I
referred you to (and some pages linked from that page) a little more
carefully (they seem to be pages I hadn't seen before--I guess it's been
fairly a long time since I dug into this stuff), and realize that some of my
previous statements were not accurate.

The first being that Richard Stallman *does* consider some licenses without
copyleft to be free. If I recognize others as I reread what I wrote, I'll
try to point them out.

So MIT is more akin to BSD --less restrictive.

That is my belief, but I should admit that I haven't had much exposure to the
MIT license.

Very helpful thank you. For the moment I will hone in on one question:

You're welcome! (But after my further reading, I'm beginning to believe I
should have let somebody else dip their foot in the water first. ;-)

If a gem is released under GPL and your app depends on it, does that
mean your source must also be freely available in a way compatible to
the GPL? If not, then what about if you drop the same library into
your vendor/ directory and redistribute it along with your app?

I don't think I can give an instant (correct ;-) answer to that. I'd suggest
you look for and read up on the LGPL--it was originally intended to stand for
the Library GPL, but has since been changed to stand for the Lesser GPL, but
its focus is on issues related to your concern.

Good luck!

Randy Kramer

 

[M. Edward (Ed) Borasky]

Rails uses the MIT license. The Ruby license is essentially the GPL
(it's a dual license).

So what are the basic differences between the two and why would you
pick one over the other?

Thanks,
T.

The Ruby license says that you can use the the GPL, or you can use the
explicit terms of the Ruby license. Here's the text of the Ruby license.
-----------------------------------------------------------------------
Ruby is copyrighted free software by Yukihiro Matsumoto <[email protected]>.
You can redistribute it and/or modify it under either the terms of the GPL
(see COPYING.txt file), or the conditions below:

1. You may make and give away verbatim copies of the source form of the
software without restriction, provided that you duplicate all of the
original copyright notices and associated disclaimers.

2. You may modify your copy of the software in any way, provided that
you do at least ONE of the following:

a) place your modifications in the Public Domain or otherwise
make them Freely Available, such as by posting said
modifications to Usenet or an equivalent medium, or by allowing
the author to include your modifications in the software.

b) use the modified software only within your corporation or
organization.

c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided.

d) make other distribution arrangements with the author.

3. You may distribute the software in object code or executable
form, provided that you do at least ONE of the following:

a) distribute the executables and library files of the software,
together with instructions (in the manual page or equivalent)
on where to get the original distribution.

b) accompany the distribution with the machine-readable source of
the software.

c) give non-standard executables non-standard names, with
instructions on where to get the original software distribution.

d) make other distribution arrangements with the author.

4. You may modify and include the part of the software into any other
software (possibly commercial). But some files in the distribution
are not written by the author, so that they are not under this terms.

They are gc.c(partly), utils.c(partly), regex.[ch], st.[ch] and some
files under the ./missing directory. See each file for the copying
condition.

5. The scripts and library files supplied as input to or produced as
output from the software do not automatically fall under the
copyright of the software, but belong to whomever generated them,
and may be sold commercially, and may be aggregated with this
software.

6. THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.

 

[Alexey Verkhovsky]

The Ruby license says that you can use the the GPL, or you can use the
explicit terms of the Ruby license.

Except for some of the source files you cannot... because those are
GPL. See quotes below. Ruby license is a rather weird device that
shouldn't be used for anything other than Ruby itself.

QTE LICENSE
But some files in the distribution are not written by the author, so
that they are not under this terms. They are gc.c(partly),
utils.c(partly), regex.[ch], st.[ch] and some files under the
/missing directory. See each file for the copying condition.
UNQTE LICENSE

QTE regex.c
you can redistribute it and/or modify it under the terms of the GNU
Library General Public License
UNQTE regex.c

 

[Bill Kelly]

I don't think I can give an instant (correct ;-) answer to that. I'd suggest
you look for and read up on the LGPL--it was originally intended to stand for
the Library GPL, but has since been changed to stand for the Lesser GPL, but
its focus is on issues related to your concern.

Indeed. I'm writing a partly open source, partly closed source
application at the moment. Any library released under GPL is
off-limits to me (unless it is a library bundled with the operating
system.)

(Which is fine, if that's really what the library author intended.)

Personally I'll not release a *library* under the GPL, since I
prefer to impose the fewest restrictions on who can link with my
library.


Regards,

Bill

 

[Chad Perrin]

T.,

I normally enjoy your posts, and I do hate to be negative, but it feels
like ruby-talk has been plagued with a lot of
200-followup-barely-on-topic threads lately, and your post could easily
be (given this strong opinions that people can form about FOSS
licensing) the start of yet another.

Would it be too much to ask for you to go off and read some of the
commentary on these licenses that can be found on the web, form some
conclusions, and then, if necessary (and I don't think it will be)
follow up with "I've read this material and this is what I think and
here are some RUBY-SPECIFIC questions I have or conclusions I've come to
that I'd like to share?"

You can start your research with the text of the licenses. MIT is here:
http://www.opensource.org/licenses/mit-license.php. GPL here:
http://www.gnu.org. I notice several books are available on Amazon,
including _Understanding_Open_Source_and_Free_Software_Licensing_.

To the list, I apologize. I try to keep my posts positive, contributory,
and on-topic. I recognize that this one is simply cranky.

I understand the intent behind your commentary, and don't really see any
particular need to apologize. For my part, at least, there's nothing to
forgive.

For T.:

If you want to discuss it with someone off-list, and think I may be
someone that can help, I'll be happy to discuss the matter with you. I
have very specific opinions on the matter, but I'm also of the opinion
that everyone should be able to form his or her own opinions, so I'll try
to be as clear about the matter as possible complete with very distinct
separation between facts and opinions.

 

[Jon Lambert]

From: (e-mail address removed)

(Richard Stallman considers free licenses without copyleft
to be non-free.) ...

With a license like the MIT (and BSD, and ...) you give away your softwar= e
(almost) unconditionally... ...
With a license like the GPL, your software gift is conditional--the recei= ver
of the gift must (to use a phrase that I haven't heard in this context
before) "pay it forward".=20

Which one gives the user more freedom, the unconditional or conditional gra=
nt?
That's rhetorical. I've already determined the answer for myself.=20

While GPL software apparently does fall under the OSD , it does impose a pr=
actical though not explicit discrimination against a particular field of en=
deavor... selling software.=20

- J. Lambert

_________________________________________________________________
Boo!=A0Scare away worms, viruses and so much more! Try Windows Live OneCare=
!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=3Dwl_hotma=
ilnews=

 

[Jon Lambert]

The GPL gives the *user* *complete* freedom. It restricts *other*
activities, such as distributing a derived work, but it imposes no
restrictions on simply using the software.

Using that limited definition of user, one who "simply uses the software",=
=20
most proprietary licenses also give the user complete freedom. =20

- J. Lambert

_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook =96 together at last. =A0=
Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=3DCL10062=
6971033=

 

[Chad Perrin]

Including the freedom to install and run the software *without* paying
anything for it? I think not. And at my last office job I didn't see
any proprietary software whose license did not restrict either the
number of installation hosts or the number (total or concurrent) of
users. GPL software has no such usage restrictions.

Considering we were talking about "freedom", I didn't think we were
talking about "free cost".

The user does not necessarily get "complete freedom" (for instance, I'm
in the odd position of having a bunch of GPLed software on a shelf that I
cannot legally give away for free, thanks to the rules relating to
upstream linking for GPLv2). Many of those cases are largely
unimportant, but the fact that restrictions still exist should not be
ignored.

I'm not saying there's anything wrong with the GPL (nor that there isn't,
per se) at the moment. I'm just trying to stick to the cold, hard facts
of the matter. Considering ruby-talk isn't exactly the proper venue for
an ideological war, I think we'd all appreciate it if you would do the
same rather than simply applying the blanket term Freedom to all things
GPL and defend it to your last breath -- as you seem to be gearing up to
do.

 

[M. Edward (Ed) Borasky]

Including the freedom to install and run the software *without* paying
anything for it? I think not. And at my last office job I didn't see
any proprietary software whose license did not restrict either the
number of installation hosts or the number (total or concurrent) of
users. GPL software has no such usage restrictions.

Regards,

Jeremy Henty

Most proprietary end-user licenses explicitly forbid running the
software under a debugger, disassembling it, or benchmarking it and
publishing the timing results, even if you paid for it. It's not just
distribution you can't legally do.

 

[Randy Kramer]

Using that limited definition of user, one who "simply uses the software",
most proprietary licenses also give the user complete freedom.

Hmm, most proprietary licenses (I can't immediately think of any exceptions)
do not give the *user* (who might be a programmer, or not) the freedoms to:

* review (and learn) from the source code
* modify the program (using the source code) for his own purposes and use
* pay someone other than the original "manufacturer" to modify the program
for his own purposes and use

(Phrased as above to stay away from the concepts of then distributing those
changes to others, which most, I think, would not consider to be (strictly)
user functions.)

Randy Kramer

 

[Trans]

Chad, *I* was responding to someone's direct reply to one of my
comments. It's not relevant that you thought "we" were talking about
something else.


The right to do some things for free is a pretty important freedom.
Or would you be happy having to pay $1000 to vote? Anyway, I
mentioned (and you conveniently ignored) several other freedoms. And
other posters have mentioned more.


Irrelevant. My point was that *usage* is not restricted. And it
isn't.


You most definitely are *not*, otherwise you would not have accused me
of:


Why don't *you* "stick to the cold, hard facts of the matter." rather
than spreading rumours about what I "seem to be gearing up to do."?
Meanwhile I'll stick to defending what I actually *said*. Life's too
short to waste time on other people's silly fantasies about my
motives.

Uh oh. We were doing so well! A potentially flaming subject kept to a
congenial ember.

Tell you what. Lets now take a different bent: Here is what I think I
learned from this thread.

1) Licensing can be complicated
2) Unless you have specific reasons to do otherwise pick a very simple
one like MIT.
Specific reasons are either:
1) I demand all derivative works also be OSS.
2) This software is mine mine mine (non-OSS or partial-OSS)
3) Another lib, that I must use, is forcing my hand.
3) Ruby license is not a good license to use, but unfortunately so
many Rubyists have used it we are kind of stuck with it --see 2.3
above. Thankfully, clause 4 of the license gets us out of point 2.1
(barely?).

T.

 

[Chad Perrin]

Uh oh. We were doing so well! A potentially flaming subject kept to a
congenial ember.

Tell you what. Lets now take a different bent: Here is what I think I
learned from this thread.

1) Licensing can be complicated
2) Unless you have specific reasons to do otherwise pick a very simple
one like MIT.
Specific reasons are either:
1) I demand all derivative works also be OSS.
2) This software is mine mine mine (non-OSS or partial-OSS)
3) Another lib, that I must use, is forcing my hand.
3) Ruby license is not a good license to use, but unfortunately so
many Rubyists have used it we are kind of stuck with it --see 2.3
above. Thankfully, clause 4 of the license gets us out of point 2.1
(barely?).

I'm not quite as well-versed in the MIT license as I am in some others.
It is often compared with the BSD license as having similar terms,
however, so I'll speak about the BSD license here (with which I'm more
familiar).

The BSD license actually provides for the code covered by the license to
be forevermore "open source". There's a common misconception that the
BSD license and similar licenses somehow allow you to make the code in
them proprietary. That's not legally possible, as the BSD license
contains an inheritance clause that mandates further copies of the code
be distributed under the same license. The difference between that and
the voracious nature of the GPL is that the BSD license allows covered
code to be "wrapped" in code of another license, such that a complete
project can be distributed under the licensing terms of the copyright
holder's choice while the specific parts of it that are licensed BSD
remain under the BSD license's terms. The GPL demands that everything
that is connected to code it covers must also be distributed under its
terms.

So . . . the MIT license may very well be quite suitable to situations
where you "demand that all derivative works also be OSS". That really
depends on how you mean that statement to be interpreted.

As for the flame war prone nature of license discussions, I guess I
probably should have left well enough alone rather than asking someone to
keep his/her personal opinions down to a dull roar. The obvious pro-GPL
implications of a preceding message in this thread seemed to require some
correction, and I made the mistake of not realizing attempting to cut the
rhetoric away from the facts would be something like throwing fuel on a
fire. I apologize for that misjudgment.

 

[Chad Perrin]

Hmm, most proprietary licenses (I can't immediately think of any exceptions)
do not give the *user* (who might be a programmer, or not) the freedoms to:

* review (and learn) from the source code
* modify the program (using the source code) for his own purposes and use
* pay someone other than the original "manufacturer" to modify the program
for his own purposes and use

I'd classify the first two (because they specify access to source code as
a condition, rather than referring to any legal privilege) as
"capability" or "opportunity" rather than "freedom". I'm a stickler for
terms that way.

 

[Michal Suchanek]

The BSD license actually provides for the code covered by the license to
be forevermore "open source". There's a common misconception that the
BSD license and similar licenses somehow allow you to make the code in
them proprietary. That's not legally possible, as the BSD license
contains an inheritance clause that mandates further copies of the code
be distributed under the same license. The difference between that and
the voracious nature of the GPL is that the BSD license allows covered
code to be "wrapped" in code of another license, such that a complete
project can be distributed under the licensing terms of the copyright
holder's choice while the specific parts of it that are licensed BSD
remain under the BSD license's terms. The GPL demands that everything
that is connected to code it covers must also be distributed under its
terms.

So . . . the MIT license may very well be quite suitable to situations
where you "demand that all derivative works also be OSS". That really
depends on how you mean that statement to be interpreted.

The major difference from the "forever opensource" point of view is
that BSD license does not require you to distribute the code in source
form.
This allows you to only distribute the binaries of a modified version
of the software and keep the source, making the software as
proprietary as it ever gets. People can disassemble it, but they can
do the same with proprietary software (the license may forbid it but
it is unenforcible technically and often even legally). To disallow
copying the binaries just link with a proprietary module.

Thanks

Michal

 

[Trans]

I'm not quite as well-versed in the MIT license as I am in some others.
It is often compared with the BSD license as having similar terms,
however, so I'll speak about the BSD license here (with which I'm more
familiar).

The BSD license actually provides for the code covered by the license to
be forevermore "open source". There's a common misconception that the
BSD license and similar licenses somehow allow you to make the code in
them proprietary. That's not legally possible, as the BSD license
contains an inheritance clause that mandates further copies of the code
be distributed under the same license. The difference between that and
the voracious nature of the GPL is that the BSD license allows covered
code to be "wrapped" in code of another license, such that a complete
project can be distributed under the licensing terms of the copyright
holder's choice while the specific parts of it that are licensed BSD
remain under the BSD license's terms. The GPL demands that everything
that is connected to code it covers must also be distributed under its
terms.

That's good to understand.

So . . . the MIT license may very well be quite suitable to situations
where you "demand that all derivative works also be OSS".

Does it? I thought it was just the opposite.

That really
depends on how you mean that statement to be interpreted.

Well, I was thinking "GPL" in this case.

As for the flame war prone nature of license discussions, I guess I
probably should have left well enough alone rather than asking someone to
keep his/her personal opinions down to a dull roar. The obvious pro-GPL
implications of a preceding message in this thread seemed to require some
correction, and I made the mistake of not realizing attempting to cut the
rhetoric away from the facts would be something like throwing fuel on a
fire. I apologize for that misjudgment.

Well, we are all entitled (even to argue if we want But classically
I think the "war" of license is between GPL and BSD isn't it? That's
probably a huge over simplification, but that tends to be my shallow
assessment of the field. And that was really the crux of my dividing
line for point 2.1.

T.