As part of our going series on the notion of “forking” and open-source, let’s look into the notion of inbound and outbound licenses.
The “inbound” license is the license under which you which you receive an open-source package.
The “outbound” license is the license under which you make that code available, if you decide to redistribute it, in either modified or unmodified form.
Note that, in general, it is the act of distribution that triggers an open-source license. If you just download code that you receive under an open-source license and use it on your own, either for its intended purpose, or for the purpose of making changes and then using the modfied version, then you are under no further obligations.
While this concept is quite simple, I find it rarely mentioned in discussions of open-source. For example, I noted in an earlier post, Paul Courant, that one of the reasons I was impressed by a paper on open-source from the Ithaka.org group was that this notion was so clearly explained in a footnote. As it happens, I and one of the authors of that report took the same plane from Indianapolis back to New York after a conference in mid-October, and when I queried him about this, he said that this was common language among attorneys. (He was Barnaby Gibson, an attorney who works for ithaka.)
So one of the first questions to ask about the inbound license is, “What are my options in the outbound license?”
Some licences dictate some or all of the terms of the outbound license. For example, if the inbound license is GPL, then the outbound license must be GPL (see 2(b) in GPL License.) If the inbound license is LGPL, then the outbound license must be LGPL or GPL (see paragraph (3) in LGPL License).
It is the dictation by the inbound license of some of the terms of the outbound license that expresses what is informally known as a “viral” effect of a license, though in the case of these licenses there is also the additional consideration that the way in which your software is combined with the inbound software may dictate the terms under which the resultant work must be licensed.
So-called “viral” effects are not unique to GPL or LGPL. For example, both the Common Public License (IPL) and Eclipse Public License(EPL) have requirements that must be reflected in the outbound license.
Here, as always, I must add the disclaimer that I am not a lawyer, so you must consult with your own attorney for legal guidance. Also, I am speaking on my own, giving my personal views, and not those of my employer (IBM) in any way, shape, or form. On the other hand, the need for caution should not forbid our discussing these issues, as they are important to understanding open-source.
At the other extreme, so-called “liberal” licenses such as BSD and MIT say nothing about the terms of the outbound license other than that you must give a copyright notice as well as the terms of the inbound license.
Indeed, these licenses are “liberal” in a dual sense. You get to use the code as you deem fit, and you are also given freedom in writing the outbound license.
As a developer, I tend to prefer “liberal” licenses since I want to give the user as much freedom of action as possible. I don’t want to dictate how they must use the code, or how they must license it. I consider my work done when I release the code — what use to make of it is for others, not me, to decide.
This is also where I part ways with those who say that for code to be “open-source” it must be opened up on their terms, and not mine. I respect the licenses written by others, and I expect others to honor the terms of the license I decide to use.
You may not like my terms, but if you don’t, then go elsewhere in search of code, or write it your own code, on terms of your choice.
I don’t think I have the right to tell you how to license your code. Why should you have the right to tell me how to license mine?
Don’t bash me, or others who decide to use a liberal license — fire up a “bash” shell and start writing…