Many software developers work under the following false misconception: “Open Source Software (OSS) is freely available, so I can use it without any kind of restriction”. This is completely wrong: many OSS, even when freely available, are in fact governed by their own licensing conditions, which imply, in most cases and depending on the use of the OSS, strict contractual licence restrictions.
Lack of awareness regarding the existence of such restrictions, poses serious legal risks for companies developing projects which include OSS, not only for those developing their own projects with their own resources, but also for IT providers who involve OSS in their software development projects to clients. Nowadays in most of the IT-projects OSS is used in one way or the other.
Either way, the normal expectation of someone ordering customized software is that intellectual property rights over the desired software are to belong exclusively to the client. This is even more relevant when the client will include the software deliverable into its own IT systems. This can be seriously jeopardized if the deliverable includes OSS, or if OSS has been used during the development process.
An example will help to understand the problem: a car manufacturer wishes to develop some customized software to handle lifecycle management, with the aim of increasing production efficiency of its newest car models. Logically, the car manufacturer wants to control all aspects of such production process, and especially intellectual property of any and all tools used or results obtained, to avoid any risk of losing control over its most valuable assets (car models and esp. their production processes). If the customized software includes certain types of OSS, the car manufacturer will be forced to publicly disclose and share with anyone who requests it the whole source code of such customized lifecycle management software, even those parts of it that were not included in the original OSS.
Is the car manufacturer ready to face the risk of all its competitors gaining access to its own production procedures governed by such software?
Contents
What are the main risks?
Some OSS licensing conditions include amusing obligations, such as buying the OSS creator’s latest book as the Jason Hunter Licence is requesting. But other restrictions included in OSS licenses turn out to be not funny at all when you expect to have all intellectual property on everything that you develop or receive, as there is:
Infection effect: certain uses of specific OSS (such as GPL, LGPL, AGPL, CDDL, Mozilla Public License and Open SSL), can cause the entire resulting software development to be governed by the respective OSS license. Therefore, even though the company using such resulting software will be recognised as its owner, this ownership will not be exclusive. The software will be subject to compliance with the very same requirements that were applicable to the OSS component used, thus turning the resulting software into a de facto OSS.
Combination of certain OSS with proprietary software: from a business perspective, this risk derives from the fact that such combination may cause the resulting software to be affected by the aforementioned infection effect. This is the case, for example, when using OSS such as GPL, LGPL, AGPL, CDDL and MPL. Other OSS (Apache, Artistic, Eclipse Public License, BSD, MIT, W3C, Antlr2, Bouncy Castle, Creative Commons or Jason Hunter Software) allow such combinations without hindering exclusive commercial distribution by the company.
Disclosure of complete source code needed: Mozilla Public License, GPL, CDDL and older versions of LGPL, also partly due to the infection effect of those OSS, include the obligation to disclose the entire non-OSS source code which includes the OSS or which has resulted from a modification of these types of OSS.
Commercial distribution not permitted: other OSS licensing policies (Jason Hunter OSS License, Java Enterprise Edition and Oracle, for instance), do not allow to commercially distribute any deliverable which includes them. Thus “selling” or “renting” of deliverables containing OSS that falls under these licences is not permitted.
Clear license prohibitions to modify or to embed OSS for or within a software deliverable: this happens, for example, when using Sun Binary Code License and Oracle Binary Code.
These are only the most important risk situations caused by OSS licenses. But nearly all of them include other conditions (such as the need to include copyright notices, or fulfil certain technical obligations). All of them are ignored by most software developers, and place IT vendors and their clients into serious legal risks.
Case law because of the violation of contractual obligations
The above described risks are not just theoretical. On the contrary, they are completely real, as evidenced by the existence of many judicial decisions about this fact in various jurisdictions.
Particularly, a number of these court rulings concern violations of GPL OSS licensing conditions, due to it being one of the most popular and widely spread. Such violations mainly involve modifications of GPL that fall under the restrictions of licensing conditions set forth by such OSS. The most recent judicial decision, from June 2013 of the District Court of Hamburg, is not an exception and in fact involves the modification of OSS software without complying with license terms.
This ruling settles a dispute between the developer of an OSS component governed by the GPL v2 and a hardware manufacturer who had included said OSS component in his own developments, without disclosing the complete source code as required by the license. Prior to these legal proceedings, both parties had resolved an identical dispute through a private agreement, in which the defendant agreed to pay a fine in case of future violation.
When the hardware manufacturer committed a further violation of the license terms by not making the source code available, the OSS developer initiated legal proceedings. Even though the defendant argued that the component had been provided by a third party, and thus it was not himself, the hardware manufacturer, who had committed the violation. However, the German court ruled that not disclosing the software’s source code constituted a violation of the licensing terms governing GPL and, thus, the OSS developer’s copyright, in breach of the previous agreement between the parties. The hardware manufacturer was ordered to pay damages in accordance with said agreement and the license fees owed as a result of the sales of the defendant’s developments.
This judicial decision implies the curious situation of being forced to pay damages by using software which is free of charge. However, the other risks described (disclosure of whole source code, or the infection effect), are much more important than a potential compensation of damages due to a breach of the corresponding OSS contract.
However, court rulings do not only concern the more serious risks that a company could face for violating OSS license terms. A ruling from the federal appeals court in Washington, USA, 13th of August, 2008, concerning non-compliance with the terms of the Artistic License vacated previous judgement from a District Court, which had considered that the terms of the license were “intentionally broad” and thus the license was “unlimited in scope”, meaning that the recipient could use the OSS in any way he desired.
In this particular case (Jacobsen v. Katzer), portions of the software developed by an OSS group were copied, modified and distributed by Katzer as part of Katzer’s own software without following the conditions set in the OSS license terms. Although the defendant admitted this fact, he argued that it did not constitute copyright infringement because he had a license to use the material. Instead, it could only be considered a mere breach of contract for not complying with the license terms. Jacobsen, on the other hand, argued that the conditions set by the Artistic License defined the scope of the license, and therefore any action that exceeded these restrictions would constitute copyright infringement.
The court found that the terms of the Artistic License did in fact limit the scope as “enforceable copyright conditions” and noted that ”a user who downloads the (…) copyrighted materials is authorized to make modifications and to distribute the materials “provided that” the user follows the restrictive terms of the Artistic License”.
This particular ruling only reinforces the validity of the conditions set by OSS license terms as limits to their scope. Thus, when handling and/or incorporating OSS components, it is essential to keep in mind that such component might only be free to use if the company follows all those requirements set forth by the applicable license.
Other threats because of the violation of statutory law
Under several jurisdictions and local laws, each company needs to ensure by an appropriate organisation that neither the client nor the own company suffers damages. When using OSS, the IT-provider is not only risking to violate the licence of the respective OSS, his obligations towards the client but might also infringe copyright law that in some jurisdictions also foresee criminal prosecution in case of a wilful violation of a copyright.
All responsible of IT-providers that are not introducing appropriate workflows in order to avoid the violation of contractual or statutory law endanger thus not only their own company with administrative fines (such as para. 30 of the German Administrative Offences Act – Ordnungswidrigkeitengesetz) but could also face sanction deriving from labour law. It seems quite obvious that the party responsible for the production of software within the organisation of an IT-company not insuring that the rights of the OSS-licensor and the rights of the client are not infringed is not properly carrying out his duties.
In addition, this situation might trigger Corporate Criminal Responsibility arising from copyright crimes, if incurred by employees, managers or providers in the own benefit of their respective companies.
A solution
Handling these risks is not simple, but it is however possible with a certain degree of effort and creativity. This is one possible suggestion about how to do it:
- First and foremost, it is essential to become aware that the problem exists.
- When being a software provider or IT-developer get the buy-in of the management and the technical staff in your company;
- After that, all OSS components used or included in projects under the responsibility of the developer must be identified.
- Once this has been done, it is necessary to review the OSS contractual conditions that apply to each specific OSS component used.
- Next step is to conduct an assessment of the impact that OSS licensing conditions have on the contractual conditions that have been agreed on with the client of the IT developer. In the event that it is the company itself who has developed with its own resources or those of a third party, assess must clarify if the company is to be impacted by the above described OSS licensing risks.
- This will lead to an analysis about how the risk can be reduced or avoided, if possible. There is a variety of solutions available, which might consist, amongst others, in negotiating specific contractual conditions with the client who will receive the deliverable involving OSS, including certain disclaimers in agreements with clients, providing training to technical teams about how to fulfil OSS contractual conditions, etc. But in most cases the best and easiest solution is to find technical alternatives to the use of the problematic OSS. Generally clients feel very uneasy when they need to discuss issues, like the use of specific OSS in the deliverable, they are not familiar with. In our experience it is generally easier to adapt technical solutions and find a workaround than negotiating clauses permitting the use of OSS. In a lot of contracts the use of OSS is simply not allowed.
- Final natural step will be to create internal policies and procedures for the future involvement of OSS in software development projects, in order to quickly detect associated risks and handle them properly and in timely fashion. Here again you need the complete buy-in of the management and the IT-staff of your own company.
Conclusion
If your software development team, or your software developer vendor, keeps saying that there is no problem at all in involving OSS in development projects, what you will receive as a result will be like being gifted with a Trojan horse standing on a minefield.
A legal analysis and risk assessment is necessary to properly address this situation, as well as establishing procedures to enable the involvement of OSS or, at least, that it does not imply undesired negative effects.