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

Reply via email to