FYI: also started a discussion over at geronimo-dev. Ray had some good feedback.
https://lists.apache.org/thread.html/rffa51b77d13a6ab6423ed6cdf531a1483848b6965fe0c67b2263ff48%40%3Cdev.geronimo.apache.org%3E <https://lists.apache.org/thread.html/rffa51b77d13a6ab6423ed6cdf531a1483848b6965fe0c67b2263ff48@%3Cdev.geronimo.apache.org%3E> LieGrue, strub > Am 22.04.2020 um 07:30 schrieb Mark Struberg <[email protected]>: > > Hi Cesar! > > EPLv2 is basically LGPL but allows sub-licensing. > > https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o > <https://www.eclipse.org/legal/epl-2.0/faq.php#h.tokw8l7u084o> > > "that means that if you have modified EPL-2.0 licensed source code and you > distribute that code or binaries built from that code outside y. our company, > you must make the source code available under the EPL-2.0." > > See the license text for the full details: > https://www.eclipse.org/legal/epl-2.0/ > <https://www.eclipse.org/legal/epl-2.0/> > > I'd say that makes not much problems to us, but > > a.) whenever we package some binary which includes some EPLv2 artifact > (tomee.zip) we need to properly attribute this. > b.) whenever we change or repackage EPLv2 source code (javaee-api) we need to > make those parts available. > > b is not tragic for us but all DOWNSTREAM users also need to do it IF they > change the source code. > > Nothing tragic, but we need to comply to it. Probably well worth it. That's > why I started the discussion. > And of course there's the OSGi thingy... > > LieGrue, > strub > > > >> Am 21.04.2020 um 17:01 schrieb Cesar Hernandez <[email protected]>: >> >> 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] >> <mailto:[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/> < >>> 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 >>> <https://apache.org/legal/resolved.html>> >>> See section 3 in https://www.eclipse.org/legal/epl-2.0/ >>> <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. >
