Free and Open Source Software: opportunities and challenges

Free and Open Source Software (“FOSS”) is everywhere. What was once considered a twist to software licensing is now the bedrock of the software landscape

Software developers, unless for sensitive work and applications, use and incorporate FOSS in their developments, ie software that:

• has been created by others;
• can technically easily be downloaded from the web;
• is available in human-readable/source form; and
• does not involve money.

This definition partially only overlaps the Open Source Initiative definition, to reflect the actual variety in the field of instances of web download and re-use.

1. FOSS is Pervasive

“Software has eaten the world and open source has eaten software” (from Heather Meeker in “Open Source for Business”). FOSS re-use has been a fast-growing development practice for decades, including at Companies with a business model based on licensing for a fee proprietary software as a Company Product, whether distributed as a copy or made available as a service. Once considered a business disturbance by some, the practice is now widely embraced, sometimes as a necessary evil to meet development productivity requirements, sometimes in connection with definite opinions around software availability freedom. Whatever the motivation, adopting the practice in full consideration of the potential consequences is advisable.

2. FOSS Challenges

Downloading and incorporating FOSS in a Company Product carries with it a number of challenges and risks.

A. No Warranties or Indemnification

There is little or no recourse in case «something goes wrong» technically or legally, with the FOSS incorporated in the Company Product. Indeed, most licenses that accompany FOSS include an express exclusion of warranty, indemnification or any form of liability on the part of the copyright owner (usually the author or the assignee of its rights).

Thus, if, as is often the case, Company assumes with its customers any kind of liability vis-a-vis the Company Product, it takes on an uncertain level of liability as regard the incorporated FOSS. For example, granting customers patent infringement indemnification on delivered software when FOSS is involved, ie: a piece of code developed by a 3^rd party for which no one other than Company may be responsible, may be a risky proposition of unknown proportions.

B. Copyright Infringement

A long and generally accepted principle is that software is protected by copyright and contract laws. The prerogatives of the copyright owner amount in most countries to (i) preventing others from using, copying, modifying, or distributing the software, and (ii) being able to impose, in relation to the using, copying, modifying, and/or distributing, conditions of its choice to others, through a license accompanying the software.

FOSS as a software is no exception: in a vast majority of cases, it continues to have a copyright owner, and no surrendering of (copyright) rights results from the mere act of circulating or publishing a copy of the FOSS: indeed, transferring the physical property has no bearing on the intellectual property ownership or licensing. The FOSS is presumed to be available under permissions and conditions listed in an accompanying license, that the recipient of the FOSS is presumed to have accepted by manipulating the physical copy of the FOSS.

Thus, several situations may give rise to copyright infringement claims for having incorporated FOSS into a Company Product, among which:

• use of the FOSS has gone beyond the express permissions in the license: for example, incorporating the FOSS into a Company Product, while non-commercial use only was permitted;
• FOSS has been used not in full compliance with all imposed conditions in the license: for example, making modifications to the FOSS that, despite specific requirements in the license, are not prominently flagged in the modified FOSS incorporated into the Company Product.

Additional risk may be incurred when FOSS is used despite uncertainty as to the actual copyright owner, or as the actual applicable license (a not so rare situation).

Legal remedies to copyright infringement, depending on the jurisdiction, expose the Company to statutory and/or actual damages, and/or injunction to have to stop using the incorporated FOSS, with clear commercial consequences for the Company Product. Beyond, if the infringement makes «internet buzz», reputation of the Company may be adversely affected.

C. Unduly Surrendering Company Intellectual Property Rights

Conversely, complying with certain conditions imposed in a license of a FOSS incorporated into a Company Product, may expose the Company to unduly surrendering certain of its intellectual property rights.

For example, as regard copyright, a license may require that any modifications to the FOSS by the Company be made available to others under terms identical to that of the license. This may notably become problematic if the scope of what constitutes a “modification” under the license purports to extend to adjuncts of Company proprietary code to the FOSS.

As regard patents, beyond an implied limited scope patent license that may come with (copyright) licensing of the Company Product, a license for the FOSS incorporated into a Company Product may purport to result in the Company granting an expressly scoped larger patent license under Company patents to recipients of the Company Product.

