| 5 | | The Aperture project is published with the following licensing policy. The core parts are free to use and to extend. They should be as open as possible so that anyone can include the core Aperture in a project, commercial, closed source or not. The concrete adapter and extractor implementations, which include much work and bugfixing, are licensed under a '''reciprocal''' license, meaning that changes to the code have to be published again and external developers contribute bugfixes, improvements and extensions to the core adapters implementations. |
| | 5 | 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 to disclose their proprietary document formats, data sources, etc. |
| | 6 | |
| | 7 | Besides a framework, Aperture contains a number of concrete adapter and extractor implementations. These include much work and bugfixing and 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. |
| | 8 | |
| | 9 | == Aduna Perspective == |
| | 10 | |
| | 11 | We at Aduna have internally formulated a number of requirements we believe an Open Source license should have. We are still open for discussion on these requirements though. These are our requirements: |
| | 12 | |
| | 13 | '''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. [http://www.rosenlaw.com/Rosen_Ch06.pdf this document] for a discussion on the lack of clarity in the (L)GPL and what this could mean for a court case. |
| | 14 | |
| | 15 | '''Politically neutral''' - so no moral preamble like the (L)GPL, which serves us of no practical use. |
| | 16 | |
| | 17 | '''Reciprocal license''' - Improvements to our work (politically correct: work performed by the community) should be given back to that community. |
| | 18 | |
| | 19 | '''Limited reciprocity''' - on the other hand, if you create your own components that are to be placed 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 scare away such users. Also, people seem to have a natural tendency for more generically applicable component to make them available to the project team, if only because they get free expert feedback and, once incorporated into the project, free code maintainance. |
| | 20 | |
| | 21 | '''Build-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. should cover both Aperture and derivative works. |
| | 22 | |
| | 23 | == To Discuss == |
