The internet is an Aladdin's Cave of open source software and shareware, but commercial developers who use this free coding in their own software products without regard to the licensing terms and conditions could find themselves in hot water.
Open source software (OSS) commonly refers to a computer application that is made widely available by an individual or group in source code form for use, modification and redistribution under a license agreement that contains few restrictions. The number and types of OSS, freeware and shareware products available have grown exponentially. OSS can be used in business models on a day-to-day basis with great success. Many developers successfully integrate OSS into their products in a way that respects both the underlying source code licence and facilitates their businesses. However, some developers fail to recognise that, although they don't have to pay for it, OSS is third-party software and subject to terms and conditions that need to be respected.
The licences that apply to these sorts of products vary considerably and range from very prescriptive licences to those that simply request an acknowledgement in the authorship credits. It is hard to come up with a definition that fits all types.
Quite a few OSS licence models trigger an obligation to disclose source code that was developed using an OSS product. Often the developer must also license the source code he develops on the same terms as the original OSS if the developer chooses to distribute the developed software. Developers will need to consider the terms and conditions that apply to new code very carefully when this sort of OSS licence applies. Such issues frequently arise with GNU General Public Licences (GPL). However, not all OSS licences fall into this 'copyleft' model, as the BSD Licence and the Apache Licences demonstrate.
Why You Can't Ignore It
There are a number of key reasons why OSS licences should not be ignored by commercial developers; a few of which are dealt with here.
Undermining the Value of Your Creation
Developers undermine the value of software as an asset by introducing a piece of foreign code into the product and failing to abide by the terms and conditions applicable to its use. Time and time again in the course of due diligence, purchasers and venture capital companies will identify the use of OSS in breach of underlying licences and will factor in this negative consideration when determining their view of the value of the asset, and consequently the company. This is not a hypothetical scenario; we see it on a regular basis.
OSS issues such as this may or may not cause a deal to flounder. Where an OSS licence breach is not a 'deal breaker', it will often result in onerous obligations being placed upon the sellers and/or the investee company. Purchasers or investors may require, as a condition of a transaction, the removal of the code from the product. This requirement can impact on a product's roadmap rollout. Alternatively or in addition, onerous indemnities may be sought, frequently personally from the shareholders of the developer. In some cases, the overall value of the investment or purchase price may be reduced to take account of the OSS risk.
Breach of Customer Contracts
As often as not, customer contracts relating to software include assurances from the licensor in relation to its ability to licence the intellectual property rights in the software. Licensors are often requested to give onerous warranties and indemnities that use of the software by the licensee will not infringe third-party intellectual property rights. However, developers will be in automatic breach of such assurances from day one of the contract if they have failed to comply with the sub-licensing conditions in an OSS licence. Licensing a product which breaches a third party's intellectual property rights is often considered a material breach of the customer contract.
Of course, if a developer breaches a third party software licence, the risk of litigation arises. There are a number of examples of high-profile litigation cases in recent years where OSS licensors have taken actions against developers that they claim have breached their licences.
Guidelines for the Use of OSS
Developers should take a few messages away when considering this article.
By all means use OSS, but, as with any other third-party intellectual property, be aware of the terms and conditions that apply to the material that you intend to use. There is a great temptation for developers to use pieces of code, computer applications, libraries and other shortcuts available on the internet and to do so with impunity when there is a solution to their coding problem available at the click of a button. OSS applications are available and capable of being installed instantaneously, without negotiation or payment, by a few simple clicks. However, it is legally and commercially naive for a developer to ignore the terms and conditions that apply to such software products.
Consider who your clients are. Some organisations have taken policy decisions and will not accept OSS as a deliverable from developers. Engage with your clients early regarding your use of OSS so that you can identify where this issue arises. Do not ignore the issue as it may become much more difficult to deal with it during the preparation of commercial contracts or, worse still, during performance.
Where you decide to use OSS which involves 'copyleft'-style terms that require you to (a) disclose code which has been developed using the original OSS code, and (b) allow it to be licensed on the same terms, ensure that you are comfortable releasing and distributing your developed code in this way.
Have an Informed Workforce
There is no point in being savvy and clear about your OSS policy at board level only to find that your employees have been using OSS without your knowledge. Train and educate those working for you so that they have a clear understanding of the consequences of including OSS in your product. Ensure they get clearance for, and keep a copy of, the licences that apply to the OSS code that they use. And consider your licensing model. Some licence types are simply not compatible with other licence types. When bundling the software you have developed with third-party software, you need to take all parts of the product into account. Seek legal advice if you are not sure. It is better to deal with the issue from the outset rather than pay the price later.