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 Tue, 22 Nov 2016 09:48:47 GMT
On 22 November 2016 at 09:07, Ted Dunning <ted.dunning@gmail.com> wrote:
>
>
> 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.

Yes, but every project that uses the new jar will need to consider patching.

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

The solution to my claim of jar hell explained how to fix it in a
particular project.
I only realised last night that of course it would have to be done by
every affected project.

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

Do you mean that jars will never diverge?
Or that it does not matter?

The Java classpath only allows a single copy of each class on the same
classpath.
So if the two jars have different versions of the same class, only one
of the classes can be present.
So if component A needs the old jar version and component B expects
the new jar version, at least one of them will be disappointed.

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

I contend that it is not safe to do this.
At best the solution is unnecessarily fragile.

Interim solutions have a way of becoming permanent, or at least longer
lived than you intended and anticipated.

> See for instance the twitter4j case. Likewise the Hive case
> (possibly with the addition of a little shade).

I'm not disputing that the solution should work now.
I am saying that it is ill-advised.

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

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


Mime
View raw message