[jira] [Comment Edited] (TIKA-1581) jhighlight license concerns
[
https://issues.apache.org/jira/browse/TIKA-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371423#comment-14371423
]
Steve Rowe edited comment on TIKA-1581 at 3/20/15 3:02 PM:
---
Interestingly, the JFlex source files ({{\*.flex}}) for the {{\*.java}} files
in question are dual-CDDL-LGPL licensed, so it is theoretically possible to
just regenerate the {{.java}} files (I see a {{jflex}} target in the
{{build.xml}}), and then apply the license from the {{.flex}} files to the
regenerated {{.java}} files. I highly suspect, given this situation, that the
solo LGPL license in the {{.java}} files is simply a mistake.
Note that there is a fork of jhighlight on Github - maybe we can ask them to
fix this issue using the method I describe above, and then switch Tika to using
the fork?: [https://github.com/codelibs/jhighlight]
was (Author: steve_rowe):
Interestingly, the JFlex source files ({{\*.flex}}) for the {{\*.java}} files
in question is dual-CDDL-LGPL licensed, so it is theoretically possible to just
regenerate the {{.java}} files (I see a {{jflex}} target in the {{build.xml}}),
and then apply the license from the {{.flex}} files to the regenerated
{{.java}} files. I highly suspect, given this situation, that the solo LGPL
license in the {{.java}} files is simply a mistake.
Note that there is a fork of jhighlight on Github - maybe we can ask them to
fix this issue using the method I describe above, and then switch Tika to using
the fork?: [https://github.com/codelibs/jhighlight]
> jhighlight license concerns
> ---
>
> Key: TIKA-1581
> URL: https://issues.apache.org/jira/browse/TIKA-1581
> Project: Tika
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Karl Wright
>
> jhighlight jar is a Tika dependency. The Lucene team discovered that, while
> it claims to be a CDDL/LGPL dual-license, some of its functionality is LGPL
> only:
> {code}
> Solr's contrib/extraction contains jhighlight-1.0.jar which declares itself
> as dual CDDL or LGPL license. However, some of its classes are distributed
> only under LGPL, e.g.
> com.uwyn.jhighlight.highlighter.
> CppHighlighter.java
> GroovyHighlighter.java
> JavaHighlighter.java
> XmlHighlighter.java
> I downloaded the sources from Maven
> (http://search.maven.org/remotecontent?filepath=com/uwyn/jhighlight/1.0/jhighlight-1.0-sources.jar)
> to confirm that, and also found this SVN repo:
> http://svn.rifers.org/jhighlight/tags/release-1.0, though the project's
> website seems to not exist anymore (https://jhighlight.dev.java.net/).
> I didn't find any direct usage of it in our code, so I guess it's probably
> needed by a 3rd party dependency, such as Tika. Therefore if we e.g. omit it,
> things will compile, but may fail at runtime.
> {code}
> Is it possible to remove this dependency for future releases, or allow only
> optional inclusion of this package? It is of concern to the ManifoldCF
> project because we distribute a binary package that includes Tika and its
> required dependencies, which currently includes jHighlight.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TIKA-1581) jhighlight license concerns
[
https://issues.apache.org/jira/browse/TIKA-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371423#comment-14371423
]
Steve Rowe edited comment on TIKA-1581 at 3/20/15 3:01 PM:
---
Interestingly, the JFlex source files ({{\*.flex}}) for the {{\*.java}} files
in question is dual-CDDL-LGPL licensed, so it is theoretically possible to just
regenerate the {{.java}} files (I see a {{jflex}} target in the {{build.xml}}),
and then apply the license from the {{.flex}} files to the regenerated
{{.java}} files. I highly suspect, given this situation, that the solo LGPL
license in the {{.java}} files is simply a mistake.
Note that there is a fork of jhighlight on Github - maybe we can ask them to
fix this issue using the method I describe above, and then switch Tika to using
the fork?: [https://github.com/codelibs/jhighlight]
was (Author: steve_rowe):
Interestingly, the JFlex source files ({{\*.flex}}) for the {{\*.java}} files
in question is dual-CDDL-LGPL licensed, so it is theoretically possible to just
regenerate the {{.java}} files (I see a {{jflex}} target in the {{build.xml}},
and then apply the license from the {{.flex}} files to the regenerated
{{.java}} files. I highly suspect, given this situation, that the solo LGPL
license in the {{.java}} files is simply a mistake.
Note that there is a fork of jhighlight on Github - maybe we can ask them to
fix this issue using the method I describe above, and then switch Tika to using
the fork?: [https://github.com/codelibs/jhighlight]
> jhighlight license concerns
> ---
>
> Key: TIKA-1581
> URL: https://issues.apache.org/jira/browse/TIKA-1581
> Project: Tika
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Karl Wright
>
> jhighlight jar is a Tika dependency. The Lucene team discovered that, while
> it claims to be a CDDL/LGPL dual-license, some of its functionality is LGPL
> only:
> {code}
> Solr's contrib/extraction contains jhighlight-1.0.jar which declares itself
> as dual CDDL or LGPL license. However, some of its classes are distributed
> only under LGPL, e.g.
> com.uwyn.jhighlight.highlighter.
> CppHighlighter.java
> GroovyHighlighter.java
> JavaHighlighter.java
> XmlHighlighter.java
> I downloaded the sources from Maven
> (http://search.maven.org/remotecontent?filepath=com/uwyn/jhighlight/1.0/jhighlight-1.0-sources.jar)
> to confirm that, and also found this SVN repo:
> http://svn.rifers.org/jhighlight/tags/release-1.0, though the project's
> website seems to not exist anymore (https://jhighlight.dev.java.net/).
> I didn't find any direct usage of it in our code, so I guess it's probably
> needed by a 3rd party dependency, such as Tika. Therefore if we e.g. omit it,
> things will compile, but may fail at runtime.
> {code}
> Is it possible to remove this dependency for future releases, or allow only
> optional inclusion of this package? It is of concern to the ManifoldCF
> project because we distribute a binary package that includes Tika and its
> required dependencies, which currently includes jHighlight.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TIKA-1581) jhighlight license concerns
[
https://issues.apache.org/jira/browse/TIKA-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371423#comment-14371423
]
Steve Rowe commented on TIKA-1581:
--
Interestingly, the JFlex source files ({{\*.flex}}) for the {{\*.java}} files
in question is dual-CDDL-LGPL licensed, so it is theoretically possible to just
regenerate the {{.java}} files (I see a {{jflex}} target in the {{build.xml}},
and then apply the license from the {{.flex}} files to the regenerated
{{.java}} files. I highly suspect, given this situation, that the solo LGPL
license in the {{.java}} files is simply a mistake.
Note that there is a fork of jhighlight on Github - maybe we can ask them to
fix this issue using the method I describe above, and then switch Tika to using
the fork?: [https://github.com/codelibs/jhighlight]
> jhighlight license concerns
> ---
>
> Key: TIKA-1581
> URL: https://issues.apache.org/jira/browse/TIKA-1581
> Project: Tika
> Issue Type: Bug
>Affects Versions: 1.7
>Reporter: Karl Wright
>
> jhighlight jar is a Tika dependency. The Lucene team discovered that, while
> it claims to be a CDDL/LGPL dual-license, some of its functionality is LGPL
> only:
> {code}
> Solr's contrib/extraction contains jhighlight-1.0.jar which declares itself
> as dual CDDL or LGPL license. However, some of its classes are distributed
> only under LGPL, e.g.
> com.uwyn.jhighlight.highlighter.
> CppHighlighter.java
> GroovyHighlighter.java
> JavaHighlighter.java
> XmlHighlighter.java
> I downloaded the sources from Maven
> (http://search.maven.org/remotecontent?filepath=com/uwyn/jhighlight/1.0/jhighlight-1.0-sources.jar)
> to confirm that, and also found this SVN repo:
> http://svn.rifers.org/jhighlight/tags/release-1.0, though the project's
> website seems to not exist anymore (https://jhighlight.dev.java.net/).
> I didn't find any direct usage of it in our code, so I guess it's probably
> needed by a 3rd party dependency, such as Tika. Therefore if we e.g. omit it,
> things will compile, but may fail at runtime.
> {code}
> Is it possible to remove this dependency for future releases, or allow only
> optional inclusion of this package? It is of concern to the ManifoldCF
> project because we distribute a binary package that includes Tika and its
> required dependencies, which currently includes jHighlight.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
