Benjamin Jean interview

Licenses are legal documents, and FOSS licenses did a relatively recent appearance. Are companies' procedures ready and compatible with FOSS licenses?

The sentiment is unanimously shared today: Free and Open Source Software have a revolutionary impact on the software industry. They allow a mutualized development, which is faster, more efficient and less expensive.

During the industrialization of Open Source Software, the first phase consisted in transcending "fears" of Open Source by taking into account the idea that benefits exceeded disadvantages. After that, FLOS (Free Libre Open Source) companies (publishers, service companies, manufacturers of components, etc..) spontaneously began to adapt their practice and organization, focusing more attention to contract documents – i.e. Free Licenses. Indeed, they do not have to simply allow or encourage the use of software which is licensed under free / open source terms, but they must secure and regulate their use too: the introduction of a third party code, free or not, is a risk that needs to be supervised. Technically control this code and the assimilation of the licenses that govern it is not enough, FLOS companies have to establish a fluid and thoughtful process of good governance as well. Therefore, there is no alternative but to adapt their behavior and processes around a number of issues about both contractual drafting associated with these practices and structural or organizational changes that need to be made. For instance, it is necessary to conduct an audit containing all the legal and licensing strategy for the open source company, which involves legal experts team up with computer, engineering and community experts.

Companies' procedures are thus generally not ready and compatible with FOSS licenses, but Open source is still young and I'm confident that the practice evolves in a good way. In fact, more recently, there is a trend which encourages mutualization around these practices by companies, whether through websites (like FossBazaar) or series of conferences (like ProFOSS, EOLE and other workshops).

Do FOSS licenses change the relation between a customer and its provider?

Yes, they do! Because they are sharing something which belongs to somebody else, they usually can’t “close” the software and they have to think about the sharing of their joint effort/contribution. In fact, we notice that, like communities, customers of an open source company are parts of the overall policy of its corporate governance. Something very interesting… Therefore, when the supplier develops or modifies software for one or many customers, specific issues related to intellectual property arise naturally:

• Who is the right holder? Usually the supplier will retain ownership rights to keep control over the future development of software and support the sustainability of the solution. Nevertheless, customers may ask for shared the ownership (ie joint tenancy).
• What are the rights granted? The assignment will be very often in accordance with terms of one or more free licenses (they can evolve during the software design).

On what type of contracts do FOSS licenses have an impact?

In each contract, we have to wonder what the use FLOS license will change: about IP, governance and relationship. In all contracts relating to intellectual property rights (specific development, integration solutions, outsourcing, consortium, etc.), but also in all the precontractual documents, we have to keep in mind the idea of sharing (non exclusivity is the main aspect of free licenses): If you choose to share everything, it will be easier to keep a global control on your contributions and to be (nearly) sure that you are not violating any free license. Then, in all contracts organizing corporate governance, i-e the relationships between multiple stakeholders (employees, community, etc.), it’s necessary to think about the control directly linked to the competiveness of the company and the freedom/sharing needed by the communities: for instance, concerning (joint) copyright assignment, the companies have to make a certain amount of promises/concessions to persuade contributors to contract. The only version of the GPL recognized by the FSF is in English. Is that a problem on contractual levels in European countries? Usually, free licenses are international contracts (i.e. elements of more than one country are involved) and thus are relatively emancipated from any particular law (except for Ordre Public law/public policy). This fact restricts, without removing, difficulties linked to the use of English.

• Only authors can choose and change the licenses: the licensees can not therefore discuss the various terms and their final understanding of the license may be very imperfect (source of defects of consent and so, cancellation of the agreement). It is in this way that consumers traditionally overprotected during their contracts with professionals, could validly challenge their commitments.
• Translations are not usually borne by the editors of licenses - even discouraged (except for the CeCILL EUPL, LAL, CC and some others). They are generally incomplete and only informative. However, they can throw light on a few concepts towards non-English speakers when they are attached to the main contract.
• Some national laws require governments, local authorities and other public entities to use the national language in their contracts (consequences are penalty and revocation of commitments).

Do customers really want to identify someone to sue in case of problems?

One of the functions of the company is precisely to be the interface between the communities and the Customer. We find de facto that the use of free software does not change their behavior very much: Customers want functional solutions and the provider must guarantee them.

To go further, we can notice that the combination of legal and contractual guarantees (such as non-eviction) and (compliance, etc..) gives the customer all the insurance it would have with a traditional software.

If yes, how does the provider find the right balance between making the customer feel confortable, without taking responsibility for things it can not control?
In any case of problem with an open source software, the supplier can always offer the customer a support and an assistance whose level is equivalent level than those of a traditional publisher. For instance, it is the subject of the offer “OSSA” (OpenSource Software Assurance): technical support services aim to improve the service offered to the client by providing answers to questions that may be asked during the deployment stage of the supported software or during its management.

If no, then why is it an argument we often hear from people feeling more comfortable with proprietary licenses?

This argument is what we call FUD (Fear, uncertainty and doubt): a technique use to discredit Open Source and discourage people from using it. Proprietary software may apparently give satisfaction to the general management unit and may be imposed in a "corporate" strategy – computer managers cannot always make their own decision in the choice of investment strategy. Because proprietary software is still considered as classical/normal, customers are more confident about the way it works: in the opposite, Open Source companies are younger, unknown and their strength unsure. Competition between open-source and proprietary software will remain an unequal struggle as long as people won’t think differently.

So, it is important for the operational departments to secure their general management on FOSS issues in a better way and have to involve each department which is interested in order to target a more efficient strategy and avoid some preconceived ideas on that matter.