www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Lessard <simon.lessar...@gmail.com>
Subject Re: A grace period for getting rid of JSON license jars
Date Mon, 21 Nov 2016 10:52:33 GMT
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)
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


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

Mime
View raw message