A short guide to applying open licences
Open licences are an alternative way of managing copyright on IT works. Their function is to replace the exclusive rule established by law — “all rights on the work are reserved to its author” — with a grant of some of those rights to third parties. Whoever uses an IT work under an open licence acquires the right to access the source code, study it, copy it, modify it and distribute it. In this way the use is open to a vast community of users, the development of the work of intellect becomes faster and at the same time better results are obtained from the point of view of efficiency and product stability.
If these are the advantages of adopting the “open” economic model, from a legal point of view, however, the information gap of the sector has led to an “AS IS” approach to using licences, raising issues related to the effects and validity of the clauses contained in them.
Operators often use programmes under different licences, re-elaborating them or combining modules of different works without considering that these operations are indeed allowed, but under the conditions described in the licence governing the individual programme. In the IT field it is believed that one can “do everything” with the code: this is true only in the abstract. In market reality, however, code encounters the limits of law. In this sense, that “do everything” must turn into “you can do… all the operations envisaged by the licence”.
Where the operations do not respect the licence clauses, and further, where the licences do not respect the mandatory rules set by the legal system in which they must be applied, then the permissions granted by the author cease to be effective and the exclusive “all rights on the work are reserved to the author” returns to having force. The OSI Definition itself states that “Considering a licence as something separate from the body of applicable laws (in that State) is as foolish as considering an English-language document separate from the dictionary of that language, a case in which no word would have a definite meaning”. In fact, what was said may pose serious problems to the dissemination of works, frustrating the meaning of “open source”.
The series of articles that follows aims to bring some clarity to the world of licences and draft general guidelines for their application, warning, however, that each of these — once chosen for the release or commercialisation of a product — requires the specific study of an expert eye.
Compatibility among open licences and between open and proprietary licences
For a company adopting the open business model it is fundamental to be able to create products from the combination of code belonging to software released under different licences. In this economic model, the creation of a programme rarely takes place from scratch: it is the reuse of others’ creations — to which a new destination and function are given — that constitutes the fulcrum around which the creation of the work revolves and is, in a broader perspective, the engine of the entire “Open Business Community”. If these are the needs, they cannot always be satisfied. Much depends on the type of regulation imposed by the licences governing the works to be combined.
In concrete terms, therefore, the issues at hand are of compatibility. For the company it is necessary to know the clauses concerning the possibility of derivation and their effects: violating them, indeed, means losing the possibility of releasing the programme or, where one decides to release it nonetheless, incurring a copyright infringement.
Proceeding by category, on this topic two general orders of issues can be identified:
- Compatibility between two or more programmes both released under open licences
- Compatibility between programmes released under open licence and proprietary programmes
Compatibility among two or more programmes governed by open licences
Developing with open software does not mean being able to use the source code of a programme in any way: it is still necessary to abide by the rules established by the licence under which it is released.
Open licences, in fact, are not necessarily compatible with each other: in the case of two codes under different licences it is necessary to verify whether the clauses specified in one are compatible with those laid down in the other, and under what conditions. In general, where both licences are characterised by copyleft clauses, an incompatibility situation is created; for example, if one licence requires that all derivative works be released according to its content and the other has the same prescriptions, the software resulting from the combination of the two codes should simultaneously respect mutually exclusive conditions. Another case may be the policies pursued by the licences regarding patents: for example, the Apache 2.0 licence and GPLv2 are incompatible; on the compatibility between Apache 2.0 and GPLv3, however, the discussion is open (it should be noted that the FSF considers the two licences incompatible, although on close reading of the latest “Stallman house” version no substantive differences seem to exist).
In general, it can be concluded that among open licences we speak of incompatibility every time not all the clauses of the licences governing the original products can be respected by the derivative work. This conclusion is undoubtedly compliant with what is provided for by Italian copyright law (l. 633/1941), which at art. 4 states that:
Without prejudice to the rights existing on the original work, creative elaborations of the work itself are also protected, such as translations into another language, transformations from one literary or artistic form into another, modifications and additions that constitute a substantial reworking of the original work, adaptations, reductions, compendia, variations not constituting an original work.
The law, in stating that derivative works are also protected by copyright, indicates that this is possible provided the condition of not causing prejudice to the rights existing on the original work is respected: rights that, in the case in question, are those governed by the original licences.
Compatibility between open and proprietary licences
The open world and the proprietary world, contrary to what is thought, are not necessarily in conflict.
Some companies set their commercial policy by trying to make them coexist; at other times still, incorporating open code into a programme under a proprietary licence goes beyond corporate choice and becomes a necessity due to the costs of realisation and, why not, to the quality of the product that often becomes a standard of use (for example in the case of certain libraries): from the perspective of this policy the choice of licence is fundamental.
That said, it should be noted that some licences are completely incompatible with proprietary ones and absolutely do not allow operations to create derivative works resulting from the combining of proprietary software with open software. GPL, for example, being characterised by very strong copyleft, requires that a work resulting from a fusion of distinct codes belonging to different software be released under GPL; where this is not possible, the software under GPL cannot be used. Other licences such as MPL allow the creation of mixed derivative works (and even their release under proprietary licence), provided the operation occurs through the association of modules and the proprietary module and the one under open licence remain separate. There are then particularly permissive licences such as BSD and the BSD-style licence family that allow any kind of operation on the code, provided that the authorship of the work is given evidence and the regulation indicated therein for the use of the trademark and the distinctive signs of which the author is the holder is respected. In this case the software house can link proprietary code and open software without any compatibility issue.
In conclusion, it is appropriate that, at the design stage, a study is provided for the licences of the software products one intends to use and their interactions. The aim is to apply the business model chosen by the company governance without incurring the dangers of a violation of intellectual property rules, which may cause sanctions and prevent the commercialisation of the product.