Changes between Version 32 and Version 33 of ApertureLicense


Ignore:
Timestamp:
10/17/05 14:23:29 (19 years ago)
Author:
Herko_ter_Horst
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ApertureLicense

    v32 v33  
    1010 
    1111We 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. 
     12 
     13Herko> 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. 
    1214 
    1315'''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 sloppiness of the (L)GPL in this matter and what this could lead to in court case. 
    … …  
    3335'''still open: AFL or BSD for core: If BSD is similiar to AFL, Leo would recommend BSD as it is more commonly used.''' 
    3436 
     37Herko> 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. 
     38 
    3539The core project interfaces and architecture are published using the AFL  
    3640http://www.opensource.org/licenses/afl-2.1.php 
    … …  
    4448 
    4549Some of the arguments against ASL are [http://www.fsf.org/licensing/licenses/index_html listed on the FSF site]. 
     50 
     51Herko> 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. 
     52 
    4653We 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. 
     54 
     55Herko> 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. 
     56 
    4757If 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. 
    4858 
     59Herko> 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. 
    4960 
    5061