Here is the legal JIRA to ask about the categorization of that license https://issues.apache.org/jira/browse/LEGAL-360
Thanks Joe On Tue, Jan 23, 2018 at 10:04 AM, Joe Witt <[email protected]> wrote: > 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 >>> >> >>> >> >>> >> >>> >>> >>> >
