geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: [VOTE] Release Geronimo Customized Tomcat
Date Sat, 01 May 2010 01:57:08 GMT
Thanks for checking it, usually, I "hate" those license related issues ;-)
Just find that Kevan has post a message in Tomcat community, so depending on
the result there, we could decide whether we would continue or cancel this
vote.

2010/5/1 David Jencks <david_jencks@yahoo.com>

> Mark Thomas changed the license in rev 934219 on april 14 2010.  That
> change and rev 934220 seem to indicate that the tomcat community thinks
> including EPL source in apache svn and releases is fine.  The tomcat copies
> are modified from the bcel "originals" including:
>
> - changing the package name  (rev 887296, 887302) (this could be done with
> maven-shade-plugin from binaries, were they to have been aleady released
> which AFAICT they aren't)
> - removing unused methods  ( rev 887610, 887613)
>
> These seem to me to be functional modifications and so decidedly outside
> the acceptable uses of CPL/EPL licensed source in apache.
>
> These files aren't in the latest bcel tag.  As seen below the bcel source
> has the CPL license.  BCEL needs to fix this, right?
>
>
> http://svn.apache.org/repos/asf/jakarta/bcel/trunk/src/main/java/org/apache/bcel/classfile/EnclosingMethod.java
>
> http://svn.apache.org/repos/asf/jakarta/bcel/trunk/src/main/java/org/apache/bcel/classfile/LocalVariableTypeTable.java
>
> I'm having some trouble interpreting bcel svn history but I think these
> were added in rev 411580 as part of a GSOC project.
>
> david jencks
>
> On Apr 30, 2010, at 1:59 PM, Kevan Miller wrote:
>
>
> On Apr 30, 2010, at 3:10 PM, Joe Bohn wrote:
>
>
> IIUC then I think we do need to fix this for the following reasons:
>
> 1) We are releasing these artifacts - even if they are copies of Tomcat
> artifacts.  The artifact is being released under the groupID
> "org.apache.geronimo.ext.tomcat" and it is being released in source (not
> just binary) form.
>
>
> I agree with your general conclusion, but don't necessarily agree with how
> you got there... :-). I definitely agree with your statement in 1).
>
>
> 2) In addition to that, I can't see where Tomcat has actually ever released
> these files - so it may be that we are "pre-releasing" them rather than
> "re-releasing" them.  I see a tag for Tomcat 7.0.0 RC1 but I don't see any
> artifacts available yet on any repositories.
>
>
> As far as I can tell, Tomcat never concluded their vote on 7.0.0. I would
> assume the vote is cancelled. The issue of these two files was raised in
> their vote. And the possibility of removing them was also suggested. More
> below...
>
> <snip>
>
>
> On 4/30/10 1:10 PM, Joe Bohn wrote:
>
>
> -1 (sorry)
>
>
> There are some files with invalid license headers:
>
>
> /util/src/main/java/org/apache/tomcat/util/bcel/classfile/EnclosingMethod.java
>
>
>
> /util/src/main/java/org/apache/tomcat/util/bcel/classfile/LocalVariableTypeTable.java
>
>
> The license headers are not Apache source license headers. However, this
> does not necessarily make them invalid source for an Apache release. The
> files are not AL2 licensed. So, it makes sense that they would not contain
> an Apache source license header. Apache releases can contain source files
> that are licensed under a number of licenses that the ASF has determined to
> be compatible with AL2. Here is a pretty good overview --
> http://www.apache.org/legal/3party.html
>
> The source files in question were originally CPL Licensed. There's a
> further comment that the ASF has elected to distribute the file under an EPL
> license. I haven't looked to see when this "relicense" occurred, or if I
> agree with it. For this discussion it's largely irrelevant. CPL and EPL are
> equivalent for the purposes of this discussion.
>
> From the web site, you'll note that both CPL 1.0 and EPL 1.0 are Category B
> licenses. As such, these files could not be included in an Apache *source*
> release (they could be included in binary form), unless they fall into the
> following exclusion:
>
> "For small amounts of source that is directly consumed by the ASF product
> at runtime in source form, and for which that source is unlikely to be
> changed anyway (say, by virtue of being specified by a standard), this
> action is sufficient. An example of this is the web-facesconfig_1_0.dtd,
> whose inclusion is mandated by the JSR 127: JavaServer Faces specification.
>
> Code that is more substantial, more volatile, or not directly consumed at
> runtime in source form may only be distributed in binary form."
>
> My guess is that this code is unlikely to change, but probably still does
> not fall under the above guidelines (e.g. AFAIK, it is "not directly
> consumed at runtime in source form"). We could discuss this if others
> disagree with this conclusion...
>
> One note: If the license for these files were instead BSD or any other
> Category A license, they would be fine for an Apache release...
>
> --kevan
>
>
>


-- 
Ivan

Mime
View raw message