Metalicensing

38

Author: Grigor Gatchev

The free and open source software world offers many different licenses, and this richness has both advantages and disadvantages. On one hand, developers differ in what they want to let others do with their code, and consequently need different licenses. On the other, many licenses do not allow anyone to use the code to which they apply inside products governed by other licenses (cross-license sharing). But this problem may be solved by a special kind of license — a metalicense.

A wide spectrum of free licenses is a good thing, since if a developer cannot find or create a license that meets his vision of how people should use his product, he may refrain from freeing it. In the open source world, licenses range from BSD-type licenses, which allow completely free usage of the software without any limitations, to GPL-type licenses, which demand derivatives of the software to be also free (sometimes called copyleft licenses).

However, this abundance of licenses is also a disadvantage for FOSS, since it fragments the open source code pool between the different licenses, and thus hampers the growth of a common code base, one of FOSS’s greatest strengths.

Often the barrier erected by disparate licenses is neglected. You can find such “illegal” cross-license code sharing in most big FOSS packages, as a means to retain the code pool integrity. Few people seem bothered by this practice, but it is a potential problem, and we would be better without it.

We can’t avoid license fragmentation, as it is the inevitable price of the objective need for different license types. However, from a legal viewpoint, the FOSS pool is already very fragmented. While much of it is still governed by the GPL, there are already a lot of GPL-like and BSD-like licenses. If things continue this way — and they are going to — we may soon have license wars inside FOSS, which is a problem we don’t need and must do everything we can to avoid.

One possible approach 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 would be hard to achieve and fragile to keep.

Another way is to mediate negotiations between these holders for “cross-licensing” that allows sharing of code across the free licenses. However, this too 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 metalicensing.

Metalicensing basics

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 a set of additional requirements and provisions.

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 Sun’s CDDL or the 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 the copyleft spirit.

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

Many possible metalicenses may share the same main text, if it is carefully considered, and differ only in the list of permitted licenses.

The licenses in the list may also be metalicenses. This would allow a developer to create a hierarchical structure of licenses to allow. It might also educate developers on license types and relations, since they understand hierarchical structures much better than legalese. 😉

All these are definite advantages over the specific licenses. New code may be metalicensed instead of or in addition to specifically licensed, and old code could be relicensed under metalicenses. The more code that is metalicensed, the less the fragmentation of the FOSS code pool — and the better for us all.

To see a couple of examples of possible metalicense wording, please visit the author’s page.

Category:

  • Free Software