geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Monteiro <jlmonte...@tomitribe.com>
Subject Re: DISCUSS geronimo-security_1.0_spec content unclear
Date Wed, 04 Sep 2019 15:01:09 GMT
I'd like to certify some of them if possible of course.

Le mer. 4 sept. 2019 à 15:33, Romain Manni-Bucau <rmannibucau@gmail.com> 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.
>
> 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:07, Mark Struberg <struberg@yahoo.de> a écrit :
>
> > 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 <
> rmannibucau@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 <struberg@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 <
> > rmannibucau@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 <
> > >> jlmonteiro@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 <
> > rmannibucau@gmail.com>
> > >> wrote:
> > >>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
> > >> jlmonteiro@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
> > <struberg@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 <
> > >>>>> rmannibucau@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 <
> > >>>>> jlmonteiro@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
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>
> > >>
> >
> >
>

Mime
View raw message