Blog ยป An Introduction to Open Source Software
Posted by Avraham on 08 Apr 2014 18:32
As the Open Source software committee, it probably behooves us to release some, if not all, of our work under an open source license as well. Prior to that, we should clarify what we is meant by "Open Source" as opposed to "Free" or "Libre" and then reach a consensus about the best option.
Technically, open source software simply means that the source code for a piece of software is distributed together with, or in lieu of, its executable. It technically makes no statement about how the end user may take advantage of that source code, other than compiling it, and possibly learning from reading it.
The accepted definition of free software is software which is released under a license that guarantee users not only the freedom to run the software for any purpose, but also to study, modify, and distribute both the original software as well as any changed versions.
Because the word "free" has another connotation (Stallman's famous "free as in speech, not free as in beer" line) the industry has accepted the use of the term libre to mean "free as in beer" in this context.
So when people say free software, most of the time they are referring to FLOSS software: Free Libre Open Source Software. This is very different from freeware which means that the author is giving away the software, but not the source code or any license outside of using the software. For example, many iOS and Android apps are freeware, but if you reverse-engineer the source code and sell or give away your own version, you will quickly be sued for copyright infringement.
For anyone interested, there is some friction between the "free software" proponents and the "open source" software proponents. If you are interested, Wikipedia, the OSI, and the FSF are good places to look.
Even within the context of F(L)OSS, there are different classes of licenses which can be more or less restrictive. One of the most important differences between licenses is do derivative works need to be released under the exact same (or sometimes a similar enough) license, or may they be distributed however is desired, including on a proprietary basis (and for a fee). The licenses that require release under the same (or similar) licenses are called copyleft (yes, that is a pun on copyright). Examples include the Gnu GPL and LGPL. Other, more permissive, licenses include the BSD(-3) and Boost licenses.
Another important question is even if the released software will remain untouched, can it be "folded into" a proprietary piece of software or must any software into which it is compiled be release in toto on a free basis. This is the main difference between the GPL and LGPL. The former requires all software which includes any library licensed under the GPL to be released under a compatible license. The Gnu Lesser General Public License allows for a free library to be released in a proprietary package as long as the free library itself is untouched (and released with the proper license and author list etc.)
A third key question is with which licenses do we want our works to be compatible. For example, GPL2 is not compatible with the original BSD license (although GPL3 is compatible with BSD3) which meant that, legally, someone could not build a piece of software which relies on two libraries, one of which is GPL2 and the other OldBSD, as that would violate the license.
If we wanted to be as permissive as possible (allow someone to use our work to make money for his or her company, use our work to build proprietary software for sale, etc.) then we need to focus on licenses like the new BSD, the Boost, the ISC, the MIT, etc. which are pretty much along the lines "Use this for whatever you want at your own risk." If we wanted to ensure that our work remains open source we would have to focus on one of the more restrictive copyleft licenses.
Like this entry?
Leave a comment
The comments are gone, when deleting the blog. Blog comments are automatically saved in forum.
Ops, the comment shows under this blog again. Anyway, nice blog. Avi. But let me change the star level again. Interesting, the star level is averaged. Let me change it again.
Growing pains :)
Thanks for all your work, Hai, this is certainly looking better!
Now URL has color. You are welcome!! Enjoy your blog. I rate it higher again. :-)
Excellent summary, Avi! I was not aware of that difference between the GPL and LGPL.
I honed in on this paragraph:
My personal opinion is that the product of a research organization like the CAS should be as free-for-use as the "discovery" that f(x) = (x-2)(x+3) has two roots. I vote for whatever license allows us to "Use this for whatever you want at your own risk."
That being said, isn't it true that GPL code can be plagiarized, i.e., re-typed into one's own code?
Thanks Avi, good summary. To back up a level, the choice of a license could be made, I suppose, at the committee level or at the individual contributor or product level. It's called the "Open Source Committee", so it's probably not controversial for us to plug some kind of open source license at the committee level.
On the other hand, it may not be necessary for the committee to encourage particular FLOSS licenses in advance. Often there are strong tactical reasons for some open source work to be in a particular license. For instance, both R and the ChainLadder package are GPL'd, so any code submitted to these should be GPL'd also; the stan MCMC libraries are BSD3'd so contributions to those should be BSD3'd. Conversely, if you use ChainLadder package code in your project, then the GPL copyleft would probably attach to your code, basically requiring that you use GPL also. The free software foundation has a somewhat nuanced view about which license to choose, even though they are strong GPL/AGPL advocates.
Somewhat unrelated to this point, but perhaps worth mentioning, is that a project can be dual or even triple licensed, and this sometimes makes sense. So a new project could be BSD'd and GPLv2 at the same time, partially ameliorating that incompatibility.