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 >> >> >>
