Metalicensing

Grigor Gatchev

1. The labyrinth of the licenses

In the free / open source software world exist many different licenses - and this has both advantages and disadvantages.

On one hand, developers differ in what degree and type of freedom they plan for their product, and consequently need different licenses. For example, there are BSD-type licenses that allow completely free usage of the software, without any limitations - and there are GPL-type licenses, that demand derivatives of the software to be also free (sometimes called copyleft licenses). If a developer cannot find or create a license that meets their vision on how should be used their product, they may refrain from creating or freeing it. In this sense, a wide spectre of free licenses is an advantage.

On the other hand, many licenses do not allow using their subjects with or inside products governed by another license (cross-license sharing). Often the intentions are good - for example, GNU GPL uses this to prevent code proprietarising, which would destroy its freedom. However, this is also a disadvantage for FOSS, since it fragments its code pool between the different licenses, and thus hampers one of its greatest strengths - the common code base.

Often this barrier is neglected - one may find such "illegal" cross-license code sharing in most big FOSS packages, as a means to retain the code pool integrity in practice. Currently, few people are bothered by this legal neglection. However, it is a potential problem, and we will be better without it.

This fragmentation is the inevitable price of the objective need for different license types, and can never be avoided completely. However, from a legal viewpoint the FOSS pool is already very fragmented. Most of it is still governed by a single license, GPL, but there are already a lot of GPL-like licenses. The same is with the BSD-like licenses. There is CDDL, which is very similar to MPL, but is different, and CDDL code cannot be shared to GPL. If things continue this way - and they are going to - we may soon have license wars inside FOSS. Which is what we need least, and must do everything to avoid.

Okay, any contribution is welcome. This is the FOSS way. And if, let's assume for a moment, Sun wants CDDL exactly as a non-sharing license, in order to prevent code transfer from OpenSolaris to Linux, then they probably won't like to change CDDL. However, the integrity of the FOSS code pool should be increased as much as possible. Otherwise, we are losing a big advantage, a source of freeness, cheapness and quality for all FOSS users. (Which includes most, if not all of us, too.)

One of the possible ways may be to convince the holders of similar licenses to negotiate common licenses that suit all of them, and to produce one license from the lot. However, in many cases this will be impossible, and in many others the compromise will be hard to achieve, and fragile to keep.

Another way is to mediate negotiations between these holders for a "cross-licensing" that allows sharing of code across the free licenses. However, in many cases this may be unsuccessful - the creators of similar, but non-sharing licenses must have had some reasons to create them, and make them non-sharing...

A third approach, which avoids most of these problems, is the metalicensing.

2. Metalicensing basics

The original copyright holder, and controlling entity of every free / open source software is its developer. If Frank wants his code to be usable with, say, every copyleft license, he has the right to explicitly license it with every one of these. Also, the FOSS developers have the incentive to have their code shared as much as possible, as long as that doesn't interfere with the degree of freedom they want for it. So, from the viewpoint of increasing the code pool integrity, they are the ones that should best have the ease to license to everyone they like.

There are, however, practical problems. Most coders aren't license gurus. The lists of licenses constantly evolve. If a code forks in two directions under two non-sharing licenses, it cannot be united back... These, and other problems may be solved by a special kind of license - a metalicense.

In its simplest form, a metalicense is a license that permits code to be used under any of the licenses in a list. A more complex form may include also a set of additional requirements and/or provisions, and to clarify their relations with the licenses of this list.

A metalicense can legally circumvent the non-sharing demands of the copyleft FOSS licenses. For example, if a code is licensed under a metalicense that allows using it with CDDL or GPL, it can be legally included in both CDDL- and GPL-licensed software. And if the derivatives of this code are also licensed under this metalicense, they will be compatible with both CDDL and GPL, too. Since the non-sharing part of most copyleft licenses is usually designed to ensure the freedom of the code, and not to lock it in, metalicensing a code to more than one of them should not be a contradiction to their spirit.

If a work is derived from two or more works, some under a metalicense and some under a specific license, or another metalicense, this work should logically be under the licenses and conditions that are common to all (meta)licenses involved. For example, if Program A is derived from Program B, which is under a (GPL, MPL or BSD) meta-license, and program C, which is under GPL, the Program A must be under GPL. (This paragraph was added later to the article - I believed this to be obvious, but noticed that some readers miss it.)

The maintenance of the license list itself may be transferred to a trusted entity, which cares to keep it in accordance with the original idea. Thus, even if the metalicense itself is non-sharing, it will allow using the code under an as broad range of licenses as desired, and to ensure that this range will include new licenses that match its criteria, without the need for the developer to constantly watch the license news, and to re-license again and again the code.

