On 9/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On 9/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
<snip> > > an alternative would be create our own pom's. the critical meta-data > > (dependencies) is probably not copyrightable. see > > http://www.softwarefreedom.org/resources/2007/originality-requirements.html. > > this probably needs raising on legal-discuss. > > > > - robert > > If we choose this way then we probably should use also a different > groupId/artifactId because of the way maven works. Otherwise if our poms > declare different dependencies or have any other difference maven will > behave differently depending on random events (the artifacts are > permanently installed in the local repository, first win.. once they > have been installed by us they will be taken for "good" also from other > projects that probably will instead work with the "original" pom) we have category A - contains AL2.0 license header: * james * maven-skin * excaliber * avalon category B - derived from AL2.0'd source: * commons beanutils * commons logging * commons digester * log4j category C - minimal, no license: * oro * junit * activation category D - full, probably copyright sun: * mail A are no problem for B, i think that the best policy would be to use to originals (rather than the transformed copeis). the differences are likely to be minimal and IHMO the minimal chance of difference between online and offline builds is worth the risk for C, these contain so little information that we can safely create original works without a risk of difference between online and offline builds. for D, i think that we should approach sun for license clarification. in the meantime, we remove the pom and add a readme asking people to download it. opinions? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
