www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: A grace period for getting rid of JSON license jars
Date Tue, 22 Nov 2016 09:07:34 GMT
On Tue, Nov 22, 2016 at 12:52 AM, sebb <sebbaz@gmail.com> wrote:

> There has been a suggestion that jar hell can be avoided by patching the
> poms.
> I can see how that could work for an individual case, but do we really
> want to release a jar that *requires* the poms to be patched?
>

I think that the patching is at the Apache project level.


> Every time a 3rd party project uses an ASF project containing this
> replacement jar they will potentially have to patch their poms.
> That does not seem sensible.
>

I didn't hear that.

You are right that doesn't seem super sensible.


> Furthermore, if the jars ever diverge, no amount of pom patching will
> solve the issue.
>

I don't agree with this.


> Please, let's do this properly.
>

Fine. The right way to do this is to move to Jackson.  But that will take
longer.

I merely offer an interim solution that can be used safely in some
situations.  See for instance the twitter4j case. Likewise the Hive case
(possibly with the addition of a little shade).



On 21 November 2016 at 21:12, Ted Dunning <ted.dunning@gmail.com> wrote:
> >
> > On Mon, Nov 21, 2016 at 11:01 AM, sebb <sebbaz@gmail.com> wrote:
> >>
> >> > This preference is equivalent to "unable or unwilling to make proper
> >> > Apache
> >> > releases".
> >>
> >> I did not mean ASF projects.
> >> I was thinking about 3rd party code that is used by ASF code.
> >
> >
> > So far, we don't have any examples of this. The only source code
> dependency
> > in a dependency case so far is twitter4j and it was easily dealt with and
> > the community is receptive.
> >
> > Projects which depend on the org.json version of the code in a
> non-optional
> > way where those projects will not change to fix the problem will become
> > unusable by ASF code. The ASF projects that use these dependencies will
> > become unreleasable unless they make some sort of change.
> >
> > That would suck.  No doubt.  No argument about that.
> >
> > But that situation is still theoretical. We have no examples of this.
> >
> > Let's work the problem as it exists right now.
> >
> >
> >>
> >>
> >> > The JSON license is unacceptable. It puts ill-defined constraints on
> the
> >> > downstream users. It isn't open source. It can't be a dependency for a
> >> > proper Apache release.
> >> >
> >> > The library I have created is one way around the problem, but it is
> >> > definitely not a long-term solution.
> >>
> >> The problem is, once it has been released, it's going to be difficult
> >> to un-release it...
> >
> >
> > I don't plan to un-release it. But I do plan to help projects move away
> from
> > depending on my library. The best departure direction is probably
> jackson.
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>

Mime
View raw message