You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Mark Struberg <st...@yahoo.de.INVALID> on 2020/04/19 09:33:44 UTC
javax -> jakarta
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
Re: javax -> jakarta
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <st...@yahoo.de.INVALID>:
>
> 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 <ce...@gmail.com>:
>>
>> 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 (<struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>)
>> 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.
>
Re: javax -> jakarta
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <ce...@gmail.com>:
>
> 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 (<struberg@yahoo.de.invalid <ma...@yahoo.de.invalid>>)
> 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.
Re: javax -> jakarta
Posted by Cesar Hernandez <ce...@gmail.com>.
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 (<st...@yahoo.de.invalid>)
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.