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 08:52:48 GMT
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?

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.

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

Please, let's do this properly.


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