Okay; for EDL I see it's compatible with Apache licensing, but
strangely, JAXB license does not look like an EDL:
https://github.com/eclipse-ee4j/jaxb-api/blob/2.3.2/LICENSE.md

Am I mistaking or this is actually "cheesy" ?

Kind regads,
Alexandre

Le mer. 14 août 2019 à 10:37, David Blevins <dblev...@tomitribe.com> a écrit :
>
> > On Aug 14, 2019, at 1:23 AM, Alex The Rocker <alex.m3...@gmail.com> wrote:
> >
> > Hello,
> >
> > How about JAXB which is not EPL but EDL 1.0 ?
> > (see https://github.com/eclipse-ee4j/jaxb-api/tree/2.3.2)
>
> EDL is an approved license.  Here's the complete naughty and nice list as it 
> where :)
>
>  - https://apache.org/legal/resolved.html
>
> The interesting thing about jaxb-api is there is only one implementation in 
> the world and it is also EDL and no longer included in the JVM.  If we typed 
> in the API, 98% of the other JAXB code we ship would still be EDL.
>
>
> -David
>
> > Le mer. 14 août 2019 à 10:16, David Blevins <david.blev...@gmail.com> a 
> > écrit :
> >>
> >> This is really the better thread to talk about how to handle the gaps in 
> >> our Java EE 8 APIs and support.
> >>
> >> As noted, there is not license victory to be won.  We have had EPL and 
> >> CDDL dependencies since v1.0 in 2011.
> >>
> >> From a Geronimo perspective, we typed in the APIs and created all those 
> >> spec jars because there were no open source options that weren't the JBoss 
> >> GPL versions.  GlassFish didn't exist yet.  When GlassFish came about, we 
> >> kept up the practice largely out of habit.  We did have an unavoidable 
> >> CDDL via the xml schemas and JAXB RI, so our licensing victory wasn't 
> >> quite there.
> >>
> >> This is really a resources and timeline issue.
> >>
> >> Some of these specs are actually implementations, specifically:
> >>
> >> - JavaMail 1.6
> >> - JACC 1.6
> >> - Activation 1.2
> >>
> >> If we decide we want the Geronimo versions to be upgraded (implemented) 
> >> and this is important for TomEE 8, we should expect that to ship sometime 
> >> 2020.
> >>
> >>
> >> --
> >> David Blevins
> >> http://twitter.com/dblevins
> >> http://www.tomitribe.com
> >>
> >>> On Aug 13, 2019, at 12:10 AM, David Blevins <david.blev...@gmail.com> 
> >>> wrote:
> >>>
> >>> I did a small gap-analysis of where we're still short on Java EE 8 APIs 
> >>> from the perspective of our javaee-api jar:
> >>>
> >>> - https://issues.apache.org/jira/browse/TOMEE-2620
> >>>
> >>> Specific callouts are these APIs are also implementations, so switching 
> >>> to the equivalent Jakarta version also gains a compliant implementation:
> >>>
> >>> - javax.activation 1.1 vs 1.2
> >>> - javax.security.jacc 1.4 vs 1.6
> >>> - javax.mail 1.5 vs 1.6
> >>>
> >>> This one is a flaw in my reporting, it's included in Tomcat:
> >>>
> >>> - javax.security.auth.message 1.0 vs 1.1 (JASPIC)
> >>>
> >>> We should likely use the exact version cxf requires of this:
> >>>
> >>> - javax.xml.ws 2.2 vs 2.3 (JAX-WS)
> >>>
> >>> These we will likely not be able to change as the corresponding 
> >>> implementations aren't there:
> >>>
> >>> - javax.enterprise.concurrent 1.0 vs 1.1
> >>> - javax.resource 1.6 vs 1.7
> >>> - javax.transaction 1.2 vs 1.3 (JTA)
> >>>
> >>> If we ship TomEE 8.0 with just those three lagging APIs, that would be 
> >>> pretty good.  Shipping a final with 8 lagging libraries, less fantastic.
> >>>
> >>> What do people think about the potential upgrades?
> >>>
> >>>
> >>> --
> >>> David Blevins
> >>> http://twitter.com/dblevins
> >>> http://www.tomitribe.com
> >>>
> >>
>

Reply via email to