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 11:16:24 GMT
*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)



*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


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


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

Mime
View raw message