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