...And it was vague or unintelligible, would it still be enforceable? Ernest Park, our Director of Research was pondering whether the ability to easily decipher license language could impact whether or not a license was enforceable. This isn't to mean that someone's intellectual capacity to decipher a license (or not), should be used as the determinant, but rather, if the license terms are too rambling, extremist and/or esoteric. If a developer somehow misinterprets license intent, because it may be far too hard to determine, would the author's intent, even though it's clear to no one but the author, be enforceable?
Let's take a minute to think about this.
It's important to point out that I did not seek legal counsel (which I would do if I had a serious question about a specific license I was intending to use) and instead wanted to leave this as a point to ponder. It's good to keep the mind sharp by ruminating on such unsolvable puzzles. My own answer is that it really must depend on how good your lawyer is. A good lawyer can defend just about anything.
Ernie feels that the "market" will drive which OSS projects succeed, and which will become obsolete, due to risks associated with unclear, contradictory and nonexistent licenses. There are many witty, self-serving licenses such as "Free Beer" out there just as there are many strange and dramatic ones (think "death and repudiation"). Despite the flagrancy of some license terms, there are existing projects among even the weirdest whose content may redeem them. You may actually want or need to use the open source code attached to such a license and thus, it becomes important to know whether your interpretation of that license is the same as that of the author's. Should you have a philosophical difference of opinion as in, "organization" can be a gathering of people or an oppressive, capitalist, corporate machine, depending on who the author is - and your interpretation is, for lack of a better term, flat wrong, you may find yourself, or your organization, in court.
If you are the author of a license, and you're feeling somewhat ideological and/or anti-enterprise, it certainly is your right to outline the terms of use to fit your particular bent. However, it behooves you to ensure that your intent is clear, and not subject to interpretation that runs counter to the spirit of what you're trying to accomplish. If you don't want an "organization" (defined by you, for example, as anything incorporated in the state of Delaware that turns a profit) to redistribute your license in any form, then you need to make it excruciatingly clear what you consider an organization, because a church in Iowa may consider themselves an organization and may want to send an application to other churches (I know, this may be a science fiction scenario but it serves to make a point). On the flip side, a good, solid, license, as defined by our Research Director, should be easy enough for laymen - minus an entourage of attorneys and specialists - to understand.
Ernie has put together his "rule of thumb" qualifiers that can help you determine whether a project is licensed in a clear manner:
1. Does the project have a distinct homepage that is not a repository? This provides a place where the maintainer can manage a freeform data exchange with users, and is a site unique from any repository and its goals.
2. The license maintainer should provide a URL to the license(s) used.
3. License text must reference the file from which it is derived by URL, such as http://www.opensource.org/licenses/apache2.0.php
4. The project homepage should provide a link called "Licenses" attached to the main license page, as described above.
5. Each download file is compressed with a file called "license.txt" and "license-OSI-
6. License.txt, needs to be described in the licensing hierarchy for licensing per application/version/release.
7. License-OSI-
8. License-OSI-
9. Unless the maintainer has a Juris Doctorate and is a specialist in software licensing law, they should stick with OSI licenses, or use them as the CORE. In the event that the maintainer uses the OSI license, "Congratulations!" In the event that a maintainer chose to reinvent the wheel, they should clearly identify such and change the license URL to read:
- OSI license: license-OSI-(license name).txt
- Modified OSI license: license-Modified_OSI-(license name).txt (this requires identification of the core license that was modified)
- License newly developed by maintainer or third party: license-custom-(license name).txt
As Ernie points out, a license for the use of open source software is an agreement between a maintainer/developer creating the project, and the user/developer planning to use it. Therefore, the license agreement represents the rules of that relationship and should be easy to understand.
In the end, it is the strength of the open source community that makes OSS a success.
If projects don't meet the basic measure of clear licensing as defined above, you have several options. You can request that the author clarify (in writing) and amend the license terms, your can get legal interpretation of the license, or, as a hard line approach, you can avoid the project altogether.
More often than not, license disputes involving open source projects are resolved without litigation - but as recent history shows (Xterasys, High Gain Antennas and ASUS to name a few), not without being dragged through the media mud. It is simply more efficient for people to talk to each other, correct their mistakes and move on. That being said, with the growing popularity of OSS, mainstream consumer and business use of this type of software means more people are relying on OSS and more money is involved. Developers must be aware and vigilant about the status of their projects and licensing.