Most, or even all possible metalicenses may share the same main text, if it is carefully considered, and to differ only in the list of permitted licenses. This may allow also easy creating of specific metalicenses for those who aren't satisfied with any of the existing ones.

The licenses in the list may also be metalicenses. This allows creating a hierarchical structure of licenses on top of the current "flat" structure, which will permit the developers to easily and conveniently choose the level and type of license that gives their product exactly the degree and type of freedom they want. (Also, this may help educating geeks on license types and relations - by nature, they understand hierarchical structures much better than sheets of legalese. :-)

Finally, the metalicenses may be identified by a code system, allowing easy identification of the metalicense type and spectre. It can be easily derived from the place of a metalicense in the licenses hierarchy.

All these are definite advantages over the specific licenses, and developers will probably find metalicenses to be a better choice. New code may be meta-licensed instead of or in addition to specifically licensed, old code may be relicensed also under metalicense(s) where the author's intention allows for this. The more code is meta-licensed, the less the fragmentation of the FOSS code pool - and the better for us all.

3. A sample metalicense template

This is just a draft version, number 0.11. Any suggestions are welcome.

The GNU GPL license has been used as a base for most of the "legalese".

A real metalicense will typically (but not mandatorily) be created by filling here a licence name, maintaining entity name, and a list of permitted licenses (you may use the template in Appendix A of the sample metalicense). A rationale may be added, to explain the license in layman's language; a template may be found in Appendix B of the sample metalicense. Of course, you may also change the text and conditions in any way that suits you.

<license name>

1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law. Each licensee is addressed as "you".

2. You may not do anything with the Program except what is expressly provided under this License. Any attempt to proceed otherwise is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

3. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to do anything with the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by doing anything with the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions.

4. This License allows you to do anything with the Program in accordance with the terms and requirements of any of the licenses specified as permitted (further: "specified") in Appendix A, which is an inseparable part of the License. The list may contain additional conditions and requirements for doind anything with the Program in accordance with particular licenses.

An exclusion to this is the derivation of works from this Program. You are allowed to derive works from this Program only if the derivative works are released under this License. If this requirement conflicts with any requirement of a license in Appendix A, this requirement prevails.

If a work is derived both from this Program and from another Program governed by a different License, then this work must be governed by a conjunction of this License and the other License.

The License Controlling Entity may add new licenses to the specified in Appendix A, if these are considered to be within the scope of the original intention of the list. Such a change of Appendix A is not considered a change of the License. Adding a license to the list entitles this Program to be used under it, even if written and licensed before this change in Appendix A, unless explicitly stated otherwise.

The License Controlling Entity may remove licenses from the specified in Appendix A, if either their wording, or the wording perception is changed to become out of the scope of the original intention of the list. Such a change of Appendix A is not considered a change of the License. Removing a license from the list terminates the right to use the Program under it, even if written and licensed before this change in Appendix A, unless explicitly stated otherwise.

5. This License is governed and controlled by its License Controlling Entity. The control may be transferred on need, by mutual agreement, to another entity. Such a transfer is not considered a change of the License.

The License Controlling Entity for this License is currently <entity name>.

6. New versions of this License may be published from time to time by the License Controlling Entity. They will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published. If the Program does not specify a version number of this License, you may choose any version ever published.

Appendix A

Licenses permitted by <license name>:

The following Licenses once were in this list, but were removed from it, and therefore of this License:

This list was last changed on <date>.

The control over the License has been transferred, up to and including this version, as follows:

<a list of control transfers, containing entity names and data, and transfer dates>.

Appendix B

Rationale for <license name>. (Not a legal part of the License.)

This License is originally meant for the following cases and situations:

This License is not originally meant for the following cases and situations:

Reasons to use this License:

Reasons to avoid this License:

4. Proposed Metalicenses

This part contains few metalicenses that are proposed for usage. Currently, all of them are just drafts. Any suggestion on them is welcome.

4.1. Free and Open Source Software Global Meta-License (FOSS-GML)

Free and Open Source Software Global Meta-License
(FOSS-GML)

(draft version - 0.11)

If a work is derived both from this Program and from another Program governed by a different License, then this work must be governed by a conjunction of this License and the other License.

The License Controlling Entity for this License is currently Grigor Gatchev.

Appendix A

Licenses permitted by the Free and Open Source Software Global Meta-License:

This list includes all licenses that are both:

