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). 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. I still can't remember of specific svn comments to commits adding a new jar to svn (if this also needs a specific comment). >>> 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? >> Back to the jsieve issue, excluding junit, activation and mail all the >> other dependencies are ASF projects, so I would assume that their poms >> taken from ASF m2-rsync-repository is ASLv2 licensed (and they simply do >> not add the license to their poms). > > all pom's from apache projects should be covered by CLAs and so should > have headers. i'll raise this on repo. I agree, thank you. >> 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? >> 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 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? 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. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
