Roundtable "Potential of OSS for ATM" - Jointly organized by CALIBRE and EUROCONTROL
Previous 7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France Next

Home

Intro

Programme

Synopsis

Abstracts

Participants

Debriefing

Glossary

Organisation

Short bios

Thanks

Follow-up

Permissive vs Restrictive OSS Licences

by Delphine Prieur, INRIA

Overview

Legal aspects of Intellectual Property protection vary from country to country. This presentation discusses OSS licenses, often from a French point of view, and deliberately avoids the issue of software patents, instead focusing on copyright protection. From the onset, two points are worth noting: a proprietary license can be more permissive than an OSS license, and OSS licenses are an original way to use copyright.

Software is an IP tool protected by copyright. The legal protection of software is divided between moral rights (droits patrimoniaux) and economic rights (droits commerciaux). Copyright law grants a monopoly on the work to the author for these two types of rights.

Moral rights in software is essentially to be able to oppose modifications when they would be harmful to the honour of the author, or his reputation. Economic rights are usage rights such as reproducing, translating, modifying the software. The duration of the monopoly is very long: almost 70 years after the first display. Protection is automatic; the author needs no formalities to be protected.

So then, what exactly is a license? It is a charter of rights and duties, a contract in which an author, while preserving the whole property of his work, confers to a certain extent, the possibility to a licensee to implement his rights. Some people consider that a license is more or less permissive when the possibilities offered are higher, or vice-versa. For OSS, another way to express this dichotomy in a more positive way: the rights granted to the licensee have to be implemented with more or less reciprocity. In other words, the more freedom you have, the more responsibility you must feel.

Two categories of licenses are frequently identified: proprietary licenses and Open Source licenses. Without delving into the differences between the Open Source Initiative (OSI) definition and that of the Free Software Foundation (FSF), we can note that OSS licenses are based on copyright law, but used in an original manner to produce the desired effects. Often called copyleft, OSS uses copyright. It is different from the public domain. Whether it's because it's no longer protected, or because the author has chosen to place his work in the public domain, the point is that no one can reserve property rights on the public domain. OSS copyleft, in contrast, exists solely because of copyright law.

The natural legal risk for Intellectual Property Rights is counterfeiting, a notion that is left to the appreciation of the judge, on the basis of many different criteria that vary greatly from one country to another. Proof of counterfeiting is usually based on resemblances rather than on differences: copied code (the easiest case), sequences of screens, order and logical organization of functions and control structures, in one case even spelling mistakes in code comments. Punishment for counterfeiting can range from monetary compensation to prison time.

In the world of OSS licensing, despite there being around 50 different licenses out there, we can concentrate on three major ones right now: 1) GNU/GPL, the most visible, widely used and also most criticized, 2) CECILL, a recent GPL-based license produced by CEA, CNRS and INRIA to fully comply with French law, and 3) the new BSD license, permissive and succinct, as opposed to the GNU/GPL. The current trend is to try to reduce this number, and this is a hot topic within the community.

Let's look at these three approaches to OSS licensing a bit more closely:

O. Robert: The older BSD licenses had a so-called "advertising clause" which stipulated that code using the BSD licensed sources had to have a screen advertising that the code contained parts licensed under the BSD. Current BSD versions no longer use this clause. Compensation resides in keeping copyright notices and license terms intact. The BSD license is the canonical example of a non-copyleft OSS license.

A few points should now be noted: first, the legal framework has not yet been tested. Few cases have been tried, and there is a movement from considering them as natural risks (counterfeiting) toward examining them for contract compliance. Those few cases tried have not attempted to validate the GPL, rather they have targeted whether the users have been complying with the license.

Lloyds insurance is studying insurance coverage of up to $10 million for damages, including profit losses related to non-compliance with an OSS license. In some cases, the policy could cover the cost of repairing the code found to infringe on an OSS license.

With regards to the number of IPRs, conflict brought to court are rare, lots of them are solved by arbitration or transaction and are kept secret. No one has an interest in invalidating an Open Source License, the consequences would be worse than the initial problem. Besides that, these legal issues are complicated by the multiple nationalities in presence, and the same is true for liability.

A crucial point is that the multitude of licenses generates compatibility problems between these licenses. For example, BSD is compatible with GPL, but GPL is not compatible with any other licence.

O. Robert: GPL is not even compatible with itself.

For OSS-based business models to be safe, new concepts were developed like OCC management, tests of source code infringement. A new prototype is being developed by the INRIA, to diagnose the legal status of a source code.

One of the extraordinary forces of OSS is the community. The OSS community can often react to programming bugs within 24 hours. Now the OSS community is defending the rights of the authors with tools like the web site gnu-violations.org, based on the compliance to the GPL license.

In conclusion, when choosing a license, it not important to consider whether it is permissive or not, but to ask the relevant questions such as: what are your intentions for development, distribution, and modification of your code? What is the status of the contributions of people? Who will use the code, why, and to do what? It is important to keep in mind that these intentions may change, so you should use a flexible model.

Discussion

from 15'00" to 15'29" (29")

J-D. Frayssinoux: About your slides, they will be available?

D. Prieur: I was late, but I gave them to the organizer.

Salient points

 
Delphine Prieur
 

"Licensing:
the more freedom
you have,
the more responsibility
you must feel."

Abstract Text Slides MP3 OGG
abstract text slides MP3 OGG

INRIA logo