Open source is enabled by granting permission in advance through a standardised copyright license.
The term “open source” was coined at the end of the 1990s to embody the application of the older concept of “free software” (software with its user freedoms intact) when applied to communities of developers that potentially included commercial users.
The Open Source Initiative (OSI) was formed in 1998 to advance the term, and since then has acted as a standards body for copyright licenses. Using an open process, OSI evaluates whether copyright licenses comply with the Open Source Definition, a ten-clause statement allowing objective evaluation of the effectiveness of a copyright license to deliver the freedoms to use, improve and share code.
In the last 18 years, OSI has approved many copyright licenses as open source, providing a richly varied scope for open source development. All these licenses allow use of the code without any preconditions whatever, and grant permission in advance to improve the code and to share the original or improved code with anyone.
Some licenses place preconditions on the sharing of the code, most frequently by requiring that anyone doing so reciprocate on the liberty they enjoy by making the same liberty available to recipients of the code. In a play on the word “copyright”, licenses requiring reciprocal license terms are called “copyleft”.
The scope of the required reciprocity varies. Some licenses require projects incorporating their code to share the full source that corresponds with the program being given to users. These project-reciprocal licenses are sometimes termed “strong copyleft” with the best-known being the GNU General Public License (GPL). Other licenses limit the scope of the required reciprocity, for example by only requiring the reciprocal sharing of the source of modified files (the Mozilla Public License, MPL, does this) or only requiring reciprocal licensing if the source code is shared (the Eclipse License does this).
Scope-limited reciprocity makes it easier for existing companies to execute their business models outside the project, so we believe use of a scope-limited open source license will lead to more rapid growth of TravelSpirit and the markets associated with it.
Since existing code that is likely to be used by TravelSpirit is licensed under both the non-reciprocal Apache License and under the project-reciprocal GPL, we need to select a license explicitly compatible with both. We will therefore use the Mozilla Public License version 2 for all new code in TravelSpirit that is not already subject to another license.
An open source model leverages copyright to create innovation, collaboration and market growth
All code is automatically protected by copyright the instant it is created, and without a license from the copyright owner almost all legal reproduction of the code would be impossible. In proprietary contexts, copyright licenses are granted in exchange for payment, as a convenient control point allowing a vendor to recover the costs of development and profit from code.
But this is not the only way to leverage copyright. Open source projects license the copyright under an OSI-approved license in a way that creates permission in advance for improvement and use, and as a result encourage commercial use of the code outside the scope of the project. Companies working with open source code have commercial models that do not rely on the artificial scarcity of the code that results from a proprietary license. Instead, they use the code to enable generation of revenue by other means.
A well-constructed open source project consequently allows many enterprises to benefit from code, rather than just one. New entrants to the market will still need new business models and new investment, but do not need to re-implement basic and well-understood code which is non-differentiating.
Since it is non-differentiating, it’s unlikely such improvements will lead to significant business advantage but rather to the maintenance burden of maintaining an independent “fork” of the code. As a result, businesses sharing open source code are incented to contribute their improvements to the code back to the community, with the consequence that the shared code is constantly being improved by every business adopting it.
This continuous improvement leads to shared innovation, to collaboration and to the growth of the market generated by the code. These benefits are likely to greatly exceed the benefits that would have accrued to a single entity seeking to directly monetise the copyright.
Existing projects should be used and improved where possible, reserving new development to gaps
The Open Source movement, together with the Free Software movement before it, have caused millions of lines of code to be liberated under open source licenses. As a consequence, the basics of any software system are highly likely to already be available in a collaborative project somewhere. It is better to default to using existing projects, improving them where necessary and contributing the improvements upstream.
For TravelSpirit, just a cursory investigation has disclosed a number of possible upstream projects that can be combined into new MaaS solutions. Some samples:
FreeGIS, a local government GIS
- Open Trip Planner, a widely-used trip planner based on and released as open source software
- DigiTransit, a travel planner app based on Open Trip Planner
- KillBill, a subscription billing framework
Open source and open data are necessary but not sufficient.
A collaborative development will need source code licensed so as to give every participant permission in advance to use the code to satisfy their extrinsic motivations. The code will almost certainly consume external data that will need to be licensed in such a way as to permit such consumption, and will need to expose APIs and emit data licensed in ways to allow downstream consumption.
These are “hygiene factors”, necessary for open collaboration but sufficient neither to cause nor to guarantee it. We will need to go beyond open source licensing to also stimulate and protect open development and representative governance.
Read more on how.