Open Source Solutions

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.

Open development occurs when all decisions are publicly documented, all resources are open source and all bona fides participants have equal rights.

Development in the open is inclusive and empowering. Experience shows that the collective memory of a community – both short-term and long-term – must be available to all if development is to be accessible to all who wish to participate. It’s thus essential to apply consensus rules such as those used by the Apache Software Foundation, where all code commits are documented, small enough to be reviewable, logged to a mailing list and subject to challenge.

Apache asserts that “if it didn’t happen on the mailing list, it didn’t happen,” a rule to ensure that all in-person interactions are fully documented for all participants. Even when a project comprises a few co-located people, it is vital to follow this rule otherwise new participants will have lesser rights in practice whatever their rights in principle.

Open collaborative tools, open licensing, self-governance, non-discriminatory respect, release-train schedules and shared assets are the keys to open development.

Open development is now a well-understood practice among open source communities. We expect TravelSpirit to operate using the following default practices:

Open collaborative tools: We will use open source tools to support community interaction and software development, rather than proprietary tools. We will also seek to ensure that it is possible to migrate between hosting arrangements and also to migrate to alternative solutions.

  • Open licensing: All code we work with will be licensed under an OSI-approved copyright license compatible with the Mozilla Public License version 2. All non-code assets will be licensed under the equivalent Creative Commons license, CC-BY-SA-4.0-Intl.
  • Self-governance: Decisions will be made by current, actual contributors, possibly with reference to a larger body of former contributors where decisions are not readily reversible by future participants.
  • Non-discriminatory respect: We will require all participants to abide by policies requiring respectful interaction that is not affected by externalities of the individuals or companies involved.
  • Release-train scheduling: We will release software according to a pre-determined schedule (a “release train”) to ensure that all participants have their improvements included in a timely manner, that security fixes are circulated promptly and that no party is able to prevent releases based on their own preferences alone.
  • Shared assets: We will cause all common assets – funds, trademarks, collective copyrights, employees, events – to be in the stewardship of an independent entity beyond the control of any one participant.
  • Open Trust: Collaborative projects will have shared assets that need managing. An independent legal entity is the best vehicle for this, and we believe a fiduciary and administrative umbrella is a wise first home.

Collaborative projects will have shared assets that need managing

Once a collaborative project is in progress, the collaboration will naturally start to require the management of shared assets on behalf of the community of collaborators. This will include technical assets such as a source code repository, mailing list service, wiki, translation memories, build services, test systems and so on. While these can in many cases be hosted on shared services such as GitHub, it’s important to ensure that no member of the community has exclusive control. Even the most trusted individual can leave a project, and a lack of clarity about who legally “owns” those servers can lead to painful disputes.

Even more important is the stewardship of legally-recognised assets such as domain name registrations, trademarks, shared cash from donations and other sources, hardware bought for general use and so on. It’s very important these assets are legally controlled by the project rather than by a subset of individuals.

In time a project may have more significant assets, including public events, staff and even premises. By the time these are acquired, a community must definitely be anchored in a legally-recognised entity.

An independent legal entity is the best vehicle

Most projects aspire to creating a legal entity of their own, such as a limited liability company or a non-profit company. While it’s easy to start such things, getting it right and ensuring the control of the entity is in the right hands from the beginning – before there’s a crisis – takes experience.

Many people assume the best way to triage these issues is to start a new charitable entity – often colloquially called a “Foundation” irrespective of the actual structure – as these are government regulated and must incorporate both equitable treatment rules and not-for-profit objectives. But experience shows that starting a charity doesn’t actually guarantee as much as people expect. It’s still important to have the benefit of experience, so starting a new “open source foundation” – the expectation of many collaborating groups – may not be the best first step.

A fiduciary and administrative umbrella is a wise first home

Experience also shows that projects may be better protected seeking the shelter and assistance of an existing “umbrella” charity designed for open source projects. A number of these exist – Software in the Public Interest and Software Freedom Conservancy, both in the USA, are well known. The Apache Software Foundation has evolved into a form of project umbrella, providing its “incubator” process as an on-ramp for new projects, and the Linux Foundation is evolving an equivalent process. Outercurve Foundation can also offer assistance, viewing themselves as a liability firewall for contributors and sharing their excellence at packaging open source IP. Also referred to as fiscal sponsors, this approach is addressing a real need for, as open source becomes more popular and mature, formalizing the governance and corporate structures of open source projects.

In Europe, such arrangements are much less common, but a new open source umbrella Community Interest Company (CIC) called Public Software is being formed for European projects, and that’s an entity that holds good promise to host TravelSpirit open source software projects in the future.

Visit TravelSpirit Foundation to find out more on how we’ve evolved our wider governance and objectives around the Internet of Mobility.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s