Hi Mark,

I'm didn't notice the licensing aspect you mention on b).
What would be the work need it, for example in java-ee-api, to add the
reciprocity you are mentioning?
Just a license header change?

El dom., 19 abr. 2020 a las 3:34, Mark Struberg (<[email protected]>)
escribió:

> Hi folks!
>
> While moving over to jakartaee we need to discuss which specs we want to
> include in our maven builds.
>
> We have a jakarta.* branch for the geronimo specs since a year.
> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ <
> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/>
> In fact, this was the first ever attempt whether moving the packages was
> possible at all.
>
> The other possible option would be to use the now existing official
> packages from eclipse.
> There are a few issues with those though.
>
> a.) they are not OSGi capable. Not a bit deal for most, but there are
> projects like karaf, Camel, etc which make use of OSGi.
> I have not checked whether Eclipse has plans to add this feature to their
> official artifacts. Anyone?
>
> b.) The EPLv2 is a weak copyleft license. So it still requires some
> reciprocity. ALv2 does not.
> https://apache.org/legal/resolved.html <
> https://apache.org/legal/resolved.html>
> See section 3 in https://www.eclipse.org/legal/epl-2.0/
> I think this would be fine as long as we make sure not to modify it. Our
> java-ee-api super-jar might be such a case.
>
> c.) Software Maintenance
> With maintaining our own versions of the specs we can rather quickly test
> out new features currently under discussion. This would be harder if we do
> not maintain those sources ourselves.
> Of course this also has downsides: we _need_ to maintain it and we need to
> make sure it finally is binary compatible. Checking signatures and stuff...
>
> For the record: Apache Tomcat still maintains all the apis for themselves
> as well:
> https://github.com/apache/tomcat/tree/master/java/jakarta



-- 
Atentamente:
César Hernández.

Reply via email to