geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: DISCUSS geronimo-security_1.0_spec content unclear
Date Thu, 05 Sep 2019 13:00:19 GMT
Yes, that's a sane approach.
EPL just requires us to have it mentioned in every downstream NOTICE iiuc.

From the EPL v2 [1]
----
3.1 If a Contributor Distributes the Program in any form, then:
	• a) the Program must also be made available as Source Code, in accordance with section
3.2, and the Contributor must accompany the Program with a statement that the Source Code
for the Program is available under this Agreement, and informs Recipients how to obtain it
in a reasonable manner on or through a medium customarily used for software exchange; and...
----

For TomEE we'd need to add it to our NOTICE for example, right [2]?

This is likely not a problem for TomEE, but might be something to know if some project has
a fat-jar approach. In this case this weak-copyleft semantic also spreads over to the customer
project. Not a show-stopper, but something to consider.

LieGrue,
strub

[1] https://www.eclipse.org/legal/epl-2.0/
[2] https://github.com/apache/tomee/blob/master/NOTICE


> Am 04.09.2019 um 23:51 schrieb David Blevins <david.blevins@gmail.com>:
> 
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:
>> 
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
> 
> Right.  A few things in my mind at least:
> 
> - Industry health: we (Apache) are the only other implementations of Activation, JavaMail,
JACC and similar "impl" specs.  If we give up on the impls we have, the industry collapses
down to one impl and then what is the point of a spec?
> 
> - Competitiveness: we have seen performance issues reported against our impls.  I distinctly
remember one for JACC several years ago.  Where there are issues, there are also potential
advantages.  If we can handle it, let's keep our impls and be competitive.
> 
> Where there is no actual impl I don't see any gain for the effort even if small.
> 
> - Unavoidable EPL dependence: We're not likely to write a new Java compiler any time
soon, so we're stuck with the EPL forever.
> 
> - Likelyhood of increased EPL dependence: Given it is the default choice in Jakarta,
more things will be created under it we may need.
> 
> - Decreasing helping hands: Projects at Apache are switching over to the EPL libraries,
so we will have fewer people willing to type in APIs for already-thin legal reasons.
> 
> 
> -David
> 


Mime
View raw message