There has been some discussion about camel-extras license policy on IRC and in CAMEX-69[1]
Summarizing it, there are three policies that are relevant, two are documented, one is more ambiguous: - Google Code allows projects to have any OSI approved license[2], anything without such a license is not allowed. This would be avoided by moving to Github or elsewhere. In any case, the policy doesn't make any restrictions on the use of non-free dependencies as long as they are not committed in the repository. - The Apache Extras policy[3] says that "Although Apache Extras does not impose a specific open source license, we encourage the usage of Apache License 2.0.". That is even less proscriptive than the Google Code policy and it doesn't prohibit projects from depending upon non-free code. - The Camel-extras project page[4] mentions it is for projects "which due to GPL/LGPL licensing cannot be hosted at Apache". It doesn't say whether it is ONLY for GPL code though. People have expressed opinions about this, suggesting it should follow the ASF approach, but I couldn't find these documented explicitly. So there are a few observations: - if Camel-extras is going to be more strict than the Apache Extras policy, then it should probably have a policy statement somewhere - if it is just going to use the Google Code and Apache Extras policy, then I feel that CAMEX-69 can be accepted in the repository but the dependency JAR can't be distributed by anybody who makes a ZIP or tarball of the dependencies - if Camel-extras moves to Github or another hosting provider with less restrictions, then it would legally be possible to have non-OSI licensed code in there - however, with any of these non-free artifacts, whether they are dependencies or contributions in the repository, there would be practical issues. For example, not every developer would be able to test or even compile every component with every dependency and people would have to be careful to avoid accidentally distributing dependency JARs that have a no-distribution clause. These practical problems could be resolved by creating Maven profiles for separating the stuff that is OSI-approved and the stuff that isn't or it could be solved by creating some extra repository, called camel-nonfree perhaps, on Github. Do people feel that this summary is accurate? Does anybody want to propose a policy statement for the Camel Extras web site? I personally don't mind which direction is preferred, I just want to have some clear rules about where to contribute things. 1. https://camel-extra.atlassian.net/browse/CAMEX-69 2. http://googlecode.blogspot.ch/2010/09/license-evolution-and-hosting-projects.html 3. http://community.apache.org/apache-extras/guidelines.html 4. https://code.google.com/a/apache-extras.org/p/camel-extra/
