[
https://issues.apache.org/jira/browse/XALANJ-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12833616#action_12833616
]
Michael Glavassevich edited comment on XALANJ-2438 at 2/14/10 8:00 PM:
-----------------------------------------------------------------------
Derivative works such as the Sun JAXP RI are permitted by the Apache License to
distribute their software with different or additional license terms provided
that they comply to the redistribution terms of the Apache License. Depending
on those extra / different terms the resulting work may not be able to be
included in an ASF project. It may not even be open source anymore. The concern
with developers studying and contributing to the JAXP RI is the potential for
contamination of the ASF project with code that carries license terms which are
incompatible with Apache's licensing policy [1]. To my knowledge I don't
believe any of Sun's distributions (even the OpenJDK one which I believe is a
modified GPL) meets these requirements. Note that I haven't reviewed Sun's
licensing terms myself in detail and I'm not a lawyer, so feel free to start a
thread on legal-disc...@apache.org [2] if you have doubts.
Regarding source contamination, it can happen inadvertently. You may have been
reading code that Sun never donated to the ASF and that could have inspired
(some of) the contents of your patch without realizing that it may not have
been your original idea. Did that happen here? I don't know but there's a risk
that it did and can understand why Henry feels this would need to be assessed /
committed by a Sun or Oracle employee since they own the copyright on
modifications / additions that have been made since forking from the ASF
codebase.
Thanks.
[1] http://www.apache.org/legal/3party.html
[2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/
was (Author: mrgla...@ca.ibm.com):
Derivative works such as the Sun JAXP RI are permitted by the Apache
License to distribute their software with different or additional license terms
provided that they comply to the redistribution terms of the Apache License.
Depending on those extra / different terms the resulting work may not be able
to be included in an ASF project. It may not even be open source anymore. The
concern with developers studying and contributing to the JAXP RI is the
potential for contamination of the ASF project with code that carries license
terms which are incompatible with Apache's licensing policy [1]. To my
knowledge I don't believe any of Sun's distributions (even the OpenJDK one
which I believe is a modified GPL) meets these requirements. Note that I
haven't reviewed Sun's licensing terms myself in detail and I'm not a lawyer,
so feel free to start a thread on legal-disc...@apache.org [2] if you have
doubts.
Regarding source contamination, it can happen inadvertently. You may have been
reading code that Sun never donated to the ASF and that could have inspired
(some of) the contents of your patch without realizing that it may not have
been your original idea. Did that happen here? I don't know but there's a risk
that it did and can understand why Henry feels this would need to be assessed /
committed by a Sun or Oracle employee since they own the copyright on any
modifications / additions that have been made since forking from the ASF
codebase.
Thanks.
[1] http://www.apache.org/legal/3party.html
[2] http://mail-archives.apache.org/mod_mbox/www-legal-discuss/
> [PATCH] XSLTC ignores XPath predicates in xsl:key elements
> ----------------------------------------------------------
>
> Key: XALANJ-2438
> URL: https://issues.apache.org/jira/browse/XALANJ-2438
> Project: XalanJ2
> Issue Type: Bug
> Components: XSLTC
> Affects Versions: The Latest Development Code
> Environment: Linux and Windows XP with Sun JRE 1.5.0_14, 1.5.0_15,
> 1.6.0_04 and 1.6.0_05
> Reporter: Helge Schulz
> Priority: Blocker
> Fix For: The Latest Development Code
>
> Attachments: PredicateInKey-Xalan-SVN-r889881.patch,
> PredicateInKey-XSLT-Test-1.1.jar, PredicateInKey-XSLT-Test-1.2.jar,
> PredicateInKey-XSLT-Test-1.3.jar, PredicateInKey-XSLT-Test.jar,
> PredicateInKey.out, PredicateInKey.xml, PredicateInKey.xsl
>
>
> The Xalan XSLT compiler (XSLTC) ignores XPath predicates in xsl:key
> elements since the class 'org.apache.xalan.xsltc.compiler.Stylesheet'
> was rearranged in august 2003 to reorder the compilation of top level
> XSLT elements (including keys) to respect dependencies between global
> XSLT variables and keys. Method 'compileTopLevel' was changed to emit
> code also for key elements and not emit code calling the method generated
> by 'compileBuildKeys'. For this reason the byte code for each key element
> is generated twice: First time into generated method 'buildKeys' from
> 'compileBuildKeys' and second time into generated method 'topLevel'
> from 'compileTopLevel'. Method 'buildKeys' is still necessary, because
> it is called by the XSLT 'document' function, if additional input
> documents are loaded later.
> Unfortunately the translate method of some XPath elements expected to
> be called only once and they remove sub elements while their first execution.
> So all XPath predicates get lost in class
> 'org.apache.xalan.xsltc.compiler.FilterExpr'
> and 'org.apache.xalan.xsltc.compiler.Step' by a remove operation on
> the '_predicates' container while the execution from 'compileBuildKeys'.
> So 'compileTopLevel' generates wrong code for all key elements containing
> predicates in their XPath expressions.
> The attached patch changes the 'FilterExpr' and 'Step' class to use an
> index variable to determine the current predicate and to not remove them.
> This patch was tested with the current Subversion version of Xalan
> (last change of Xalan tree in revision 584164) and with Sun JDK 1.5.0_14,
> 1.5.0_15, 1.6.0_04 and 1.6.0_05.
> This bug exists also in Sun JRE 1.6 (1.6.0 up to 1.6.0_05) and JRE 1.5
> (since 1.5.0_12 up to 1.5.0_15) in classes
> 'com.sun.org.apache.xalan.internal.xsltc.compiler.FilterExpr' and
> 'com.sun.org.apache.xalan.internal.xsltc.compiler.Step'. The attached
> test JAR file contains also patches for these versions and fixes in form
> of JAR files to be installed into '../jre/lib/endorsed' directories of
> Sun JRE installations. The last Sun JRE version with correct handling
> of xls:key elements is 1.5.0_11.
> Please add the attached test files to the Xalan test suite. I have
> released them under Apache license version 2.0.
> Helge Schulz - OpenSHORE.org
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscr...@xml.apache.org
For additional commands, e-mail: xalan-dev-h...@xml.apache.org
