www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Fwd: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Date Fri, 03 Aug 2007 19:33:10 GMT
accidently sent this to Stefano only...

Begin forwarded message:

> From: David Jencks <david_jencks@yahoo.com>
> Date: August 3, 2007 10:02:20 AM PDT
> To: Stefano Bagnara <apache@bago.org>
> Subject: Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
> On Aug 3, 2007, at 9:27 AM, Stefano Bagnara wrote:
>> David Jencks ha scritto:
>>> On Aug 3, 2007, at 2:03 AM, Stefano Bagnara wrote:
>>> <giant snip>
>>>> I didn't follow the full thread, but if CDDL licensed files  
>>>> exists for
>>>> this dtd I would include them *as* *is* (cddl header): I share the
>>>> interpretation that a dtd file that is not to be used as source to
>>>> generate a binary can be considered a binary wrt the CDDL and ALv2
>>>> licenses.
>>> I see this "it's a binary" point of view being expressed fairly  
>>> often.
>>> IMO this is a questionable point of view.
>> Let's take the CDDL: CDDL defines "Source Code" at 1.12 and  
>> "Executable"
>> in 1.4. Everything depends on how we read that 2 definitions.
>> 1.4. “Executable” means the Covered Software in any form other than
>> Source Code.
>> 1.12. “Source Code” means (a) the common form of computer software  
>> code
>> in which modifications are made and (b) associated documentation
>> included in or with such code.
>> Can you tell us (using your interpretation) what is the Source  
>> Code and
>> what is the Executable of this xsd files?
>> Can you also point to the CDDL point that you think prevents ASF from
>> redistributing that (SUN copyrighted, CDDL licensed) XSD files  
>> inside an
>> ASF product?
> I don't have an opinion on what _is_ source code or executable with  
> regards to xsds, and I don't see a problem with including either  
> cddl licensed schemas or code generated from them in asf products.   
> However, it looks to me as if some of the arguments to allow  
> inclusion of such xsds are based on them being "Executable" and I'd  
> like to make sure that anyone making such an argument is aware that  
> in many cases these schemas need to be compiled into java code to  
> be useful.  I'm hoping that whatever policy the asf comes up with  
> allows that.
> I don't think distinguishing between hand written DOM/STAX/SAX  
> based translation code, rule driven translation code (tomcat/ 
> digester), xmlbeans generated translation code (geronimo), and hand  
> modified jaxb generated java classes with the jaxb runtime  
> (openejb) is particularly meaningful and I'm hoping the eventual  
> policy doesn't draw a line separating these uses.
> thanks
> david jencks
>> Stefano
>>> There are at least 2 commonly used technologies that appear to treat
>>> schemas as source files and compile them into binaries (with the  
>>> help of
>>> the java compiler);
>>> xmlbeans (asl licensed)
>>> jaxb (some kind of sun license, I think CDDL)
>>> These both compile schemas into java classes and provide mapping  
>>> code of
>>> some sort.  It's really silly to try to build a javaee product  
>>> without
>>> using one of these (or a similar product).  In particular  
>>> geronimo uses
>>> xmlbeans and openejb uses jaxb for this purpose.  Furthermore any  
>>> javaee
>>> product is going to need some kind of java object representation  
>>> of the
>>> information in the deployment descriptors corresponding to the  
>>> schemas
>>> under discussion, and some code to transfer the information from  
>>> these
>>> dds to the java objects.  What's the difference between  
>>> automatically
>>> generated/compiled code and hand written code (using say DOM or  
>>> SAX or
>>> STAX?) that transfer information from a document complying with  
>>> one of
>>> these schemas to a java object designed to contain the same  
>>> information?
>>> thanks
>>> david jencks
>> ---------------------------------------------------------------------
>> DISCLAIMER: Discussions on this list are informational and  
>> educational
>> only.  Statements made on this list are not privileged, do not
>> constitute legal advice, and do not necessarily reflect the opinions
>> and policies of the ASF.  See <http://www.apache.org/licenses/> for
>> official ASF policies and documents.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org

View raw message