The legal rules often play a key role when it comes to business models in software businesses and notably in free and open source software projects. This is particularly true when the project owner wants to maintain some level of control over the software and the project itself. The balance between control and freedom is achieved by legal tools and policies, such as licenses, compliance policies, contracts, trademarks, organization rules, contribution policies, only to name a few.
All choices on how to use the available legal tools depend ultimately on the business model and the goals of the project owner or host. How does the project host intend to make money or savings with the project? Or are there other goals? However, legal tools are not there to just take control on all aspects of the project, but they are there to achieve the right balance. Legal tools can be used to control or, in the other end, to free and to enforce freedom.
Trade-off between Control and Participation
When choosing an open model for a project, one typical goal is to get attention and participation from a broader audience, i.e. the project’s future community. When choosing what to control and what to free, it is important to understand that with each layer or element of control, you sacrifice an element of participation. A totally free open source project with decent governance is likely to attain a lot more interest than a company controlled project that is only partly open.
Community participation may lead to lower development and support costs while increasing the amount of payable customers. This can happen among other things via an increased amount of users, customers and feedback, participation in bug-finding and fixing, development contributions, community support, and more business partners. The community can become a competitive advantage, if maintained correctly.
At the same time, many projects benefit from the advantage of having one or more commercial actors investing in the project and gaining profit in relation to the project. So the success of a project may also be dependent on whether or not it creates business opportunities for others while growing the business of the project host.
So the trick is to find the right balance between freeing elements to support participation and controlling to maintain interest for long-term investments.
Example of Control vs. Participation
Business Description: A device, say a mobile phone, is sold to masses of consumers. The money is made with device sales. Software should be of great quality, versatile, effectively developed and allow for differentiation (additional, eventually closed elements). Customers choose the device based on brand, ease of use, available services and eventual add-ons. Analysis: Money comes from device sales, not software. The customer’s choice is largely based on other elements than software. Therefore the software could be licensed freely, but perhaps with a license encouraging participation to the project, such as a copyleft license. The license should allow for proprietary elements, as LGPL and GPL do, in correct software architecture. Enforcement of copyrights is probably not a game-breaker question: you can accept diverse contributions. Trademarks could play an important role in establishing some control on compatibility questions. In order to encourage business participation, the project could be set-up in a separate organization, such as an existing or new association or foundation.
Choosing the Structure
The straight forward option is to host the open source project in your company. The benefits are simplicity and lower costs. The down-side is that full control by your company of the host (them being the same) may lead to less interest by third parties to participate. You will probably end up as the only party making initial investments into setting up and pushing the project. However, many businesses decide to live with this option. The other option is to reach towards other players and partners and to establish an association or foundation for the project or find an existing organization to host your project.
Setting up a Project and Cleaning up the Materials
Setting up an open source project means also other things than dumping a source code snapshot to a web-page. Depending on the project, it means for example setting up a public development tool such as git or svn, setting up public distribution of source and binary packages, public mailing lists, bug reporting and tracking software, opening road-maps, architecture descriptions, documentation, support forums, etc. If you have an existing closed source project, you will probably have much of this material already. There is probably some cleaning work to be done with regard to the content, e.g. source code comments like “I stole this code from…” are not suited for a professionally maintained public code base.
Choosing and Implementing the License
The license plays an important role in establishing the basic set of rules for the project. Licenses have many subtleties, but most often you will end up looking at the copyleft (i.e. reciprocity) obligations, license compatibility questions and perhaps patent clauses, professionalism of the license and eventual jurisdiction and liability limitation clauses.
Copyleft means an open source license obligation that requires a party, who distributes a modified version of the software, to distribute the modifications with the same license terms as the original software.
When choosing the type of copyleft suitable for you, a strong copyleft license will mean more control over the project. At the same time, the license might not be suited to all business models by those who may not deviate from the license. As long as you are the sole copyright holder, you retain the right to make exceptions to the license.
Once you have chosen the license type, you should implement it in a way that everybody understands clearly the contents. In addition to stating on the project pages the license that you apply, I suggest that you add the license text to the root of your software packages, place it similarly in code repositories and add it with clear attachment text. Consider placing this a license attachment in each file with automated mechanism. The license reference text should state the software name and version, copyright notice, reference to the applied license and eventually a disclaimer.
You will probably use third party developed open source software as a part of your project. That will mean that you need to comply with the license conditions applicable to that software. Since it’s your public project, I suggest taking compliance seriously and using review tools, such as Fossology to help review the third party code or to use dedicated services, such as the collaborative service by Validos.
Deciding on Contribution Policies
In anticipation and support of eventual contributions, you will need to decide and communicate how you accept contributions. The more controlling option is to require copyright assignments for all contributions. The other option is to accept licensed contributions. The first option will mean that you need to agree with each contributor on transfer of copyrights, which will mean a hinder for making contributions. The latter option will lead to distribution of copyrights among all contributors and will mean that making contributions is easy but you have fewer options in business models and in enforcing the copyright.
In copyright contribution agreements, you could just agree on the transfer of rights or you could require different types of warranties of ownership and non-infringement. Licensed contributions might be conditioned by the type of licenses you accept. They may also be added with warranties of ownership and non-infringement. Depending on your project, it might be a good idea to ask from individuals only the warranty that they actually wrote the code they are offering and that they are making a good faith contribution with no actual knowledge of copyright, patent or similar infringement as a result of accepting the contribution to the project.
Choosing a Name and Registering Trademarks
Any project will need to use a name. Many business models depend on the trademark and the value built into the mark. Trademark registrations in key jurisdictions are recommended. There is normally not much downside in establishing a strong trademark policy and control around the use of the name in connection with your project. Sometimes trademarks are being used (or tried) to limit the distribution of an open source project’s code, but these efforts don’t normally work due to the nature of trademarks. Trademarks are a useful way to control, for instance, compatibility questions; i.e. you may have a policy that only versions approved by the project host may be named with your trademark.
Other Control Mechanisms: Patents and Agreements
Holding a patent covering your software allows for another layer of control. Granting patent licenses to select persons or to the whole downstream (at the extreme, donating the patent to an established free software organization) are mechanisms for loosening control. Eventual contributor patents will need to be controlled with contribution agreements or license terms. Third party patents present a similar question with other fields of software.
Agreements can be introduced to control a wide variety of matters. However, for an agreement structure to be efficient, the project must be severely limited in openness: Full access to code or some other elements can only be granted to those who have entered into the agreement.
Well Begun is Half Done
When you start a project, it is probably a good idea to prepare it in advance so that its first steps are successful and also perceived as successful and positive by the target audience. This will help gain momentum and build a productive community for the project. Good external visibility is also a critical success factor that can be prepared and carefully planned.
You should prepare a road map which will be backed by you and your partners in the short to medium term, while you strive to build or maintain the project as self-sustainable.
Some facts and figures about Open Source in large organizations
• Hewlett-Packard reported already in 2003 to have received 2.5 billion USD in Linux- related revenues.
• Red Hat’s revenues for the financial year 2010 were approximately 800 Million USD and for financial year 2012, approximately 1.1 Billion USD.
• According to Forrester in 2009, 23 % of European and American corporations announced that they do not use open source. [1]
• Accenture (August, 2010): 38 % of interviewed organizations with over 500 million USD annual revenues expected to migrate mission critical software to open source. [2]
• Nearly 76 % of enterprise users had deployed Linux for new applications, services and greenfield deployments, according to the Linux Foundation 2013 Enterprise End User Report, in the two years preceding the report. Nearly 40 % of these respondents reported that they were migrating to Linux servers from Windows, compared with 31 % in 2010, representing a growing trend. Moreover, during 2013, 73 % of the enterprises had increased their use of Linux for mission critical workloads.[3]
• In the Future of Open Source Survey 2013, 57 % of the respondents agreed that their companies will collaborate with competitors in industry-specific OSS communities over the next three years. The most important factor for OSS adoption was deemed to be quality, followed by freedom from vendor lock-in. The respondents believed that over the next 2–3 years, open source adoption will affect government the most (35 %), with health and science in the second spot (15 %), media in the third place at 13 %, financial services at 9 %, and automotive at 8 %.[4]
• Gartner forecasts that in 2014, 45 % of the projected total of 2.5 billion units of PCs, tablets, ultramobiles and mobile phones will ship with the Android operating system. [5]
1. Forrester Dr. Dobb’s 2009 Developer Technographics Survey, Q3 2009, Base: 1298 development pros at North American and European enterprises and SMBs, presentation at LinuxCon 2010 by Jeffrey Hammond,principal analyst at Forrester Research
2. http://newsroom.accenture.com/article_display.cfm?article_id=5045, a survey of 300 large organizations both in the private and public sectors, all with annual revenue in excess of 500 millions / year.
3. Linux Foundation 2013 Enterprise End User Report by the Linux Foundation and Yeoman Technology Group (https://www.linuxfoundation.org/publications/linux-foundation/linux-adoption-trends-end-user-report-2013). The survey was based on responses from 355 IT professionals from Linux Foundation End User Council, as well as other companies, organizations and government agencies with $500 million or more per year in revenues and/or 500+ employees, selected by The Linux Foundation and Yeoman. The majority (56 %) of the respondents identified themselves as IT/IS staff or developers and represented a wide range of industries. Users from the US and Canada made up 41 % of the respondents, 25 % were from Europe, and 16 % from Asia.
4. http://www.blackducksoftware.com/news/releases/seventh-annual-future-open-source-survey-results-show-culture-quality-and-growth, a survey by North Bridge Venture Partners and Black Duck Software with over 800 respondents from various non-vendor (58 %) and vendor (42 %) organizations and communities.
5. http://www.gartner.com/newsroom/id/2645115
This article has been first published on symbio.com, but is now republished, at hhpartners.fi due to availability. The opportunity has been used to update some parts of the article.
Martin von Willebrand is a partner at HH Partners and the chairman of Validos and a board member at COSS. Validos is a Finnish registered association established to enhance the use and implementation of open source by way of helping in complying with license obligations contained in software. COSS is the Finnish Center for Open Solutions and Systems. As a part of HH Partners technology law practice, Martin von Willebrand advises private, public and non-profit organizations in strategic and daily needs in using and publishing open source.
Copyright© 2010-2011, 2014 Martin von Willebrand. This article is licensed under the Creative Commons Attribution-No Derivative Works 3.0 Unported license.
