> On Aug 14, 2019, at 2:05 AM, Alex The Rocker <alex.m3...@gmail.com> wrote: > > 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" ?
I pulled down the official text here and did a quick reformat to match it to the LICENSE.md - https://www.eclipse.org/org/documents/edl-v10.php Sans the copyright statement, both came out identical in a diff, so we appear good. We will want to make sure our NOTICE file does contain the copyright statement, so that is a definitely good catch. -David > 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 >>>>> >>>> >>
