james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [JSieve] pom's in stage
Date Mon, 01 Oct 2007 17:52:12 GMT
On 9/30/07, Stefano Bagnara <apache@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 9/30/07, Stefano Bagnara <apache@bago.org> wrote:
> >> The case I was referring to is different because that poms have not been
> >> submitted to JIRA but have been created by someone else that never
> >> donated/submitted them for JAMES inclusion. (like any JAR we placed in a
> >> lib folder).
> >
> > the division of apache into projects is only for convenience. anything
> > contributed to an apache project is contributed to apache.
> >
> > these poms were originally uploaded onto apache servers by a
> > committer. when copying documents already contributed to apache, this
> > should be noted.
> I think that artifact submission procedure does not require the
> submitter to be a committer.
> As described here
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> someone (any JIRA user) simply open a new JIRA issue and is not required
> to have the copyrights for such jars/poms to JIRA.

copyright is not neccessary: just a suitable license

> The procedure does not even tell the uploader what are the allowed
> licenses for the uploaded artifacts.
> Am I allowed to ask uploads of a GPL jar? what about a non open source jar?
> Does this means that the "responsibility" to check this is left to the
> person that will concretely place that jars/poms in the right folder?
> Are they the "repository" guys and no one else?

i think so but this is a question for maven or repo

> >> This is probably the "key" of this issue. What is the license for pom
> >> files redistributed by ibiblio and other maven repositories?
> >
> > +1
> I saw you asked this in repository.
> But I'm a bit confused about what repository we are talking about: there
> is a maven repository managed by ASF including only releases for ASF
> projects: http://people.apache.org/repo/m2-ibiblio-rsync-repository/
> but this is only a subset of what we can see in the maven central
> (http://repo1.maven.org/maven2).
> I think that it is safe to think that poms released by ASF in the former
> are ASLv2 licensed (even if each project forgot to add a license
> header), but the big issue is the licensing for the other poms.

there are quite a number of relative issues all reasonably important

> >> If we can assume that a pom is always redistributed under the same terms
> >> of the jar/artifact it describes then I think we are ok with our current
> >> NOTICES/LICENSE comments, otherwise it will be a real pain to understand
> >> what we can do.
> >
> > 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)


> If the dependencies is not copyrightable, the license reference is not
> copyrightable and the artifactId+groupdId is not copyrightable then 99%
> of POMs are not copyrightable and we are safe, but we end up
> understanding something of this complicate issue this should be
> definitely written somewhere in apache documents (maybe the 3rd party
> page from cliff is a good place, or the maven repository documentation).

AIUI the expression is probably copyrightable but the facts themselves are not

- robert

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message