geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: 2.0 release status
Date Mon, 06 Aug 2007 18:36:39 GMT

On Aug 6, 2007, at 11:25 AM, David Jencks wrote:

> On Aug 6, 2007, at 6:16 AM, Kevan Miller wrote:
>> Here's where things stand at the moment
>> Specs
>> We have a vote on 3 spec releases that have been held up by a CDDL  
>> licensing issue. After reviewing the issues, I don't think these  
>> specs have a problem. They are not built with CDDL licensed  
>> materials. We <could> start to rebase our specs on CDDL licensed  
>> materials. I think this would make things cleaner. However, I  
>> don't think that it is necessary to do that now.
> It would also make it so we couldn't release them according to  the  
> draft 3rd party licensing policy at 
> ~cliffs/3party.html which prohibits cddl source code in apache  
> releases ("Categoy B).  Sam has indicated that xsds are source code  
> in his opinion and I certainly agree.

I also agree that they are source code.

According to the draft 3rd party licensing policy, you are correct. I  
used to treat that very literally.

However, we have also gotten a clear advice from Sam Ruby, a member  
and current chair of the ASF legal team, that the use of CDDL schemas  
is ok. In fact, Sam has instructed all projects to replace Sun  
Proprietary/confidential dtd's and xsd's with their CDDL equivalent.

As long as the Geronimo PMC agrees and we follow the rules of the  
CDDL license, I don't see a problem. I think we're better off.

>> Schemas
>> We have an outstanding vote on two schema releases. These releases  
>> are built from CDDL licensed materials.
> I believe the copies under vote are NOT built from CDDL but from  
> the previous non-cddl xsds.  I guess only Prasad knows for sure.

I believe you are correct. I got ahead of myself.

>> At the moment, the license and notice files for the schema  
>> releases are not correct.
> I think they are correct , since the jars are not built from cddl  
> sources.  In any case I think that (in disagreement to Craig  
> Russell) that even if we started with CDDL schemas the xmlbeans  
> generated source and binary would be under asf, not cddl.  If not,  
> then the xmlbeans code we've been using generated from the pre-cddl  
> schemas would be under the mysterious sun license that prohibits  
> all use, so we wouldn't be able to write a javaee server in the  
> first place.

I'm going to skip this for now. We can come back to it, if you still  
feel we should not move to CDDL licensed schemas.

>> I think we should do the following: move the schema source  
>> directories from our tck svn repository to our public repository,  
>> fix our license and notice files, and build schema releases from  
>> there. Note that both the schema source directories and the  
>> resultant schema binaries will have CDDL licensed elements. The  
>> current guidance that we have received from legal-discuss is that  
>> both source and binary CDDL is ok for us to release. We will need  
>> to be sure that our schemas follow all CDDL requirements.
> I don't think we should do this until the violent disagreement  
> between the 3rd party licensing policy and sam's suggestion that  
> it's ok to use the cddl xsds is resolved.

I don't think there's a violent disagreement. I think Sam's opinion  
on the matter carries a lot of weight and also makes a lot of sense.

There was some discussion about whether or not schemas are source or  
binary. Seems we both agree they are source. So, let's assume they  
are source and treat them accordingly.

There is also some discussion about whether xmlbeans or jaxb  
generated code would inherit a CDDL license. This may be debatable.  
Best case the code is ASL. Worst case it's ASL+CDDL or even just  
CDDL. IMO, we can deal just fine with all of those cases. So, let's  
make our best call on the appropriate license for the schema jars.

IMO, we end up in a better situation. In particular, we move our  
schema code out of tck svn -- this seems like a very, very good thing  
to me. Other than the overhead of moving some code, building new  
release candidates, and minor mods to license/notice files, I don't  
see a downside...


View raw message