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 <[email protected]> > 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
