Re: DISCUSS geronimo-security_1.0_spec content unclear

Yes, that's a sane approach. EPL just requires us to have it mentioned in every downstream NOTICE iiuc. From the EPL v2 [1] 3.1 If a Contributor Distributes the Program in any form, then: • a) the Program must also be made available as Source Code, in accordance with section 3.2,

Re: DISCUSS geronimo-security_1.0_spec content unclear

> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau wrote: > > No I guess it was right, "that are" ;) = fork @G only when we need to > change some impl/default provider. Right. A few things in my mind at least: - Industry health: we (Apache) are the only other implementations of Activation,

Re: DISCUSS geronimo-security_1.0_spec content unclear

> On Sep 4, 2019, at 6:04 AM, Mark Struberg wrote: > > 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

Re: DISCUSS geronimo-security_1.0_spec content unclear

We cant, only impl+api are certified so no issue ;) Le mer. 4 sept. 2019 à 17:01, Jean-Louis Monteiro a écrit : > I'd like to certify some of them if possible of course. > > Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau > a écrit : > >> Not sure I'm following Mark, EPL is fine for us ( >>

Re: DISCUSS geronimo-security_1.0_spec content unclear

I'd like to certify some of them if possible of course. Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau a écrit : > Not sure I'm following Mark, EPL is fine for us ( > https://www.apache.org/legal/resolved.html) and G spec jars are not > officially certified so don't change of license anytime.

Re: DISCUSS geronimo-security_1.0_spec content unclear

Not sure I'm following Mark, EPL is fine for us ( https://www.apache.org/legal/resolved.html) and G spec jars are not officially certified so don't change of license anytime. Romain Manni-Bucau @rmannibucau | Blog | Old Blog

Re: DISCUSS geronimo-security_1.0_spec content unclear

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 : > > @Mark: didn't change with jakarta donation? can you open a ticket on > jakartee tracker please? > > Romain Manni-Bucau > @rmannibucau

Re: DISCUSS geronimo-security_1.0_spec content unclear

@Mark: didn't change with jakarta donation? can you open a ticket on jakartee tracker please? Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github |

Re: DISCUSS geronimo-security_1.0_spec content unclear

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.

Re: DISCUSS geronimo-security_1.0_spec content unclear

exactly. Main ambiguity is for API using a provider as only impl dependency like jsonp/jsonb ( https://github.com/apache/geronimo-specs/blob/trunk/geronimo-jsonb_1.0_spec/src/main/java/javax/json/bind/spi/JsonbProvider.java#L30 ). Think it makes sense to keep it hosted to change this value even if

Re: DISCUSS geronimo-security_1.0_spec content unclear

so for instance activation and javamail would stay in Geronimo Specs and let's say @Inject would be Eclipse? -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Wed, Sep 4, 2019 at 11:11 AM Romain Manni-Bucau wrote: > No I guess it was right, "that are" ;) =

Re: DISCUSS geronimo-security_1.0_spec content unclear

No I guess it was right, "that are" ;) = fork @G only when we need to change some impl/default provider. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github

Re: DISCUSS geronimo-security_1.0_spec content unclear

> This is my current thinking as well; maintain apis that are impls, use the EPL version otherwise. I believe you meant "that are not impls ..." I'll make the changes on the javaee-api jar -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Tue, Sep 3, 2019 at

Re: DISCUSS geronimo-security_1.0_spec content unclear

> On Sep 3, 2019, at 7:20 AM, Romain Manni-Bucau wrote: > > 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 This is my current thinking as well; maintain apis that are impls, use the EPL

Re: DISCUSS geronimo-security_1.0_spec content unclear

Ok I fixed the issue. Actually the spec module was clean but the bundle configuration was not so we were badly including JASPIC dependencies. I'll open up a VOTE for it -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Tue, Sep 3, 2019 at 4:49 PM Romain

Re: DISCUSS geronimo-security_1.0_spec content unclear

go ahead Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book

Re: DISCUSS geronimo-security_1.0_spec content unclear

We can raise the issue at Jakarta Meanwhile, can I remove the jaspic api classes because they really don't have anything to do in this spec jar -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Tue, Sep 3, 2019 at 4:37 PM Romain Manni-Bucau wrote: > MP

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

Re: DISCUSS geronimo-security_1.0_spec content unclear

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

Re: DISCUSS geronimo-security_1.0_spec content unclear

Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro 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.

Re: DISCUSS geronimo-security_1.0_spec content unclear

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? It's the same license and we are using them in our MicroProfile implementations. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro

Re: DISCUSS geronimo-security_1.0_spec content unclear

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 : > > If we still can't reuse jakata artifacts (their license is ok and there is > no impl reference inside so we

Re: DISCUSS geronimo-security_1.0_spec content unclear

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