openinfra/four-opens
Code Issues Proposed changes

Add Open Source chapter

Browse Source
This commit is contained in:
Chris Hoge 2018-11-06 15:58:32 -08:00
parent 563230598f
commit bb24181a8d
1 changed files with 105 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

105
docs/opensource.rst Normal file
View File

@ -0,0 +1,105 @@
===========
Open Source
===========
We do not produce "open core" software. We are committed to creating truly
open source software that is usable and scalable. Truly open source
software is not feature or performance limited and is not crippled. There
will be no "Enterprise Edition".
We use the Apache License, 2.0. It is:
- OSI approved [#OSI]_.
- GPLv3 compatible [#GPLv3]_.
- DFSG compatible [#DFSG]_.
The most fundamental principle, historically reaching back to the "Four
Freedoms" of the Free Software Foundation, is "Open Source". Any software
developed under the Four Opens must be released under an open source license.
It means being able to study a program, modify it, and redistribute either the
original or the modified version so that others may benefit from your work.
That is a minimum standard for what we mean by "Open Source" in the Four Opens.
Beyond that, we want the software to be truly usable and scalable. This adds
the additional condition that it should not be limited in features or crippled
in performance to artificially enable any business model.
In particular, the "Open Source" principle is strongly opposed the "open core"
model, where source code and features in a proprietary "Enterprise Edition" are
deliberately withheld from the open source software. This model invariably
fails both vendors who promote it and users of the software. On the vendors
side, the ethos of committed open source developers will lead to the withheld
features and shortcomings being addressed as part of the open source version of
the product. In the best case the enhancements are made to the original
version. In the worst case, the software is forked, fragmenting the community.
Either way, the commercial upshot for "open core" is limited and risky. On the
users side, they are unnecessarily given a limited experience, with the
choices of giving up the freedoms that open source software provides by
purchasing the "enterprise" edition, wasting time and resources re-implementing
features or capabilities that already exist, or turning to other projects to
fill their needs.
This model always fails once a community member tries to add a feature that the
open core company product management would prefer to keep in the proprietary
version. That ultimately results in reduced adoption, prevents a community of
equals to be formed, and increases the risk of a fork or emergence of a truly
open competition. It is an especially bad choice for infrastructure software,
where enterprise features (like security or scalability) are desirable for
every user.
The "Open Source" Principle in Practice
---------------------------------------
"Open Source" begins with the choice of license a community applies to its
project. In the case of the OpenStack Foundation, we use v2.0 of the Apache
License [#apachev2]_. The license meets the requirements of being able to modify and
redistribute a work. It includes a number of provisions that also protect
end-users by granting copyright and patent licenses to all end users, while
limiting liability to the original copyright holder. This patent protection is
one of the distinguishing features in comparison to other open source licenses,
like the MIT License.
In practice, individual and corporate contributors need to understand the
consequences of contributing code to an Apache Licensed project, particularly
the granting of copyright and patent licenses to all users of the software. To
acknowledge this, many projects require that all contributors sign a
"Contributor License Agreements" (CLA) [#OSCLA]_ or "Developer Certification of
Origin" (DCO). Typically, a CLA is a stronger statement, attesting that a
contributor has a right to submit work to the project and that they are
granting copyright and patent licenses in accordance with the Apache License
along with their submissions. A DCO, on the other hand, is a bit lighter weight
and is more of a statement (rather than a license) that the developer is indeed
authorized to submit changes to the project and understands that their
contributions will be used in accordance with the license. A CLA, being a
stronger document, is also considered a barrier to entry. A DCO, in contrast,
lowers the barrier to entry by removing the requirement to consent to a legal
document [#CLAvDCO]_.
Apache 2.0 is very liberal in allowing companies to modify and use the code in
any way they want, and doesn't place requirements to release changes (although
it doesn't prohibit them from doing do). This, along with the patent
protections of the license, is one of the reasons why it is so popular. It has
also been used in practice since 2004, and is fairly well understood amongst
the corporate and open source legal communities.
This liberal view on modification does have some downsides, though. It becomes
very easy for companies to withhold enhancements that would be beneficial to
the wider community, or to make changes to their version of the software that
breaks interoperability. While the license doesn't address these directly,
there are guard-rails that a project can put in place to mitigate these risks.
Trademark programs based on interoperability or conformance testing are one
such tool. The OpenStack Foundation uses such a program. In order to qualify
for the trademark, a product can not modify API code (thus adding a stronger
modification restriction than provided by the Apache License), and it must
successfully demonstrate compatibility by passing a suite of interoperability
tests, run against the public API of the product. In this way, the scope of
modifications is limited.
References
----------
.. [#OSI] https://opensource.org/licenses/alphabetical
.. [#GPLv3] https://www.gnu.org/licenses/license-list.html#apache2
.. [#DFSG] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines
.. [#apachev2] https://www.apache.org/licenses/LICENSE-2.0
.. [#OSCLA] https://wiki.openstack.org/wiki/OpenStackAndItsCLA
.. [#CLAvDCO] https://opensource.com/article/18/3/cla-vs-dco-whats-difference