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/opengeospat >> ial/geoapi/blob/3.0.0/LICENSE.txt >> >> >> >> Thanks >> >> Joe >> >> >> >> >> >> >> >> >> >>
