On 9/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > On 9/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > >> I'm a bit confused because in 3 years I spent around ASF projects I > >> never seen anyone in ASF using a similar sentence when committing third > >> party jars or resources to svn. Have we all did it wrong in past or am I > >> simply misunderstanding the icla about this issue? > > > > you may have missed them. for example: > > > >> % svn log src/main/java/org/apache/james/mime4j/MimeStreamParser.java > >> ------------------------------------------------------------------------ > >> r558847 | rdonkin | 2007-07-23 20:54:08 +0100 (Mon, 23 Jul 2007) | 1 line > >> > >> Pull parser patch https://issues.apache.org/jira/browse/MIME4J-19. > >> Contributed by Jochen Wiedmann. > >> ------------------------------------------------------------------------ > >> r541636 | norman | 2007-05-25 14:17:21 +0100 (Fri, 25 May 2007) | 1 line > >> > >> Allow exceptions from a ContentHandler (Thx to Jukka). See MIME4J-16 > > > > i prefer 'Contributed by' rather than 'Submitted on behalf of' > > I also always (I hope always) use "thanks to" or "contributed by" or > "submitted by" when I commit a patch submitted to JIRA by someone else, e.g: > ------- > Let BodyDescriptor be an interface and move current behavior to > DefaultBodyDescriptor (MIME4J-22) > - [JW#2] Let BodyDescriptor provide full blown access to the headers > - Patch submitted by Jochen Wiedmann > ------------------------------------------------------ > r572819 | bago | 2007-09-04 14:56:58 +0100 (Tue, 04 Sep 2007) > ------ > > 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. > It's not a commit on behalf of someone else and it is not a commit of an > original work, because, like 3rd party jars, it is not something we/I > created, but something we simply include for redistribution under a (I > hope) compatible license. > > The poms are publicly available on ibiblio or other maven repositories > like the jars. Unlike the jars they (most time) don't include a LICENSE > file/header. they should have a header > I still can't remember of specific svn comments to commits adding a new > jar to svn (if this also needs a specific comment). i agree that this needs to be improved > >>> in other words, is it safe for me to attach the standard license headers > >>> > >>> - robert > >> The poms are descriptor used when the artifacts have been published to > >> the maven repository. Most times they have been authored by the > >> publishing project, some times they have been authored by the one that > >> submitted the jar to the repository. > > > > yes > > > >> I don't know what is the correct licensing for that files when nothing > >> is specified in the file itself (do the "maven repository" people ask > >> for any license/copyright permissions to submitter?). > > > > they should do > > This is probably the "key" of this issue. What is the license for pom > files redistributed by ibiblio and other maven repositories? +1 <snip> > >> the 2 glassfish poms (activation and mail) are from their main maven > >> repository: > >> https://maven-repository.dev.java.net/nonav/repository/javax.mail/poms/ > >> https://maven-repository.dev.java.net/nonav/repository/javax.activation/poms/ > >> I would say that the intended licensing for that files is the same of > >> the described library, but this is not obvious and not described anyway. > > > > it would probably be a good idea to raise this on the maven list > > Do you see this as a maven list issue or a repository list issue? maven: IIRC they've had issues with license comments being stripped but they need to think about the general problem of licensing for the poms. they have a ton of valuable meta-data with uncertain licensing and no clear legal provinence. > >> About the junit one IIRC I made it when I committed it to jspf or mime4j > >> (don't remember now) and I took the original simple pom from ibiblio and > >> added a description and licensing (so to have them added to the NOTICE) > >> like the one present in newer poms: > >> ftp://ibiblio.org/pub/packages/maven2/junit/junit/4.1/junit-4.1.pom > >> > >> I admit that I never considered the licensing issue for the pom files, > >> but given that we finally decided to bundle them in our svn to help > >> offline build and create "almost self contained" maven2 (website) builds > >> for most of our projects this is clearly something to be better understood. > > > > +1 > > > > - robert > > This legal stuff is really a PITA and I want to thank you again for > everything you do to help us better understanding the issues. > > For the 2 sun poms, would it fix our issue if we use the ibiblio poms > instead of the java.net ones? > http://repo1.maven.org/maven2/javax/mail/mail/1.4/mail-1.4.pom > http://repo1.maven.org/maven2/javax/activation/activation/1.1/activation-1.1.pom probably not > For the junit pom, it should be the same: > http://repo1.maven.org/maven2/junit/junit/3.8.2/junit-3.8.2.pom > > The ibiblio versions do not have a license header, but they all at least > include a link to the real license in the <licenses> descriptor. > > This does not make clear that the license also apply to the pom: can we > guess this? not sure: the meta-data may have been collected separately > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