D. Vulnerabilities

FOSS attracts hackers attempting to exploit its vulnerabilities, especially when widely used by many commercial products as de-facto standard library or routine. Fortunately, owing to FOSS being supported by communities and/or being available in human readable form, fixes often also become publicly available to correct such vulnerabilities. Specific means however need to be put in place by Company to both timely detect the availability of such fixes, fetch them, and deploy them wherever the FOSS to be fixed is incorporated throughout Company Products.

3. The Need for a Process to Handle FOSS in Company Products

These means to be put in place may take the form in the Company, of a policy and/or processes to govern use and incorporating of FOSS into Company Products while addressing all the FOSS challenges above. As a compliance issue, it may be handled differently depending in particular on the size of the Company and its business model: the importance of keeping Company Products proprietary, the number of copies of Company Products, a B2B or B2C Company Product distribution model, simultaneously developing of a Company patent portfolio, etc. The implementation of such a corporate process takes a toll on Company's operations and resources, and its scope has to be carefully weighed against the perceived challenges the process is meant to address.

Any FOSS corporate process is however likely to touch at least on the following points:

• addressing all possible entries of FOSS in the Company, either through downloading from the Internet by in-house developers or by contractors, or purchasing software from a supplier;
• subjecting the FOSS adoption to an internal approval process that accounts for technical, business and legal considerations;
• enabling the tracking and storage/retrieval of approval decisions, approved FOSS versions, and Company Products having incorporated which FOSS;
• requiring systematic web collection of updates to approved FOSS, and deployment of such updates in Company Products; etc.

Such a FOSS corporate process may in addition be optimized through:

• depth, level, and internal delegation of the approval activity which may be tailored to the perceived risks depending on the FOSS, its license, and/or the Company use case; for example, incorporating a FOSS into a Company Product made available as a service may be less risky than if copies of the Company Product are distributed;
• proper involvement and breakdown of responsibilities between Company functions: Development, Procurement, Sales, Legal;
• records of approval activities that may serve as precedent for future decisions;
• use of a tool for scanning FOSS or, before release, the Company Product incorporating the FOSS;
• maintaining an in-house approved FOSS repository;
• thorough training of Company employees around FOSS issues;
• coupling FOSS corporate process to other Company policies and compliance efforts; etc.

The final shape and form of the adopted FOSS corporate process achieves, for each Company, the «right» balance between risk taking and cost of process implementation.

4. Companies with a Patent Portfolio

There is no incompatibility in using FOSS for business with simultaneously developing a patent portfolio. All of the major IT companies owning huge patent portfolios constantly balance their interests between open and proprietary software: a FOSS corporate process helps them with that.

Besides, FOSS licensing is for the most part about copyright, not patent, licensing. If Company owns both a patent for a concept, and the copyright in some code as one way of implementing the concept, open sourcing the code grants others access to that one way of implementing, not to other ways/code of implementing the concept, leaving mostly intact the value of the patent.

Thus, a FOSS corporate process should factor in the patent dimension if a patent portfolio is of importance to the Company, for example through reviewing more specifically:

• FOSS licenses with express patent license language;
• that no Company patent reads on 3^rd party FOSS that Company distributes; or
• that when Company decides to release its own code under FOSS-like conditions, it does not also unduly grant patent licenses under its own patents.

5. The Case for Open Data

Company might wonder whether to include open data as part of the above process. Indeed, recent developments in machine learning have triggered many attempts to import the FOSS concepts, from software to data and databases. The underlying driving force being the need for collaborative frameworks to access and augment large sets of data that are fundamental to the creation of quality predictive models. Recent efforts, such as: Towards Standardization of Data Licenses: The Montreal Data License are laying the foundations for common frameworks for data licensing akin to the licensing of FOSS (of course, uncertainties remain as to whether both, FOSS and open data, are subjected to the same underlying laws: in the United States, cf: Feist, databases enjoy only very thin protection under copyright law, and even though the European Union has enacted sui generis law on database protection, cf: Directive 96/9/EC, it has been subject to little interpretation in the courts yet).

Should you have any questions regarding this article, copyright, open source or patents in general, please do not hesitate to contact our team.