Journal einhverfr's Journal: Metatron Technology Consulting's Free/Open Source Guidelines 1
Following disagreements which have gotten me banned from the OSI license discuss list over the right or power of OSI to unilaterally claim total authority over the term "open source" (a view which is disclaimed on the OSI site, but is generally held by various license-discuss participants including the list moderator-- those interested in what was actually said can check the December and January archives of that list on the OSI site), I have decided that the best way forward is to help fill the void in the industry by offering simple and concrete guidelines that my business will be using to determine whether or not we can use a license for development under our open source policy. This policy is generally in the same spirit as OSI's OSD and the FSF's Four Freedoms, but is designed to be less subject to arguments over interpretation, and easier for businesses to use as guidelines for when to state that software is uncontroversially free and open source. Note however that the guidelines are somewhat stricter than either the FSF's guidelines for Free Software or the OSI's OSD.
One of the key points one must be aware of is that software freedom carries with it an economic advantage. The goal of this set of guidelines is to help provide an objective framework for understanding when we feel that this freedom is crippled through onerous requirements either on the developers or the end users. Our commitment is to preserving this freedom for our customers and we hope other businesses will adopt similar guidelines.
The first two requirements are hard requirements. If either of these are violated, we will not do work on the project though we may help arrange others to do this.
1: Open source works must not place restrictions on use, nor may it force one to distribute source code except when one has opted to provide a copy of object code. Furthermore, no bundling restrictions may be in place. This provision disqualifies licenses which restrict commercial use either directly or indirectly (as the Aladdin License seeks to do), as well as ones which force distribution of modifications (such as those of the Aferro GPL and Larry Rosen's Open Software License). It does not disqualify the GPL v2, nor does it fully disqualify the GPL v3.
2: Modifications must be possible for all sections of the work except for the license text itself. One must be allowed to distribute such derivative works and to provide the same rights downstream as were granted to oneself. This disqualifies GFDL works which include invariant sections. If someone stated that one must *choose* a specific license and not provide the rest of the rights downstream, we would not work on that project either. This would also disqualify GPL v3 programs where additional permissions require their own removal on modification.
The following guidelines involve license selection. These do not disqualify us from working on various projects, but help us determine what licenses are best for a project:
3: Licenses should be no more restrictive then absolutely necessary for either party. Where all things are equal, more permissive licenses are preferred.
4: Licenses should be no more complicated than absolutely necessary. Where all things are equal, simpler (and usually shorter) licenses are preferred.
The final guideline defines our community involvement:
5: Multivendor solutions are preferred over single-vendor solutions.
What do people think?
UPDATE:
There has been a change in moderators of the license-discuss list. I was banned by Russ Nelson, not the current moderator (Ernie P). Ernie has been an important positive influence on the OSI in general and I wish him luck. However, I have serious questions about the OSI's ability to actually contribute substantial resources to the community at the present time, so I suppose I will work on these challenges and reconsider my involvement on the lists later.
Rule-based (Score:2)