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 > >> >> > >> > >>