a) listed as "Free License" by the Free Software Foundation (http://www.fsf.org/licenses/license-list.html)

AND

b) approved/certified as "Open Source License" by the Open Source Initiative (http://www.opensource.org/licenses)

If a license matches both conditions, it is considered to be permitted by FOSS-GML. If a license does not match any of the conditions, it is considered to not be permitted by FOSS-GML.

If a license is added to both categories, it is considered automatically added to the licenses permitted by FOSS-GML. If a license is removed from one or both of them, it is automatically considered removed from the licenses permitted by FOSS-GML.

Appendix B

Rationale for the Free and Open Source Software Global Meta-License. (Not a legal part of the License.)

This License is originally meant for the case when one wants their product to be avaliable to use with every free license in existence.

The requirement for a free license to be acknowledged by both FSF and OSI is used for several reasons:

1. The double acknowledgement ensures that this license will not be cover for licenses that are not really FOSS licenses, but are approved by an entity for any other reason.

2. Giving decision role to both big centres of FOSS influence is hoped to decrease any partisan/fan bickering over the "free software" / "open source" differencies, and thus over the role of FOSS-GML.

This License is not originally meant for cases when one wants the availability of their work limited to only some FOSS licenses. The most frequently met reason will probably be avoiding the opportunity to proprietarise the code, thus keeping the derivatives away from the FOSS. (Some licenses permitted by FOSS-GML, eg. the BSD license, would allow proprietarising.) There may be other reasons and license choices, too.

The License contains a clause that requires the derivatives of its subjects to be also its subjects. This should not be a problem, since thus they are also available to every free license. However, if you would like to avoid this, include in the copyright notice inside your work a statement in sense that the work derivatives are free from the requirement to be licensed[[ek under FOSS-GML - the license permits it.

However, FOSS-GML is not a copyleft. It does by itself making the derivatives and/or the source code available under a free license; some of the licenses allowed by it demand this, but others don't. One may choose a non-copyleft license allowed by FOSS-GML, and to proprietarize code derivatives under its permissions.

4.2. Free and Open Source Software Derivative-Binding Meta-License (FOSS-DBML)

(Initially the name "Free and Open Source Software Copyleft Meta-License" was proposed, but was abandoned in favor of a name that appears to be more clear and better understandable by the non-geeks and the public. We, the geeks, know what this name is about, anyway. :-)

Free and Open Source Software Derivative-Binding Meta-License
(FOSS-DBML)

(draft version - 0.11)

The License Controlling Entity for this License is currently Grigor Gatchev.

Appendix A

Licenses permitted by the Free and Open Source Software Derivative-Binding Meta-License:

This list includes all licenses that match all of the following three conditions:

a) listed as "Free" by the Free Software Foundation (http://www.fsf.org/licenses/license-list.html)

AND

b) approved/certified as "Open Source License" by the Open Source Initiative (http://www.opensource.org/licenses)

AND

c) demand that all derivatives of a license subject must also be FOSS and copyleft (eg. may be used only under the same license, or another copyleft license that matches the other two conditions).

If a license matches all these conditions, it is considered to be permitted by FOSS-DBML. If a license does not match all of the conditions, it is considered to not be permitted by FOSS-DBML.

If a license at some point starts matching all of the conditions, it is considered automatically added to the licenses permitted by FOSS-DBML. If a license stops matching any of the conditions, it is automatically considered removed from the licenses permitted by FOSS-DBML.

Appendix B

Rationale for the Free and Open Source Software Derivative-Binding Meta-License. (Not a legal part of the License.)

This License is originally meant for the case when one wants their work to be available for as much FOSS licenses as possible, but only if they are copyleft, that is, they demand that its derivatives will be FOSS, too - thus preventing the stealing of the freedom of this work.

This License was not originally meant for cases when one doesn't care whether the derivatives of this work will be FOSS or not.

The License demands (predictably enough) that all derivatives of its subjects are also its subjects, that is, it is also a copyleft license. It is the only logical for a Derivative-Binding Meta-License.

Some licenses are considered to be strong copyleft by some sources, and weak copyleft, or non-copyleft, by others. This controversy is resolved when contesting a proprietarizing of code that is licensed under FOSS-DBML, and used under one of these licenses. If the specific license is interpeted to be strong copyleft, it forbids by itself the code proprietarizing. If it is interpreted to not be strong copyleft, then it is not permitted by FOSS-DBML, and the proprietarizing side cannot legally use the code in question under this specific license.

This article is distributed under the Creative Commons Attribution 2.0

You may reach the author at the e-mail "grigor", at the site "gatchev.info".