www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: A grace period for getting rid of JSON license jars
Date Mon, 21 Nov 2016 15:07:41 GMT
There's another aspect to this: the org.json package domain is  owned
by a 3rd party.

On 21 November 2016 at 11:38, sebb <sebbaz@gmail.com> wrote:
> On 21 November 2016 at 11:16, Simon Lessard <simon.lessard.3@gmail.com> wrote:
>> Not sure what you mean by that.
>>
>> Maven gives precedence to locally defined dependencies if you have
>>
>> <dependencides>
>>   <dependency>
>>     <groupId>foo.bar</groupId>
>>     <artifactId>project-depending-on-z</artifactId>
>>   </dependency>
>>   <dependency>
>>     <groupId>x.y</groupId>
>>     <artifactId>z</artifactId>
>>     <scope>provided</scope>
>>   </dependency>
>> </dependencides>
>>
>> Then z.jar will be excluded from the runtime dependencies (and packaging
>> through Shade or other)
>
> The problem is that the application will likely continue to work most
> of the time.
> Debugging failures can be quite difficult (you see similar issues with
> web app classloader problems all the time)
>
> If you know you have to do this you can probably take the time to fix
> the Maven classpath.
> But this will be an ongoing maintenance issue.
>
>>
>> But in any case it will only work if the publicly usable API is identical in
>> the two jars.
>> Or rather, if the new jar contains all the publicly usable objects (methods,
>> fields,classes etc) from the original jar.
>>
>> That's kind of the point of the new jar
>
> In which case it's incomplete; there's no JSONML class in the new jar
> for example.
> I've not checked the fields that may have been used.
>
>>
>> And the new jar will have to continue to track changes to the old jar.
>>
>> I disagree, in the long term the projects can either switch to Jackson or
>> some other licence-compliant library, or we can hope that json.org fixes
>> their licence.
>
> There will always be projects that are unable or unwilling to switch.
>
>>
>> Regards,
>>
>> On Mon, Nov 21, 2016 at 12:02 PM, sebb <sebbaz@gmail.com> wrote:
>>>
>>> On 21 November 2016 at 10:52, Simon Lessard <simon.lessard.3@gmail.com>
>>> wrote:
>>> > Hi Sebb,
>>> >
>>> > It should not be a major problem, you simply have to exclude the
>>> > json.org
>>> > libray in the POM. There's two ways to do that:
>>> > 1. The clean way: for each dependency using json.org, add the <exclude>
>>> > tag
>>> > (require to use mvn dependency:tree until there's no trace of it left)
>>>
>>> That is quite a lot of effort for a large project.
>>>
>>> > 2. The not so clean way: Define json.org as a project dependency in the
>>> > provided scope in the POM. You'll still have both library at compile
>>> > time,
>>> > but only one at packaging.runtime
>>>
>>> Not sure what you mean by that.
>>>
>>> But in any case it will only work if the publicly usable API is
>>> identical in the two jars.
>>> Or rather, if the new jar contains all the publicly usable objects
>>> (methods, fields,classes etc) from the original jar.
>>> And the new jar will have to continue to track changes to the old jar.
>>>
>>> >
>>> > Regards,
>>> >
>>> > On Mon, Nov 21, 2016 at 11:45 AM, sebb <sebbaz@gmail.com> wrote:
>>> >>
>>> >> On 19 November 2016 at 03:08, Ted Dunning <ted.dunning@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> > So ... there are a few questions popping up in different forms
that
>>> >> > bear
>>> >> > on
>>> >> > the same issues.  Here are some paraphrases and my answers:
>>> >> >
>>> >> > 1) Does the replacement library use the org.json package?
>>> >> >
>>> >> > Yes. It does. This may be a problem. If it turns out that way,
I will
>>> >> > spin
>>> >> > another version that uses a different package root.
>>> >>
>>> >> Yes, it is a potential major problem.
>>> >>
>>> >> Think of it this way:
>>> >> would it be OK to set up an application with both your library and the
>>> >> original library on the classpath?
>>> >>
>>> >> If you tell Maven that your jar and the original jar have different
>>> >> (gid,aid) coords, then Maven has no way of knowing that these contain
>>> >> the same packages.
>>> >> So Maven will add them both to the classpath if they are both
>>> >> referenced.
>>> >>
>>> >> > On the other hand, it looks to me so far that re-using the org.json
>>> >> > package
>>> >> > actually makes proper surgery easier.
>>> >>
>>> >> Yes, but the cost is potential jar hell.
>>> >>
>>> >> > 2) I have a dependency on a third party that has a dependency on
>>> >> > org.json
>>> >> > stuff.
>>> >> >
>>> >> > First and most inflammatory answer: that makes the third party
>>> >> > dependency
>>> >> > category X.
>>> >> >
>>> >> > Second and much less inflammatory answer: because the package name
is
>>> >> > the
>>> >> > same, you are likely to be able to satisfy the transitive dependency
>>> >> > with my
>>> >> > packaging of the Android library. It may require slightly more
>>> >> > footwork
>>> >> > than
>>> >> > just swapping out the pom clause as I suggested earlier.
>>> >> >
>>> >> > 3) I have a dependency that includes the org.json source code.
>>> >> >
>>> >> > First and most inflammatory answer: that makes the third party
>>> >> > dependency
>>> >> > category X.
>>> >> >
>>> >> > Second and much less inflammatory answer: you might be able to
>>> >> > convince
>>> >> > your
>>> >> > dependency to use the code I extracted instead. If not, that is
a
>>> >> > really
>>> >> > difficult spot.
>>> >> >
>>> >> > 4) I have a dependency that includes the org.json jar file.
>>> >> >
>>> >> > First and most inflammatory answer: that makes the third party
>>> >> > dependency
>>> >> > category X.
>>> >> >
>>> >> > Second and much less inflammatory answer: This should be solvable
by
>>> >> > simply
>>> >> > swapping jars. Explicitly packaging jars that are in maven central
is
>>> >> > kind
>>> >> > of perverse, however, and really ought to be discouraged.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, Nov 18, 2016 at 5:44 PM, Joe Witt <joe.witt@gmail.com>
wrote:
>>> >> >>
>>> >> >> Ted,
>>> >> >>
>>> >> >> Agreed and understood that json.org's library is now considered
>>> >> >> category-x.
>>> >> >>
>>> >> >> In this case the discussion centers around the grace period
to
>>> >> >> continue apache releases while resolving pre-existing valid
usage of
>>> >> >> the library.
>>> >> >>
>>> >> >> Definitely appreciate you taking the initiative on providing
an
>>> >> >> alternative implementation.  In the case I'm concerned about
we have
>>> >> >> a
>>> >> >> library, twitter4j, which uses the json.org code as a source
>>> >> >> dependency so we'd not be able to exclude their binary dep
and
>>> >> >> replace
>>> >> >> it.
>>> >> >>
>>> >> >> As I mentioned previously we've already taken the steps necessary
to
>>> >> >> remove any usage of json.org dependencies from our codebase
and
>>> >> >> we're
>>> >> >> prepared to release.  The problem is that the solution meant
>>> >> >> removing
>>> >> >> an often used feature from the build and it will create user
>>> >> >> confusion
>>> >> >> and is inconsistent with our stated backward compatibility
guidance
>>> >> >> for the community.
>>> >> >>
>>> >> >> We did reach out to the dependency community, twitter4j, and
they
>>> >> >> responded right away and seem willing to work with us to resolve
so
>>> >> >> it
>>> >> >> is just a matter of time.  The grace period would allow us
to avoid
>>> >> >> impact to our users while we continue to responsibly address
the
>>> >> >> matter.
>>> >> >>
>>> >> >> There does seem to be consensus on this thread that some form
of
>>> >> >> grace
>>> >> >> period is reasonable so just looking to see if that has reached
the
>>> >> >> point of a decision.
>>> >> >>
>>> >> >> Thanks
>>> >> >> Joe
>>> >> >>
>>> >> >> On Fri, Nov 18, 2016 at 6:42 PM, Ted Dunning <ted.dunning@gmail.com>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> > Joe,
>>> >> >> >
>>> >> >> > I think that the consensus is that JSON is category X.
>>> >> >> >
>>> >> >> > Consider using the library I just built. Should result
in little
>>> >> >> > or
>>> >> >> > no
>>> >> >> > user
>>> >> >> > visible change.
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > On Fri, Nov 18, 2016 at 11:30 AM, Joe Witt <joe.witt@gmail.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> Hello,
>>> >> >> >>
>>> >> >> >> Has a decision been reached by any chance?  We're
looking to kick
>>> >> >> >> off
>>> >> >> >> the next Apache NiFi release and while we've done
the work to
>>> >> >> >> eliminate the use of this library it required us to
reduce user
>>> >> >> >> convenience in one case that we'd love to undo and
expect the
>>> >> >> >> grace
>>> >> >> >> period will resolve.
>>> >> >> >>
>>> >> >> >> Thanks
>>> >> >> >> Joe
>>> >> >> >>
>>> >> >> >> On Wed, Nov 16, 2016 at 8:50 PM, Ted Dunning
>>> >> >> >> <ted.dunning@gmail.com>
>>> >> >> >> wrote:
>>> >> >> >> >
>>> >> >> >> > I like this too, but would rather have the "next
release after
>>> >> >> >> > xxx/yyy"
>>> >> >> >> > form
>>> >> >> >> > of deadline.
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Wed, Nov 16, 2016 at 11:08 AM, Jim Jagielski
>>> >> >> >> > <jim@jagunet.com>
>>> >> >> >> > wrote:
>>> >> >> >> >>
>>> >> >> >> >> The more I think about it, the more this
makes sense.
>>> >> >> >> >> Basically
>>> >> >> >> >> we refuse the use of it for any new projects/efforts,
but
>>> >> >> >> >> those
>>> >> >> >> >> projects which are currently using it, with
no issues, should
>>> >> >> >> >> be allowed to continue using them, grandfathered,
at least for
>>> >> >> >> >> a time being.
>>> >> >> >> >>
>>> >> >> >> >> Let me mull this over some more and make
an official
>>> >> >> >> >> determination/
>>> >> >> >> >> ruling. :)
>>> >> >> >> >>
>>> >> >> >> >> > On Nov 16, 2016, at 2:22 PM, Alan Gates
>>> >> >> >> >> > <alanfgates@gmail.com>
>>> >> >> >> >> > wrote:
>>> >> >> >> >> >
>>> >> >> >> >> > The recent moving of the JSON license
to category X means
>>> >> >> >> >> > that
>>> >> >> >> >> > a
>>> >> >> >> >> > number
>>> >> >> >> >> > of projects cannot do any releases until
this is fixed.  I
>>> >> >> >> >> > know
>>> >> >> >> >> > this
>>> >> >> >> >> > includes Hadoop, Hive, and Spark, and
probably a number of
>>> >> >> >> >> > others
>>> >> >> >> >> > since
>>> >> >> >> >> > hadoop-common (which many project use)
depends on jars from
>>> >> >> >> >> > json.org.
>>> >> >> >> >> > The
>>> >> >> >> >> > Hive team in particular is trying to
get a maintenance
>>> >> >> >> >> > release
>>> >> >> >> >> > out
>>> >> >> >> >> > which is
>>> >> >> >> >> > blocked by this.
>>> >> >> >> >> >
>>> >> >> >> >> > I talked with Jim Jagielski briefly
today and he suggested
>>> >> >> >> >> > that
>>> >> >> >> >> > perhaps
>>> >> >> >> >> > we could have a grandfather clause on
this so that projects
>>> >> >> >> >> > that
>>> >> >> >> >> > already are
>>> >> >> >> >> > using it could continue to, at least
for a period of time,
>>> >> >> >> >> > so
>>> >> >> >> >> > that
>>> >> >> >> >> > they can
>>> >> >> >> >> > continue to produce releases rather
than needing to spend
>>> >> >> >> >> > unplanned
>>> >> >> >> >> > time
>>> >> >> >> >> > switching out this library[1].
>>> >> >> >> >> >
>>> >> >> >> >> > To be specific I propose we give projects
already using this
>>> >> >> >> >> > license
>>> >> >> >> >> > 6
>>> >> >> >> >> > months to clean this up in which they
can continue to
>>> >> >> >> >> > release
>>> >> >> >> >> > with
>>> >> >> >> >> > dependencies on the JSON license.
>>> >> >> >> >> >
>>> >> >> >> >> > Alan.
>>> >> >> >> >> >
>>> >> >> >> >> > 1. The amount of time to fix this will
not be trivial.
>>> >> >> >> >> > Based
>>> >> >> >> >> > on a
>>> >> >> >> >> > little bit of digging I’ve done the
alternatives are not
>>> >> >> >> >> > 100%
>>> >> >> >> >> > identical in
>>> >> >> >> >> > their behavior which will mean projects
will need to
>>> >> >> >> >> > thoroughly
>>> >> >> >> >> > test
>>> >> >> >> >> > the
>>> >> >> >> >> > replacements and change their code to
deal with the
>>> >> >> >> >> > differences.
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> >
>>> >> >> >> >> > ---------------------------------------------------------------------
>>> >> >> >> >> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> >> >> > For additional commands, e-mail:
>>> >> >> >> >> > legal-discuss-help@apache.org
>>> >> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> ---------------------------------------------------------------------
>>> >> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> ---------------------------------------------------------------------
>>> >> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> ---------------------------------------------------------------------
>>> >> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >> >>
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> >> For additional commands, e-mail: legal-discuss-help@apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Simon Lessard, Software Architect
>>> > CMA IT
>>> > ( +33(0) 6 79 37 39 85 (France)
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>>
>>
>> --
>> Simon Lessard, Software Architect
>> CMA IT
>> ( +33(0) 6 79 37 39 85 (France)

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message