No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB LieGrue, strub
> Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > @Mark: didn't change with jakarta donation? can you open a ticket on > jakartee tracker please? > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mer. 4 sept. 2019 à 15:04, Mark Struberg <strub...@yahoo.de> a écrit : > >> No, this is an intended situation. >> When one fully passes the TCK then you get the EFSL. This 'removes' the >> copyleft nature of the EPL. >> The details are quite nested in the legal papers, but that's it basically. >> >> If we just upgrade our existing API to be binary compat then we have no IP >> issues. >> >> LieGrue, >> strub >> >> >>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau <rmannibu...@gmail.com >>> : >>> >>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity >> for us. >>> That said it is good to reuse the same GAV for end users so we might ask >> jakarta to double license its api jars? >>> >>> Romain Manni-Bucau >>> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book >>> >>> >>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro < >> jlmonte...@tomitribe.com> a écrit : >>> Yep that was the point. >>> So I was asking if we should do the same yes or not. >>> >>> That seems to be your opinion Romain. >>> Mark on the other end is having some doubts about the license. >>> -- >>> Jean-Louis Monteiro >>> http://twitter.com/jlouismonteiro >>> http://www.tomitribe.com >>> >>> >>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro < >> jlmonte...@tomitribe.com> >>> a écrit : >>> >>>> Thanks Romain. I'm fine with using Eclipse jars if from a legal point >> of >>>> view, it works. >>>> Otherwise, I'd like to split our spec jars. >>>> >>>> What about MicroProfile? >>>> >>> >>> We already agreed to not redo the API and use microprofile jars. >>> >>> >>>> It's the same license and we are using them in our MicroProfile >>>> implementations. >>>> -- >>>> Jean-Louis Monteiro >>>> http://twitter.com/jlouismonteiro >>>> http://www.tomitribe.com >>>> >>>> >>>> On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg <strub...@yahoo.de.invalid >>> >>>> wrote: >>>> >>>>> depends what their license is. EPL is (weak) copyleft. Thus I would >> like >>>>> to avoid exposing it downstream as api. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>>> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau < >>>>> rmannibu...@gmail.com>: >>>>>> >>>>>> If we still can't reuse jakata artifacts (their license is ok and >> there >>>>> is >>>>>> no impl reference inside so we should just use them, right?) it >> sounds >>>>>> natural >>>>>> >>>>>> Romain Manni-Bucau >>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>> <http://rmannibucau.wordpress.com> | Github < >>>>> https://github.com/rmannibucau> | >>>>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book >>>>>> < >>>>> >> https://www.packtpub.com/application-development/java-ee-8-high-performance >>>>>> >>>>>> >>>>>> >>>>>> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro < >>>>> jlmonte...@tomitribe.com> >>>>>> a écrit : >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I was digging into some other specifications and see what would >> pass >>>>>>> Jakarta TCK and realized that geronimo-security_1.0_spec content >>>>> actually >>>>>>> mixes 2 specifications. >>>>>>> >>>>>>> https://github.com/eclipse-ee4j/security-api >>>>>>> >>>>>>> and >>>>>>> >>>>>>> https://github.com/eclipse-ee4j/jaspic >>>>>>> >>>>>>> I thought the initial intent was to create a specific artifact per >>>>>>> specification. >>>>>>> Mixing them is a bit annoying from a certification perspective. >>>>>>> It's also not clean because in Tomcat for instance, there is >> already >>>>>>> jaspic API so it becomes a duplicate. >>>>>>> >>>>>>> Would it be possible to split them up in 2 artifacts? >>>>>>> >>>>>>> -- >>>>>>> Jean-Louis Monteiro >>>>>>> http://twitter.com/jlouismonteiro >>>>>>> http://www.tomitribe.com >>>>>>> >>>>> >>>>> >> >>