wiki:ApertureLicense

Version 35 (modified by sauermann, 19 years ago) (diff)

--

License

The Aperture project is published with the following licensing policy.

The core parts (APIs and closely associated classes) are free to use and to extend. They should be as open as possible so that anyone can include Aperture in a project, commercial, closed source or not. Especially, people should not be required (or even think they are required) to disclose their own implementations for accessing proprietary document formats, data sources, etc.

Besides a framework, Aperture contains a number of concrete adapter and extractor implementations. A lot of time and effort has been put in their creation and maintenance and they are therefore licensed under a reciprocal license, meaning that changes to this code, such as functional extentions, bugfixes, performance improvements, that are redistributed in one way or another way, have to be made available to the community under the same open source license.

Aduna's Wishes

We at Aduna have internally formulated a number of requirements we believe the Aperture license should have. These are listed below. We are still open to discussion on these requirements though.

Herko> These requirements are important to us because we are a small, commercial entity. As such, we want to avoid surprises as much as possible, especially legal ones that could potentially cost us a lot of money. Also, we want to make clear just what our contribution is and also what it doesn't contain (trademarks, etc.). Finally, we DON'T want our commercial *competitors* to be able to just take our contribution and sell it as their own, but at the same time we DO want to allow commercial parties in general to create proprietary extensions to our software.

Judicially clear license - the license should provide a clear view and contain a judicially sound formulation of what rights a user is being given. Read e.g. ​this document for a discussion on the sloppiness of the (L)GPL in this matter and what this could lead to in court case.

Politically neutral - so no moral preamble like the (L)GPL, which serves no practical use.

Reciprocal license - improvements to our work (politically correct: work performed by the community) should be given back to that community.

Limited reciprocity - on the other hand, if you create your own components to be used inside the framework, e.g. an Extractor for a proprietary document format, you should not be required to make this available to the community. Rationale: this code may necessarily contain trade secrets and you don't want to discourage such applications. Also, we're confident that people who build more generally applicable components will have a strong motivation for contributing those to the project, as this will provide them with free expert advice and, when the code is accepted, free maintenance.

Built-in patent license - when you contribute code to the project, you automatically give people a royalty-free parent license for using that code, in case the code would otherwise infringe one of your patents. This prevents contributors from contributing code and coming back later to collect royalties. This patent license should be formulated in a fair way, e.g. it should cover both Aperture and derivative works.

Built-in patent defense - when you sue someone (either a developer or a user) for a patent infringement related to this code, all your rights (patent- and copyright-related) for this codebase should be withdrawn. This defense should be formulated in a fair way, e.g. it should not involve infringements unrelated to this project, as some licenses (MPL, CPL) do.

External deployment - making a derivate work available as a service on a network to others outside your organisation should be considered as a form of distribution. The license should demand that under these circumstances the derivative should also be made available under the chosen open source license.

Local jurisdiction - we prefer a local court (i.e. Dutch or German, depending on who is involved) rather than one in California (MPL) or New York (CPL).

So far, all these demands are (not coincidentally) met by the ​OSL. Still, we fear that people may think that, due to how the OSL is formulated, they are required to distribute their own implementations of core APIs such as DataSource and Extractor under the OSL. We believe this is not the case with the OSL, i.e. that this type of extension does not qualify as a derivative work under copyright law. However, in order to prevent any confusion and discussion in the first place, we propose to publish all core APIs and possibly some classes that cannot be separated from them under the ​ASL and all concrete implementations under the OSL.

To Discuss

still open: AFL or BSD for core: If BSD is similiar to AFL, Leo would recommend BSD as it is more commonly used.

Herko> I am not worried that using a less familiar license would reduce acceptance of the project in the community. I'm convinced that the majority of developers will accept *any* Open Source license. To use the BSD license just because it's more common would be a mistake, I think.

The core project interfaces and architecture are published using the AFL ​http://www.opensource.org/licenses/afl-2.1.php OR BSD: ​http://www.opensource.org/licenses/bsd-license.php

The implementations of adapters are licensed under the OSL (Open Software License). ​http://www.opensource.org/licenses/osl-2.1.php

Feedback Aduna: the AFL is identical to the OSL except for the reciprocal demand. In my opinion this makes it clearer why we chose two different licenses to work in parallel: for some part you want the reciprocity, for others you do not. Furthermore, the AFL is in many other places compatible with the requirements outlined above, such as judicially soundness, jurisdiction, patent license and defense, etc., which are at best implicit in the BSD license.

Some of the arguments against ASL are ​listed on the FSF site.

Herko> I see only one (GPL-specific) argument of the FSF against AFL ("it's not GPL compatible"). This might not even be true anymore. Apparently that argument was written for version 1.2 of the AFL license. The creator of AFL claims the latest version of the AFL is in fact compatible with the GPL.

We would be one of the front runners, adopting these relatively new OSS licenses - OSL and AFL. maybe some people may find that discouraging. We don't need annoying "I am richard stallmann and am politically correct and won't use your bad code" discussions, It really can be frustrating. Using BSD would be ok for the core to avoid that - and when the AFL and OFL are common practice, we can re-lizence.

Herko> Note that while AFL and OSL are not yet as big as some other licenses, we are not alone in choosing it. The Open Source Intitiative itself licenses all its content under both licenses and the licenses are used for over 100 projects on Freshmeat, including Fedora, ImageMagick and RubyOnRails.

LEO> Fedora is GPL. ​http://fedora.redhat.com/licenses/eula.html

If you have the copyright, you can always relicense your own files. if all copyright owners (i.e. DFKI and Aduna, for the time being) do that jointly, you basically have relicensed the entire project.

Herko> Relicensing after the fact could be troublesome, especially if more contributors start to take part. Also, it will confuse users. I would prefer we deal with this issue now and avoid relicensing as much as possible.

Background Info