“The roads we take are more important than the goals we announce. Decisions determine destiny.”
Frederick Speakman
Abstract
This article provides recent research results from the European Union's FLOSSMetrics project. The results focus on the business and practical aspects of the adoption of open source within software products or as a basis of service offerings. Research into free/libre open source software (F/LOSS) is usually conducted with a software engineering focus or with an emphasis on F/LOSS as a spontaneous or directed collaboration effort. The FLOSSMetrics project expanded that research with an investigation on how licenses, business models, and project choices affect development and productization. This article provides a summary of common licensing issues and business models choices in F/LOSS, and it provides a list of recommendations for selecting a license for a software project to suit both business objectives and licensing constraints.
Introduction
There are literally hundreds of different licenses for free/libre open source software (F/LOSS), the majority of which are used for only a single software application. As of early January 2011, the top 20 most commonly used licenses are used in 96% of all projects, as listed in the Black Duck Software Knowledgebase. The GNU General Public License (GPL) family of licenses remains the most widely used license group for F/LOSS projects, with over 60% of all projects using one of the GPL licenses. This skewed distribution of license usage has prompted a community call for standardization on a limited set of known and recognized F/LOSS licenses, both to ensure a clear understanding of mutual obligations in case of mixing of code from different projects and to facilitate the process of managing contributions.
Components from different license groups sometimes can be combined together to create an aggregated object. Most licenses allow for such recombination freely, while some others introduce various constraints that may limit the potential reuse of a project in different conditions. Figure 1 illustrates how popular licenses may be combined. An arrow from one box to another indicates that those two licenses can be combined and that the combined result effectively has the result of the license at the arrow's destination. To determine whether two licenses can be combined, find a common license that can be reached by pathways leading from each license. For example, an Apache 2.0 license and a GPL2+ license can be combined using GPL3 or GPL3+.
Figure 1. Compatibility Relationships Between Popular F/LOSS Licences*
*Adapted from David A. Wheeler (2007)
A license of particular importance that is still not represented within the top 20 licenses listed above is the EUPL, the European Union Public License. This license was originally intended to be used for the distribution of software developed in the framework of the European Union's IDABC programme. This license is designed to be consistent with the copyright law in the 27 Member States of the European Union, while retaining compatibility with popular F/LOSS licenses such as the GPL. Version 1.1 of the EUPL was published by the European Commission in January, 2007 and is available in all official languages of the European Union. All 22 linguistic versions have identical value, which gives the EUPL a distinct advantage compared with the GPL, for which only the official, English edition is considered valid.
Intellectual Property Rights
The debate on software patents is still not entirely settled. On one side, most F/LOSS companies are vigorously fighting the process of patenting software-based innovations; on the other side, large software companies, for example SAP, are defending the practice. An especially important point of F/LOSS licenses relates to “embedded intellectual property rights (IPR).” Embedded IPR is released code that relates to software patents held by the releasing authority. Most open source licenses explicitly mention that software patents held by the releasing authority are implicitly licensed for use with the code. This means that business practices that rely on separate patent licensing may be incompatible with some specific F/LOSS licenses, in particular the Apache License and the GPL family of licenses. The Eclipse Public License gives patent grants to the original work and to enhanced versions based on the original work but not to code that is not directly derived from the release. In contrast, permissive licenses like BSD and MIT give no patent rights at all.
If a license that explicitly gives IPR rights must be selected for purposes of compatibility or derivation, and the company or research organization wants to maintain the rights to use IPR in a manner that is not compatible with the license, a possible solution may be the use of an "intermediate releaser." An intermediate releaser is an entity that has no IPR on its own, to which the releasing organization gives a copy of the source code for further publication. Since the intermediate release has no IPR, the license clauses that require patent grants are not activated, while the code is published with the required license. This approach has been used by Microsoft for some of its contributions to the Apache POI project.
License Selection
The choice of an open source license for a project's code base is not clear-cut and depends on several factors. In general, when reusing code that comes from external projects, license compatibility is the major consideration in selecting a license. Red Hat has provided a compatibility matrix for its Fedora project to enable contributors to clarify compatibility issues they might encounter when mixing and integrating different components into this free Linux distribution (see http://fedoraproject.org/wiki/Licensing).
Licenses have an impact on development activity, depending on the kind of project and who controls the project's evolution. Some studies have shown that restrictive, copyleft licenses have a negative impact on contribution (e.g., Fershtman and Gandal, 2007). However, Stewart and colleagues (2006) found that restrictive licenses are associated with lower development activity in projects with non-market sponsors, such as foundations, than is seen in projects that are coordinated by a company. Generally, this effect is related to the higher percentage of “infrastructure” projects (such as libraries, development tools, and enabling technologies) undertaken by foundations.
Business Models
License selection is also impacted by the expected (or potential) business models underlying an open source project. F/LOSS business models can be analyzed by examining the two possible sources of value:
1.Intellectual property: a right that can be transferred. With F/LOSS, property is usually non-exclusive, with the exception of the open core business model where part of the code is not open at all. (For an overview of open source business models, including open core, see: http://www.slideshare.net/cdaffara/linuxtag-daffara.) Examples of intellectual property are trademarks, patents, and licenses - anything that may be transferred to another entity through a contract or legal transaction.
2.Efficiency: the ability to perform an action with a lower cost (both tangible and intangible). It is inherent in what the company does and how they do it, and it follows the specialization in a particular work area or appears following the creation of a new technology or process. For example, it could be the decrease in time necessary to perform an action associated with an increase in expertise and experience in performing this action. Another example is the introduction of a tool that simplifies a process and introduces a substantial improvement in efficiency.
These two sources of value are the basis of all open source business models, which can be represented along a continuum between property and efficiency (Figure 2). Among the results of our recent research, we found that property-based projects tend to have lower contributions from the outside because this requires a legal transaction for a contribution to become part of the company’s properties. Consider dual licensing: for contributions to become part of the product source code, external contributors need to sign off their rights to the code so that the company can sell the enterprise version alongside the open version. Note that dual licensing also requires at least one of the licenses to be a strong copyleft license, like the GPL.
Figure 2. Open Source Business Models Along the Property-Efficiency Continuum
In contrast, models based purely on efficiency tend to have higher contributions and visibility, but lower monetization rates. It is important to recognize that there is no single ideal business model, but a spectrum of possible models, and companies should evolve according to changing market conditions and adapt their model as required. Some companies start with purely efficiency-based business models and build internal property value with time; others may start with property-based models and move to the other side to reduce engineering effort though increased contributions or to enlarge the user base and create alternative ways of monetizing users.
Recommendations
We have already identified some of the possible constraints in selecting a F/LOSS license for a project; among them, compatibility with an upstream project from which code has been reused, different contribution rates for non-market sponsors, and constraints related to the business model. In general, the recommended approaches follow from the main licensing and business model constraints:
1. When the project is derived from an external F/LOSS project, then the main constraint is the original license. In this case, the basic approach is to find a suitable license from those compatible with the original license, and select a business model that is consistent with the selected exploitation strategy.
2. When one of the partners has an IPR licensing policy that is in conflict with a F/LOSS license, the project can select an MIT or BSD license (if it is compatible with an eventual upstream release) or use an intermediate release; in the latter case there are no constraints on license selection. If an MIT or BSD license is selected, some business models are difficult to apply. For example, open core and dual licensing are difficult to implement because the licenses lack the reciprocity of copyleft.
3. When there are no external licensing constraints, and external contributions are important, a license can be more or less freely selected, but models that reduce contributions (such as open core and dual licenses) should be avoided. When the software produced is related to infrastructure or when the future project releases are expected from a non-market entity (such as a consortia), a copyleft license may be more effective in stimulating developer participation.
Conclusion
Research into F/LOSS commonly focuses on community, participation, or contributions; licensing and business models are often overlooked. However, licensing and IPR are substantial factors in deciding whether or not a software project can be used in a specific environment. These factors also influence the degree of adoption by commercial companies as an embedded element. It is hoped that this summary of important license selection issues in relation to business models may help others decide upon the best approach to suit their circumstances.
Carlo Daffara
Open Source Licensing and Business Models (Onetti, Verma, 2008)
Licensing and Business Models (Onetti, Verma, 2008)
Software licenses
The Open Source Initiative (OSI) currently has a set of 72 licenses as open source "OSI-Approved" and the authors provide a clear picture of the basic open source approaches. They differ between GPL-like and BSD-like licenses and some of the different available variants with different trade-offs between advantages and disadvantages.
GPL-like licenses are the most popular and well-known examples of licenses that require copies and derivatives of the source code to be made available on terms no more restrictive than those of the original license. Any user (licensee) is given the permission to modify the work, as well as to copy and redistribute the work or any derivative version.
BSD-like licenses are permissive free software licenses that allow users to use the code in proprietary software, with or without modifications without obligation to propagate the license to derivative work. Any user (licensee) may create closed versions, re-brand the software and commercialize it. A BSD license can easily create competitors that can launch products based on the same source code.
Business Models
The authors consider three main business models and present examples of companies moving from one business model to another and the complications involved. The business models are:
Reciprocal - based on GPL-like licenses generating revenues from professional services such as maintenance, support, customization, consulting and training.
Academic - typically built around a BSD-like license with revenues generated from both license fees on software reselling and from professional services.
Dual - based on two different licensing models, one at no charge with GPL-like license and one license for which the customer pays a license fee.
As the authors write it is not easy to assign open source companies to the business model categories as they typically adopt hybrid schemes.
Conclusions
The choice of OSS license is typically made by the creator of a project, usually a software developer, without the business or legal skills needed to understand how the choice of license affects the choice of business model. Since the terms of a license determine what companies can do with their software, companies are implicitly narrowing the choice of business models when they select a license type. Business models are often defined around the license and not the other way around.
The authors show with examples an interesting trend in companies changing from one license type to another, trying to adjust the license to the business model at a later stage. Also, if the company does not find a suitable OSI-approved license, it seems to be a trend to create a custom/private license by adding terms to an OSI approved license scheme.
Obviously not all open source companies can change the license as they might have given away the rights needed. Only the ones who own the IPR or the ones who are able to get assignation of rights from all contributors to the software, are entitled to change the license. The authors believe that there are plenty of open source companies for whom modifications of the license to fit another business model is not available, forcing them to adopt suboptimal business models.
The conclusions are very similar to the ones I have experienced within R&D and patenting where the inventor, usually a researcher in a narrow technical field, rarely has the skills to understand how the invention and patent will be used, and how do strategically design the patent application or keep parts of the invention as trade secrets to enable different business models.
Комментариев нет:
Отправить комментарий