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 17:06:13 GMT
I have an alternative solution that I hope avoids most of the issues:

Release the new jar under a unique Java package name owned by the
publisher (i.e. not org.json).

Projects that wish to use it can change POM and imports to use the new jar.
For dependencies that cannot be changed, create a shaded copy of the
jar using the org.json package names.

It seems wrong to deliberately release a competing jar using someone
else's Java package, even if it is just 'temporary'.


On 22 November 2016 at 16:43, Ted Dunning <ted.dunning@gmail.com> wrote:
>
>
>
> On Tue, Nov 22, 2016 at 1:48 AM, sebb <sebbaz@gmail.com> wrote:
>>
>>
>> >> 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.
>
>
> The basic alternatives are:
>
> 1) pom level manipulations, possibly including shading but definitely
> including changing the reference to be to a different pom. This can handle
> the cases of direct use of the problem package and transitive use via
> dependencies. As you say, this leaks changes in the org.json component to
> the downstream user of the Apache project (but that can be limited in extent
> and effect using shading).
>
> or
>
> 2) pom AND code manipulations. At the least, this would include changing
> dependencies and imports. And it doesn't actually help with the case of
> dependencies which use the problematic package. In the ideal case, it
> involves changing the way that JSON is handled by moving to something like
> Jackson, but this change must include all dependencies.
>
>
> Note that continuing to use the json.org artifacts as currently licensed is
> NOT an option. That is what is really causing the real sand in the gears.
> Our only choices now are to choose which palliative measures we take in
> removing that dependency.  Some such measures can be done quickly and others
> will take longer.
>
>>
>> >>
>> >> 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.
>
>
> The only effect on downstream users will be that they may have to import the
> original json.org jar (if we shade) or they may have access to a more
> restrictive set of capabilities than before (if we don't).
>
>>
>> >> 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?
>
>
> That it doesn't matter. Apache projects should move away from dependency on
> json.org's artifacts or simulacra of same such as what I have released. If
> they don't move away, that means that they are happy with what they got and
> changes to something that they aren't using shouldn't have much effect.
>
>>
>>
>> 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.
>
>
> Indeed.  Thus shading.
>
>>
>>
>> >>
>> >> 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.
>
>
> Isn't this choice up to the projects? I don't see why legal-discuss is the
> proper venue for technical decisions.
>
> If you have alternative approaches, that is great. Release something or
> patch a project as a demo. All I have done is propose one alternative. It
> has costs, limitations and defects, as do all approaches.
>
> I should point out that the code I have packaged so far is, ahem, open
> source. Please feel free to provide a patch. Or fork it to provide an
> alternative.
>
>>
>>
>> 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.
>
>
> Not our decision here.
>
> We trust projects to make their own technical decisions.
>
> The only decision that is out of bounds here is to continue use of
> json.org's artifacts.
>
>

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


Mime
View raw message