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 <[email protected]>:
>
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau <[email protected]> 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
>
