I hoped to stay out of this. :) Points: * "provided" scope is another Maven mechanism that compiles against a given dependency but does not pull the dependency in as a runtime dependency. I personally prefer it to marking a dependency optional. * For annotations with only classfile retention, a future package rename e.g. lang4 would not require a consumer to upgrade just for the renamed annotation, though nothing would stop them from doing so. A given project could depend on either or both of lang3 and lang4 in any combination of compile-only or runtime-inclusive scope with no problems. * A standalone annotations component might be interesting, but I'm not sure if the proposed annotations constitute a critical mass adequate to justify it.
Matt On Mon, Nov 28, 2016 at 1:21 PM, Pascal Schumacher <pascalschumac...@gmx.net> wrote: > Groovy had to change the license of its documentation from CC-A 3.0 to the > Apache License during incubation: > > https://issues.apache.org/jira/browse/LEGAL-167 > http://markmail.org/message/2e7tehlwtpx625q4 > https://issues.apache.org/jira/browse/GROOVY-7470 > > So I guess Commons is probably not allowed to use these files. > > > Am 28.11.2016 um 18:58 schrieb Gary Gregory: >> >> On Mon, Nov 28, 2016 at 7:15 AM, Jochen Wiedmann >> <jochen.wiedm...@gmail.com> >> wrote: >> >>> On Mon, Nov 28, 2016 at 4:06 PM, sebb <seb...@gmail.com> wrote: >>> >>>> The code would not run without the JCIP jar. >>> >>> Are there licensing issues regarding that jar? >>> >> Hm, according to https://www.apache.org/legal/resolved.html, the license >> "Creative Commons Attribution (CC-A) 2.5" is discussed in the section "HOW >> SHOULD "WEAK COPYLEFT" LICENSES BE HANDLED?" >> >> It looks like we might have an issue but this is not clear to me as IANAL. >> I you look at the license summary >> https://creativecommons.org/licenses/by/2.5/ it sure seems OK, but our >> resolved.html has this license on a list of licenses to watch out for. >> >> So to be on the safe side, how do we best re-implement these? The >> annotation names we can keep as is but I would imagine that we'd want to >> re-write the Javadoc from scratch. >> >> Thoughts? >> >> Gary >> >> >>> Jochen >>> >>> >>> -- >>> The next time you hear: "Don't reinvent the wheel!" >>> >>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/ >>> evolution-of-the-wheel-300x85.jpg >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
