And…looks like Tim already did that thanks Tim! ☺ And Joe…
From: Chris Mattmann <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, January 23, 2018 at 8:25 AM To: "[email protected]" <[email protected]> Subject: Re: Tika-parsers using cat-x json.org dep and is geoapis ok? Thanks for checking into this Joe. This seems odd but really isn’t Tika has a direct dependency then on GeoAPI which is clearly something that should be included if you are using SIS. It may just be in tika-parsers directly since that’s where we aggregate all of the sub parsers and their dependencies (for building OSGI, etc etc.) The root of this issue is not in Tika though I can say that for sure – this is a dependency introduced from using SIS. If modern versions of SIS have moved on to a dependency that seems to be licensed less obtusely, perhaps we should just upgrade Tika to use that newer SIS and be done with it? Separately, it would be good to know what SIS folks think mostly b/c I have no clue what GeoAPI does precisely other than it’s a dpendency from SIS. Sorry for more confusion 😉 Cheers, Chris From: Joe Witt <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, January 23, 2018 at 7:04 AM To: "[email protected]" <[email protected]> Subject: Re: Tika-parsers using cat-x json.org dep and is geoapis ok? i said yep to be agreeable then thought... the problem dependency isnt coming in transitively via apache sis. it is a dependency tika parsers pulls in itself via geoapis. https://github.com/apache/tika/blob/master/tika-parsers/pom.xml ill raise the license question on legal but ill avoid bugging the sis folks just yet. thanks joe On Jan 23, 2018 9:58 AM, "Joe Witt" <[email protected]> wrote: yep. sounds fair On Jan 23, 2018 9:52 AM, "Chris Mattmann" <[email protected]> wrote: Hi Joe, Great analysis. Can you do me a favor: 1. Raise a LEGAL JIRA with the below insight. 2. Contact the Apache SIS PMC and ask them how they dealt with it? SIS is an ASF project and is expected to be following ASF release guidelines which gives me confidence in the product (and its dependencies that they ship). Martin Desruisseaux is an ASF member and their Chair and is very thorough I'm sure they ran into this and have some idea. Tika should action (or not) based on #1 and 2 above. Sound good? Cheers, Chris Mattmann (wearing his VP, Legal hat). On 1/23/18, 5:53 AM, "Joe Witt" <[email protected]> wrote: Chris Bottom line up front: Is https://github.com/unitsofmeasurement/jsr-275/blob/0.9.3/LICENSE.txt Category A or Category B? ****** a bunch of words to explain why I'm asking **** I truly do not wish to create a problem where there is none. L&N is truly a painful thing. That said, based on my experience and current understanding of ASF policies and guidance I do believe there is a problem. If you think this thread is better on legal-discuss please let me know. My hope in starting the thread here was to get a 'yep this is a known thing - we cleared it with legal - here is a mailing list thread or JIRA or something'. What I believe to be true is that there are binary artifacts which are under licenses. Those licenses are either compatible with the ASF legal policy or they are not and specifically they're either listed as Category-A or Category-B from https://www.apache.org/legal/resolved.html. If they're not you cannot use them as binary dependencies until they are on that list. What is also true is that apache-tika-parsers version 1.16 (at least) depends on org/opengis/geoapi 3.0.0 which depends on javax.measure.jsr-275:0.9.3. That artifact appears to be under this license: https://github.com/unitsofmeasurement/jsr-275/blob/0.9.3/LICENSE.txt. Plainly, from my quick read and review that binary artifact (jsr-275:0.9.3) does not appear to be a Category A or Category B license. Do you believe it is? If yes which Cat-A/Cat-B is it considered to be? Is there a mailing list thread, Legal-Discuss, or L&N entry in Tika that calls this out so I can reference that? Now for more general background: There are all kinds of threads on the Internet about the problems with JSR-275 and that JSR-363 is the way to go to move on with regard to the unit of measure work, etc.. If you look at the source for opengis/geoapi which I believe is here https://github.com/opengeospatial/geoapi/tree/3.0.0 which is what tika-parsers uses then it will pull in the jsr-275:jar:0.9.3. If you look at the source for opengis/geoapi for latest milestone release https://github.com/opengeospatial/geoapi/tree/4.0-M06 you can see they've moved on from JSR-275 and now use JSR-363. Further, the Apache SIS project in their Nov 2017 release 0.8 (Tika-parsers 1.16 uses apache sis 0.6) clearly stated in their NOTICE they depend on JSR-363. Not sure if they were specifically relying on JSR-275 before that or not as it isn't called out. Thanks Joe On Mon, Jan 22, 2018 at 11:43 AM, Chris Mattmann <[email protected]> wrote: > Hi Joe, > > > > My quick read on the license is that it’s a spec jar in a transitive > dependency. SIS has made > many releases and is an ASF project (of which this JSR 275 is one dependency > that I believe is > just the JSR spec API). I think you’re fine to use Tika and to use SIS in > NiFi. > > > > Cheers, > > Chris > > > > > > > > > > From: Joe Witt <[email protected]> > Reply-To: "[email protected]" <[email protected]> > Date: Monday, January 22, 2018 at 8:06 AM > To: "[email protected]" <[email protected]> > Subject: Re: Tika-parsers using cat-x json.org dep and is geoapis ok? > > > > tika team > > > > bumping this thread as i beleive tika is using a non asl/asf compatible > library. > > > > thanks > > joe > > > > On Dec 6, 2017 12:27 AM, "Joe Witt" <[email protected]> wrote: > > Tika Team, > > I'm finally coming back to this thread and getting Apache NiFi all > caught up with the latest Tika-Core and Tika-Parsers version. > > I am back to looking at the GeoAPIs 3.0.0 stuff which as you mentioned > the license is ok. It does, however, have a transitive dependency on > 'JSR 275 0.9.3' library. The license for this was much harder to find > but this appears to be it [1] and it appears decided un-ASF friendly > to me. Can you please clarify why this library is ok to use? I'm just > trying to get our L&N done for NiFi so want to understand how this is > ok. I was not able to find anything in the Legal discuss/JIRA for > this. > > Here is the GeoAPIs team talking about this dependency and what they > will do with it [2, 3]. > > [1] https://github.com/unitsofmeasurement/jsr-275/blob/0.9.3/LICENSE.txt > [2] https://osgeo-org.atlassian.net/browse/GEO-190 > [3] https://github.com/opengeospatial/geoapi/issues/8 > > Thanks > Joe > > On Wed, Nov 16, 2016 at 11:50 AM, Chris Mattmann <[email protected]> > wrote: >> Thanks Joe. The legal-discuss/committee for the ASF is discussing getting >> a 6 >> month time period on this b/c there are transitive dependencies all over >> for >> this. We will be appreciative of a time frame since I think replacing it >> with >> another JSON library will likely be non trivial and involve some PRs. >> >> RE: [2] and [3] it’s the same dependencies that Apache SIS uses and I >> think >> we are good there – in fact they are pulled in by SIS. >> >> Thanks, >> Chris >> >> >> >> >> On 11/15/16, 8:06 PM, "Joe Witt" <[email protected]> wrote: >> >> Tika Team, >> >> The ASF has recently changed their mind regarding the json.org [0] >> dependency this individual is referring to [1]. I believe that JIRA needs >> to be reopened. It has blocked Apache NiFi from being able to update to >> using the newest tika-parsers. >> >> In reviewing the list of other new dependencies I also ran across >> geoapis which was pulled in during [2]. It's license looks questionable to >> me given the claim of need to give notice to any changed OGC files. It >> looks BSD-ish but not quite sure [3]. I don't see this called out in your >> LICENSE or NOTICE and I could not find a legal thread. Are you sure this is >> ok to use? >> >> [0] https://www.apache.org/legal/resolved#category-x >> [1] https://issues.apache.org/jira/browse/TIKA-1804 >> [2] https://issues.apache.org/jira/browse/TIKA-443 >> [3] https://github.com/opengeospatial/geoapi/blob/3.0.0/LICENSE.txt >> >> Thanks >> Joe >> >> >>
