Simple description of popular open source licenses
1–10 of 14 posts
Re: Simple description of popular open source licenses
#2WTFPL and other similar licenses seem to belong with the MIT license, but they're just floating off on their own.
Re: Simple description of popular open source licenses
#3WTFPL and other similar licenses seem to belong with the MIT license, but they're just floating off on their own.
Agreed. Flowcharts also assume that there is some sort of decision hierarchy that will be followed. Who's to say that derivative works are the most important thing here? Maybe some company/person needs to cover their ass in another way first.
This list is less a description and more a taxonomy, which means that it's not valuable to anyone new to these licenses. When starting a project, it's best to convey the benefits of each license in a straightforward manner to whoever the decision maker is. A tree like this will only confuse and ensure that an ill-fitting license is chosen from the onset.
Simple, written definitions are therefore best, and are similar to the article here: http://simple.wikipedia.org/wiki/GPL
Re: Simple description of popular open source licenses
#4While LGPL and MPL are similar, there are differences and they should not be lumped together.
The biggest difference is that MPL allows static linking while LGPL does not. While in the past this wasn't a big deal, it is important for iOS development since you cannot dynamically link to libraries in iOS apps.
Re: Simple description of popular open source licenses
#5I would like to see the wording of "Companies that distribute software cannot bring a legal claim against the software users" changed to a non-negative, "Companies that distribute software CAN bring a legal claim against the software users." It may seem pedantic, but the "Yes/No" arrows are ambiguous because if you answer the "question" with arrows, it would be "Yes, companies that distribute... cannot bring a legal action..." just sounds confusing.
Otherwise, awesome infographic.
Re: Simple description of popular open source licenses
#6WTFPL and other similar licenses seem to belong with the MIT license, but they're just floating off on their own.
Agreed. Flowcharts also assume that there is some sort of decision hierarchy that will be followed. Who's to say that derivative works are the most important thing here? Maybe some company/person needs to cover their ass in another way first. This list is less a description and more a taxonomy, which means that it's not valuable to anyone new to these licenses. When starting a project, it's best to convey the benefit…
This would matter if there were more than 12 licenses. As it stands, it takes less than a minute to look at every possibility on the chart.
Re: Simple description of popular open source licenses
#7Code under another license can be freely linked and distributed with software.
This misrepresents the LGPL. LGPL doesn't allow static linking. It's not a small detail.
Re: Simple description of popular open source licenses
#8funny that even "I don't care" has many implementations: WTFPL, http://unlicense.org/, CC0 (which wasn't invented for code), etc.
Re: Simple description of popular open source licenses
#9Code under another license can be freely linked and distributed with software. This misrepresents the LGPL. LGPL doesn't allow static linking. It's not a small detail.
It does allow static linking---from section 4, paragraph d:
"d) Do one of the following:
"0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
"1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version."
You just have to allow relinking in some form. Admittedly, this is easier with dynamic linking, but the LGPL doesn't restrict static linking per se.
Re: Simple description of popular open source licenses
#10Code under another license can be freely linked and distributed with software. This misrepresents the LGPL. LGPL doesn't allow static linking. It's not a small detail.
It does allow static linking---from section 4, paragraph d: "d) Do one of the following: "0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by sect…
Yes. It's like saying humans can fly, if thrown out of an airplane. Asking developers to distribute all the object files of their proprietary software is not realistic. And even if one developer accepts that condition, most developers won't, sending any open source software that she releases and that depends on an LGPL library directly into oblivion (again, in a context where dynamic linking is not possible).