You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Henri Yandell <ba...@apache.org> on 2007/07/31 17:56:25 UTC
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
On 5/21/07, Kevan Miller <ke...@gmail.com> wrote:
> I raised a similar issue on the Tomcat dev list some months back.
> Tomcat contains Sun xsd's and dtd's (e.g. http://svn.apache.org/repos/
> asf/tomcat/trunk/java/javax/servlet/resources/j2ee_1_4.xsd) which are
> Sun copyright and contain the following restrictions of use:
>
> This document and the technology which it describes are
> distributed under licenses restricting their use, copying,
> distribution, and decompilation. No part of this document
> may be reproduced in any form by any means without prior
> written authorization of Sun and its licensors, if any.
>
> I was told that there might be documents in the Foundation svn
> repository that grant Apache the right to redistribute these files.
> I've never seen these documents, despite requesting the information
> from Tomcat. Nor do I know how any rights granted by Sun to Apache
> might transfer to a third party...
Anyone have more info on this one?
http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr154/src/share/dtd/web-app_2_4.xsd
is an example of a file with both Apache permissive licensing, and a
Sun extremely unpermissive header. It's come up in Freemarker as an
issue:
http://sourceforge.net/tracker/index.php?func=detail&aid=1754236&group_id=794&atid=100794
Hen
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@apache.org>.
On 8/2/07, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wednesday 01 August 2007 15:02, Santiago Gala wrote:
> > I'm not really sure what we are trying to achieve here, but a file
> > committed by a Sun employee, that has signed a CLA, while working under
> > Sun direction, etc. *is licensed under AL 2.0*
>
> Indeed, and it is a matter of either 'mistake' (which we all
> hope), 'ignorance' (which wouldn't be good) or 'malicious' (which some might
> fear)...
Let it go. Humans are falable in many ways. It is the job of the PMC
to exercise oversight in these matters. If the PMC wasn't doing it's
job properly in the past, it is certainly doing so now, as evidenced
by these discussions.
On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> 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.
Bah. I had taken the action item, and had hopes that I could task
this to Doug, just to find out that he is going on vacation just as
this heats up. The nerve of some people.
I believe that the definition of the term 'source' is too clear and
widely understood for us to ever consider XSD files anything other
than source. That being said, I do believe that ASF policies should
handle distribution of sources which are in intended to be directly
processed in their original source form the same way that it handle
binaries.
Until we resolve this, I do believe that MyFaces and any other
projects with similar issues should proceed forthwith with replacing
any and all SUN PROPRIETARY/CONFIDENTIAL with what Cliff's "3party"
document calls Class A or Class B licensed material, with the
understanding that we may need to revisit this once the policy is
finalized.
- Sam Ruby
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 01 August 2007 15:02, Santiago Gala wrote:
> I'm not really sure what we are trying to achieve here, but a file
> committed by a Sun employee, that has signed a CLA, while working under
> Sun direction, etc. *is licensed under AL 2.0*
Indeed, and it is a matter of either 'mistake' (which we all
hope), 'ignorance' (which wouldn't be good) or 'malicious' (which some might
fear)...
Cheers
Niclas
---------------------------------------------------------------------
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
RE: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Janet Campbell <ja...@eclipse.org>.
Apologies for coming late to this thread. There is interest in using
myfaces within Eclipse and we are currently completing our due diligence on
the code base. The project has said that they will not be updating the DTD
files to reflect the CDDL license and I believe they understand that to be
what they should do based on this discussion [1]. I haven't been able to
locate a final resolution on that part of the discussion. Could someone
clarify for me?
[1]
http://users.myfaces.markmail.org/search/?q=#query:+page:9+mid:hbl3jra5x57w4
hi6+state:results
Janet
-----Original Message-----
From: Kevan Miller [mailto:kevan.miller@gmail.com]
Sent: Friday, August 10, 2007 9:55 AM
To: Craig L Russell
Cc: Sam Ruby; David Jencks; ASF Legal Discuss; Geronimo Dev List (JIRA)
Subject: Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
On Aug 10, 2007, at 12:52 AM, Craig L Russell wrote:
> On Aug 9, 2007, at 6:50 PM, Sam Ruby wrote:
>
>> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>>
>>> I'm a bit confused though about the inclusion of cddl xsds in apache
>>> svn since IIUC you have indicated xsds are definitely "source
>>> code" (I completely agree) and the draft 3rd party licensing page
>>> says cddl source can't be in apache releases. It doesn't say
>>> whether
>>> a few files can be in svn or not AFAICT but that certainly looks
>>> like
>>> it would prohibit shipping an asf jar with any cddl xsds in it.
>>
>> I've updated the draft 3rd party licensing page:
>>
>> http://people.apache.org/~rubys/3party.html
>
> +1
>
> Thanks for the update, Sam!
Agreed. Also, thanks for the timely and informative responses. They
were very helpful in deciding how to move forward on this matter.
>
> IIUC, Geronimo makes two uses of the CDDL-licensed xsd files.
>
> 1. The unmodified xsd files are available to the xml parser to
> avoid downloading the files from the internet during operation.
>
> 2. The unmodified xsd files are "compiled" into Java classes which
> are then compiled into binary form for execution.
>
> The new policy seems to address both cases, assuming that Geronimo
> chooses to update their copies of the files to the CDDL-licensed
> versions.
Just to be precise, Geronimo does not currently use CDDL-licensed
schema files. Moving to the CDDL-licensed versions of these schema
files is, IMO, the right thing to do. I intend to start this next week.
There's still the question of how the CDDL license extends to the
resultant binaries. Something for next week, I guess...
--kevan
---------------------------------------------------------------------
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
RE: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Janet Campbell <ja...@eclipse.org>.
Apologies for coming late to this thread. There is interest in using
myfaces within Eclipse and we are currently completing our due diligence on
the code base. The project has said that they will not be updating the DTD
files to reflect the CDDL license and I believe they understand that to be
what they should do based on this discussion [1]. I haven't been able to
locate a final resolution on that part of the discussion. Could someone
clarify for me?
[1]
http://users.myfaces.markmail.org/search/?q=#query:+page:9+mid:hbl3jra5x57w4
hi6+state:results
Janet
-----Original Message-----
From: Kevan Miller [mailto:kevan.miller@gmail.com]
Sent: Friday, August 10, 2007 9:55 AM
To: Craig L Russell
Cc: Sam Ruby; David Jencks; ASF Legal Discuss; Geronimo Dev List (JIRA)
Subject: Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
On Aug 10, 2007, at 12:52 AM, Craig L Russell wrote:
> On Aug 9, 2007, at 6:50 PM, Sam Ruby wrote:
>
>> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>>
>>> I'm a bit confused though about the inclusion of cddl xsds in apache
>>> svn since IIUC you have indicated xsds are definitely "source
>>> code" (I completely agree) and the draft 3rd party licensing page
>>> says cddl source can't be in apache releases. It doesn't say
>>> whether
>>> a few files can be in svn or not AFAICT but that certainly looks
>>> like
>>> it would prohibit shipping an asf jar with any cddl xsds in it.
>>
>> I've updated the draft 3rd party licensing page:
>>
>> http://people.apache.org/~rubys/3party.html
>
> +1
>
> Thanks for the update, Sam!
Agreed. Also, thanks for the timely and informative responses. They
were very helpful in deciding how to move forward on this matter.
>
> IIUC, Geronimo makes two uses of the CDDL-licensed xsd files.
>
> 1. The unmodified xsd files are available to the xml parser to
> avoid downloading the files from the internet during operation.
>
> 2. The unmodified xsd files are "compiled" into Java classes which
> are then compiled into binary form for execution.
>
> The new policy seems to address both cases, assuming that Geronimo
> chooses to update their copies of the files to the CDDL-licensed
> versions.
Just to be precise, Geronimo does not currently use CDDL-licensed
schema files. Moving to the CDDL-licensed versions of these schema
files is, IMO, the right thing to do. I intend to start this next week.
There's still the question of how the CDDL license extends to the
resultant binaries. Something for next week, I guess...
--kevan
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 10, 2007, at 12:52 AM, Craig L Russell wrote:
> On Aug 9, 2007, at 6:50 PM, Sam Ruby wrote:
>
>> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>>
>>> I'm a bit confused though about the inclusion of cddl xsds in apache
>>> svn since IIUC you have indicated xsds are definitely "source
>>> code" (I completely agree) and the draft 3rd party licensing page
>>> says cddl source can't be in apache releases. It doesn't say
>>> whether
>>> a few files can be in svn or not AFAICT but that certainly looks
>>> like
>>> it would prohibit shipping an asf jar with any cddl xsds in it.
>>
>> I've updated the draft 3rd party licensing page:
>>
>> http://people.apache.org/~rubys/3party.html
>
> +1
>
> Thanks for the update, Sam!
Agreed. Also, thanks for the timely and informative responses. They
were very helpful in deciding how to move forward on this matter.
>
> IIUC, Geronimo makes two uses of the CDDL-licensed xsd files.
>
> 1. The unmodified xsd files are available to the xml parser to
> avoid downloading the files from the internet during operation.
>
> 2. The unmodified xsd files are "compiled" into Java classes which
> are then compiled into binary form for execution.
>
> The new policy seems to address both cases, assuming that Geronimo
> chooses to update their copies of the files to the CDDL-licensed
> versions.
Just to be precise, Geronimo does not currently use CDDL-licensed
schema files. Moving to the CDDL-licensed versions of these schema
files is, IMO, the right thing to do. I intend to start this next week.
There's still the question of how the CDDL license extends to the
resultant binaries. Something for next week, I guess...
--kevan
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 10, 2007, at 12:52 AM, Craig L Russell wrote:
> On Aug 9, 2007, at 6:50 PM, Sam Ruby wrote:
>
>> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>>
>>> I'm a bit confused though about the inclusion of cddl xsds in apache
>>> svn since IIUC you have indicated xsds are definitely "source
>>> code" (I completely agree) and the draft 3rd party licensing page
>>> says cddl source can't be in apache releases. It doesn't say
>>> whether
>>> a few files can be in svn or not AFAICT but that certainly looks
>>> like
>>> it would prohibit shipping an asf jar with any cddl xsds in it.
>>
>> I've updated the draft 3rd party licensing page:
>>
>> http://people.apache.org/~rubys/3party.html
>
> +1
>
> Thanks for the update, Sam!
Agreed. Also, thanks for the timely and informative responses. They
were very helpful in deciding how to move forward on this matter.
>
> IIUC, Geronimo makes two uses of the CDDL-licensed xsd files.
>
> 1. The unmodified xsd files are available to the xml parser to
> avoid downloading the files from the internet during operation.
>
> 2. The unmodified xsd files are "compiled" into Java classes which
> are then compiled into binary form for execution.
>
> The new policy seems to address both cases, assuming that Geronimo
> chooses to update their copies of the files to the CDDL-licensed
> versions.
Just to be precise, Geronimo does not currently use CDDL-licensed
schema files. Moving to the CDDL-licensed versions of these schema
files is, IMO, the right thing to do. I intend to start this next week.
There's still the question of how the CDDL license extends to the
resultant binaries. Something for next week, I guess...
--kevan
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 9, 2007, at 6:50 PM, Sam Ruby wrote:
> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>
>> I'm a bit confused though about the inclusion of cddl xsds in apache
>> svn since IIUC you have indicated xsds are definitely "source
>> code" (I completely agree) and the draft 3rd party licensing page
>> says cddl source can't be in apache releases. It doesn't say whether
>> a few files can be in svn or not AFAICT but that certainly looks like
>> it would prohibit shipping an asf jar with any cddl xsds in it.
>
> I've updated the draft 3rd party licensing page:
>
> http://people.apache.org/~rubys/3party.html
+1
Thanks for the update, Sam!
IIUC, Geronimo makes two uses of the CDDL-licensed xsd files.
1. The unmodified xsd files are available to the xml parser to avoid
downloading the files from the internet during operation.
2. The unmodified xsd files are "compiled" into Java classes which
are then compiled into binary form for execution.
The new policy seems to address both cases, assuming that Geronimo
chooses to update their copies of the files to the CDDL-licensed
versions.
> The longer term intent is to revise the document to say something
> along the lines of "Category A is always OK",
> "Category C is never
You mean Category X I assume...
Craig
P.S. One more note: I've been unable to get a timely response from
the Java SE folks regarding licensing of the two remaining dtd files.
Hopefully there will be a reply shortly...
> http://java.sun.com/dtd/properties.dtd
> http://java.sun.com/dtd/preferences.dtd
> OK", and "Category B is up to the PMC, with the following
> guidance...".
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> 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
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 9, 2007, at 6:50 PM, Sam Ruby wrote:
> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>
>> I'm a bit confused though about the inclusion of cddl xsds in apache
>> svn since IIUC you have indicated xsds are definitely "source
>> code" (I completely agree) and the draft 3rd party licensing page
>> says cddl source can't be in apache releases. It doesn't say whether
>> a few files can be in svn or not AFAICT but that certainly looks like
>> it would prohibit shipping an asf jar with any cddl xsds in it.
>
> I've updated the draft 3rd party licensing page:
>
> http://people.apache.org/~rubys/3party.html
+1
Thanks for the update, Sam!
IIUC, Geronimo makes two uses of the CDDL-licensed xsd files.
1. The unmodified xsd files are available to the xml parser to avoid
downloading the files from the internet during operation.
2. The unmodified xsd files are "compiled" into Java classes which
are then compiled into binary form for execution.
The new policy seems to address both cases, assuming that Geronimo
chooses to update their copies of the files to the CDDL-licensed
versions.
> The longer term intent is to revise the document to say something
> along the lines of "Category A is always OK",
> "Category C is never
You mean Category X I assume...
Craig
P.S. One more note: I've been unable to get a timely response from
the Java SE folks regarding licensing of the two remaining dtd files.
Hopefully there will be a reply shortly...
> http://java.sun.com/dtd/properties.dtd
> http://java.sun.com/dtd/preferences.dtd
> OK", and "Category B is up to the PMC, with the following
> guidance...".
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> 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
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@intertwingly.net>.
On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>
> I'm a bit confused though about the inclusion of cddl xsds in apache
> svn since IIUC you have indicated xsds are definitely "source
> code" (I completely agree) and the draft 3rd party licensing page
> says cddl source can't be in apache releases. It doesn't say whether
> a few files can be in svn or not AFAICT but that certainly looks like
> it would prohibit shipping an asf jar with any cddl xsds in it.
I've updated the draft 3rd party licensing page:
http://people.apache.org/~rubys/3party.html
The longer term intent is to revise the document to say something
along the lines of "Category A is always OK", "Category C is never
OK", and "Category B is up to the PMC, with the following
guidance...".
- Sam Ruby
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
On Aug 4, 2007, at 12:50 PM, Sam Ruby wrote:
> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>
>> As I see it there are two kinds of questions I'm asking:
>>
>> 1. Are the 6 questionable jars (4 I already mentioned plus a servlet
>> spec jar with some retyped sun xsds and dtds) OK to release?
>> Obviously the geronimo PMC thought so but this conversation has
>> thrown that into doubt as far as I am concerned. Is there some
>> information you (or anyone else) would like in order to give an
>> opinion? I tried to explain the process used to generate these jars
>> and the thinking behind the process already. Note that none of these
>> jars start from the cddl licensed sun schemas, they all start from or
>> relate to the pre-cddl schemas. I don't see these questions as being
>> hypothetical, and I hope 6 jars isn't a dump truck. The servlet spec
>> jar under vote is at http://people.apache.org/~mcconne/geronimo-
>> servlet_2.5_spec-1.1.tar.gz. The vote passed but AFAICT it has not
>> yet been called or the artifact actually released.
>
> Legally, yes.
>
> Now onto the next question. Have you documented this in a way that
> users of Geronimo codebase are aware of the composition of the
> package? Given the answer below, I'll presume no; so let's move onto
> the next problem. After we are done we can come back to this one.
Note that the jars under discussion all relate to the pre-cddl
licensed xsds, so I don't think the hypothetical questions following
(2) are relevant to these particular jars.
The jars containing source and compiled xmlbeans generated jars
include the standard ASL1 license and notice files. To the best of
our knowledge they dont contain any text such as comments from the
sun schemas (we recently discovered that the binary files generated
by xmlbeans by default contain the comments from the source and took
steps to configure xmlbeans to leave them out). I guess we could
include a comment explaining how we got them, but if the asl2
licensing is really correct I don't exactly see why that would be
required.
The servlet spec jar contains the standard apache license and notice
files and the hand-typed schemas start out similar to this:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed
with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License,
Version 2.0
(the "License"); you may not use this file except in compliance
with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://java.sun.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.5">
<!--
** This is the Web Application 2.5 XSD with only the
required elements to support an implementation.
** Please see http://java.sun.com/xml/ns/javaee/web-
app_2_5.xsd for a fully documented and latest
** XSD.
-->
If these files are legally OK, I can't see why we would need any
other notice. If they are not legally OK, then we need to change
them and figure out what kind of notice is appropriate. Our position
has been that the stripped down xsds are required to implement a
compliant javaee product, which we have a license to do, so the sun
legalese must be talking about the text bits that aren't needed and
we left out.
That's the state of the non-cddl-questions about the current
stuff ... onto the hypothetical future.
>
>> 2. Hypothetically, starting from the cddl licensed schemas, what can
>> we generate from them, what can we include in apache svn and
>> releases, and what license is any of this under? The geronimo pmc
>> has previously thought that generated source was under asl. Craig is
>> claiming that generated source is cddl, however as I tried to explain
>> this point of view seems to me to lead to the entire server being
>> required to be cddl. In other words I think either Craig is wrong or
>> apache can't develop any javaee products. In addition I think
>> Craig's argument applied to the pre-cddl xsds would entirely prevent
>> apache releasing any j2ee or javaee products whatsoever.
>
> So, the entire server is generated from these XSDs? Sweet! Must be
> one kick ass generator. :-)
>
> Let's assume for the moment that Craig is correct (I believe that
> section 3.5(*) of the license contradicts this interpretation). Even
> assuming that, how do you the leap from generated artifacts being CDDL
> to entire server?
The only way I can make sense of Craig's argument is that the CDDL
applies to the information content of the schemas, not any particular
representation of that information content. As such any compliant
implementation has to include that information content throughout a
large part of its core functionality, so most of the source files are
going to need to be cddl licensed since they are going to contains
bits of that information content. If anyone thinks this isn't what
Craig's argument means, please explain how to draw the line between
cddl and non-cddl in the 5 examples I presented earlier.
>
>> Following onto 2, sometimes there are mistakes in the sun schemas
>> that, well, prevent using them directly in completely compliant
>> implementations. For instance the web-app-2.5.xsd had a incorrect
>> regular expression for http-method. Assuming we eventually do use
>> the cddl licensed schemas, and these are in publicly accessible
>> apache svn, can we fix these errors?
>
> Legally, as long as you comply with the CDDL license (in particular,
> note sections 3.1 and 3.3(*)), yes.
>
> Now as to ASF policy; in general ASF SVN repositories are for the
> development of code under the Apache License. I don't believe a few
> files that are clearly marked would substantially change the fact that
> the Geronimo SVN meets that criteria. If you do proceed to do this,
> mention it in the next regularly scheduled board report and move on.
I think the latest sun web-app schema has actually fixed this mistake
so we will burn this bridge when we come to it in the future.
I'm a bit confused though about the inclusion of cddl xsds in apache
svn since IIUC you have indicated xsds are definitely "source
code" (I completely agree) and the draft 3rd party licensing page
says cddl source can't be in apache releases. It doesn't say whether
a few files can be in svn or not AFAICT but that certainly looks like
it would prohibit shipping an asf jar with any cddl xsds in it.
thanks
david jencks
>
> - Sam Ruby
>
> (*) http://www.sun.com/cddl/cddl.html
>
> ---------------------------------------------------------------------
> 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
>
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
On Aug 4, 2007, at 12:50 PM, Sam Ruby wrote:
> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>
>> As I see it there are two kinds of questions I'm asking:
>>
>> 1. Are the 6 questionable jars (4 I already mentioned plus a servlet
>> spec jar with some retyped sun xsds and dtds) OK to release?
>> Obviously the geronimo PMC thought so but this conversation has
>> thrown that into doubt as far as I am concerned. Is there some
>> information you (or anyone else) would like in order to give an
>> opinion? I tried to explain the process used to generate these jars
>> and the thinking behind the process already. Note that none of these
>> jars start from the cddl licensed sun schemas, they all start from or
>> relate to the pre-cddl schemas. I don't see these questions as being
>> hypothetical, and I hope 6 jars isn't a dump truck. The servlet spec
>> jar under vote is at http://people.apache.org/~mcconne/geronimo-
>> servlet_2.5_spec-1.1.tar.gz. The vote passed but AFAICT it has not
>> yet been called or the artifact actually released.
>
> Legally, yes.
>
> Now onto the next question. Have you documented this in a way that
> users of Geronimo codebase are aware of the composition of the
> package? Given the answer below, I'll presume no; so let's move onto
> the next problem. After we are done we can come back to this one.
Note that the jars under discussion all relate to the pre-cddl
licensed xsds, so I don't think the hypothetical questions following
(2) are relevant to these particular jars.
The jars containing source and compiled xmlbeans generated jars
include the standard ASL1 license and notice files. To the best of
our knowledge they dont contain any text such as comments from the
sun schemas (we recently discovered that the binary files generated
by xmlbeans by default contain the comments from the source and took
steps to configure xmlbeans to leave them out). I guess we could
include a comment explaining how we got them, but if the asl2
licensing is really correct I don't exactly see why that would be
required.
The servlet spec jar contains the standard apache license and notice
files and the hand-typed schemas start out similar to this:
<?xml version="1.0" encoding="UTF-8"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed
with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License,
Version 2.0
(the "License"); you may not use this file except in compliance
with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://java.sun.com/xml/ns/javaee"
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified" version="2.5">
<!--
** This is the Web Application 2.5 XSD with only the
required elements to support an implementation.
** Please see http://java.sun.com/xml/ns/javaee/web-
app_2_5.xsd for a fully documented and latest
** XSD.
-->
If these files are legally OK, I can't see why we would need any
other notice. If they are not legally OK, then we need to change
them and figure out what kind of notice is appropriate. Our position
has been that the stripped down xsds are required to implement a
compliant javaee product, which we have a license to do, so the sun
legalese must be talking about the text bits that aren't needed and
we left out.
That's the state of the non-cddl-questions about the current
stuff ... onto the hypothetical future.
>
>> 2. Hypothetically, starting from the cddl licensed schemas, what can
>> we generate from them, what can we include in apache svn and
>> releases, and what license is any of this under? The geronimo pmc
>> has previously thought that generated source was under asl. Craig is
>> claiming that generated source is cddl, however as I tried to explain
>> this point of view seems to me to lead to the entire server being
>> required to be cddl. In other words I think either Craig is wrong or
>> apache can't develop any javaee products. In addition I think
>> Craig's argument applied to the pre-cddl xsds would entirely prevent
>> apache releasing any j2ee or javaee products whatsoever.
>
> So, the entire server is generated from these XSDs? Sweet! Must be
> one kick ass generator. :-)
>
> Let's assume for the moment that Craig is correct (I believe that
> section 3.5(*) of the license contradicts this interpretation). Even
> assuming that, how do you the leap from generated artifacts being CDDL
> to entire server?
The only way I can make sense of Craig's argument is that the CDDL
applies to the information content of the schemas, not any particular
representation of that information content. As such any compliant
implementation has to include that information content throughout a
large part of its core functionality, so most of the source files are
going to need to be cddl licensed since they are going to contains
bits of that information content. If anyone thinks this isn't what
Craig's argument means, please explain how to draw the line between
cddl and non-cddl in the 5 examples I presented earlier.
>
>> Following onto 2, sometimes there are mistakes in the sun schemas
>> that, well, prevent using them directly in completely compliant
>> implementations. For instance the web-app-2.5.xsd had a incorrect
>> regular expression for http-method. Assuming we eventually do use
>> the cddl licensed schemas, and these are in publicly accessible
>> apache svn, can we fix these errors?
>
> Legally, as long as you comply with the CDDL license (in particular,
> note sections 3.1 and 3.3(*)), yes.
>
> Now as to ASF policy; in general ASF SVN repositories are for the
> development of code under the Apache License. I don't believe a few
> files that are clearly marked would substantially change the fact that
> the Geronimo SVN meets that criteria. If you do proceed to do this,
> mention it in the next regularly scheduled board report and move on.
I think the latest sun web-app schema has actually fixed this mistake
so we will burn this bridge when we come to it in the future.
I'm a bit confused though about the inclusion of cddl xsds in apache
svn since IIUC you have indicated xsds are definitely "source
code" (I completely agree) and the draft 3rd party licensing page
says cddl source can't be in apache releases. It doesn't say whether
a few files can be in svn or not AFAICT but that certainly looks like
it would prohibit shipping an asf jar with any cddl xsds in it.
thanks
david jencks
>
> - Sam Ruby
>
> (*) http://www.sun.com/cddl/cddl.html
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@apache.org>.
On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>
> As I see it there are two kinds of questions I'm asking:
>
> 1. Are the 6 questionable jars (4 I already mentioned plus a servlet
> spec jar with some retyped sun xsds and dtds) OK to release?
> Obviously the geronimo PMC thought so but this conversation has
> thrown that into doubt as far as I am concerned. Is there some
> information you (or anyone else) would like in order to give an
> opinion? I tried to explain the process used to generate these jars
> and the thinking behind the process already. Note that none of these
> jars start from the cddl licensed sun schemas, they all start from or
> relate to the pre-cddl schemas. I don't see these questions as being
> hypothetical, and I hope 6 jars isn't a dump truck. The servlet spec
> jar under vote is at http://people.apache.org/~mcconne/geronimo-
> servlet_2.5_spec-1.1.tar.gz. The vote passed but AFAICT it has not
> yet been called or the artifact actually released.
Legally, yes.
Now onto the next question. Have you documented this in a way that
users of Geronimo codebase are aware of the composition of the
package? Given the answer below, I'll presume no; so let's move onto
the next problem. After we are done we can come back to this one.
> 2. Hypothetically, starting from the cddl licensed schemas, what can
> we generate from them, what can we include in apache svn and
> releases, and what license is any of this under? The geronimo pmc
> has previously thought that generated source was under asl. Craig is
> claiming that generated source is cddl, however as I tried to explain
> this point of view seems to me to lead to the entire server being
> required to be cddl. In other words I think either Craig is wrong or
> apache can't develop any javaee products. In addition I think
> Craig's argument applied to the pre-cddl xsds would entirely prevent
> apache releasing any j2ee or javaee products whatsoever.
So, the entire server is generated from these XSDs? Sweet! Must be
one kick ass generator. :-)
Let's assume for the moment that Craig is correct (I believe that
section 3.5(*) of the license contradicts this interpretation). Even
assuming that, how do you the leap from generated artifacts being CDDL
to entire server?
> Following onto 2, sometimes there are mistakes in the sun schemas
> that, well, prevent using them directly in completely compliant
> implementations. For instance the web-app-2.5.xsd had a incorrect
> regular expression for http-method. Assuming we eventually do use
> the cddl licensed schemas, and these are in publicly accessible
> apache svn, can we fix these errors?
Legally, as long as you comply with the CDDL license (in particular,
note sections 3.1 and 3.3(*)), yes.
Now as to ASF policy; in general ASF SVN repositories are for the
development of code under the Apache License. I don't believe a few
files that are clearly marked would substantially change the fact that
the Geronimo SVN meets that criteria. If you do proceed to do this,
mention it in the next regularly scheduled board report and move on.
- Sam Ruby
(*) http://www.sun.com/cddl/cddl.html
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@apache.org>.
On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>
> As I see it there are two kinds of questions I'm asking:
>
> 1. Are the 6 questionable jars (4 I already mentioned plus a servlet
> spec jar with some retyped sun xsds and dtds) OK to release?
> Obviously the geronimo PMC thought so but this conversation has
> thrown that into doubt as far as I am concerned. Is there some
> information you (or anyone else) would like in order to give an
> opinion? I tried to explain the process used to generate these jars
> and the thinking behind the process already. Note that none of these
> jars start from the cddl licensed sun schemas, they all start from or
> relate to the pre-cddl schemas. I don't see these questions as being
> hypothetical, and I hope 6 jars isn't a dump truck. The servlet spec
> jar under vote is at http://people.apache.org/~mcconne/geronimo-
> servlet_2.5_spec-1.1.tar.gz. The vote passed but AFAICT it has not
> yet been called or the artifact actually released.
Legally, yes.
Now onto the next question. Have you documented this in a way that
users of Geronimo codebase are aware of the composition of the
package? Given the answer below, I'll presume no; so let's move onto
the next problem. After we are done we can come back to this one.
> 2. Hypothetically, starting from the cddl licensed schemas, what can
> we generate from them, what can we include in apache svn and
> releases, and what license is any of this under? The geronimo pmc
> has previously thought that generated source was under asl. Craig is
> claiming that generated source is cddl, however as I tried to explain
> this point of view seems to me to lead to the entire server being
> required to be cddl. In other words I think either Craig is wrong or
> apache can't develop any javaee products. In addition I think
> Craig's argument applied to the pre-cddl xsds would entirely prevent
> apache releasing any j2ee or javaee products whatsoever.
So, the entire server is generated from these XSDs? Sweet! Must be
one kick ass generator. :-)
Let's assume for the moment that Craig is correct (I believe that
section 3.5(*) of the license contradicts this interpretation). Even
assuming that, how do you the leap from generated artifacts being CDDL
to entire server?
> Following onto 2, sometimes there are mistakes in the sun schemas
> that, well, prevent using them directly in completely compliant
> implementations. For instance the web-app-2.5.xsd had a incorrect
> regular expression for http-method. Assuming we eventually do use
> the cddl licensed schemas, and these are in publicly accessible
> apache svn, can we fix these errors?
Legally, as long as you comply with the CDDL license (in particular,
note sections 3.1 and 3.3(*)), yes.
Now as to ASF policy; in general ASF SVN repositories are for the
development of code under the Apache License. I don't believe a few
files that are clearly marked would substantially change the fact that
the Geronimo SVN meets that criteria. If you do proceed to do this,
mention it in the next regularly scheduled board report and move on.
- Sam Ruby
(*) http://www.sun.com/cddl/cddl.html
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
Let me first point out that I'm not acting in any official Sun
capacity here. I'm just an Apache guy with an opinion but with no
legal training.
On Aug 5, 2007, at 12:14 AM, David Jencks wrote:
>
> On Aug 4, 2007, at 2:55 PM, Craig L Russell wrote:
>>
>> On Aug 4, 2007, at 12:15 PM, David Jencks wrote:
>>
>>> 2. Hypothetically, starting from the cddl licensed schemas, what
>>> can we generate from them, what can we include in apache svn and
>>> releases, and what license is any of this under? The geronimo
>>> pmc has previously thought that generated source was under asl.
>>
>> If you can clarify what you mean by "generated source" I can
>> respond to this. Seems to be an oxymoron. You were earlier talking
>> about some Java files that were generated by an xml-to-java tool.
>> Are these what you mean by "generated source"?
>
> Starting from one or more schemas, xmlbeans can generate a bunch
> of .java java source files. Similarly jaxb can, starting with one
> or more schemas, generate a bunch of .java java source files. In
> particular, as I would have thought was clear from all the
> discussion, I was thinking of the source jars geronimo was voting
> on that contain java source generated by xmlbeans from the pre-cddl
> sun schemas.
Ok, thanks for clarifying that. I was confused because we had been
talking about xml and xsd files as if they were source and I just
wanted to make sure we were talking about the same thing.
So regarding the generated source files. If these were created from
files with a clear license, then the license terms of the original
files whence the generated sources were generated would apply. In the
case of CDDL, there is a section 3 governing distribution
requirements. (Among other things, these require that the original,
CDDL-licensed version be available in source form with its original
CDDL license).
>
> IMO it can't possibly matter how these files were arrived at: if we
> have a license to implement a javaee spec,
So there is a license for you to implement a JCP spec. That would be
the specification license, which I haven't heard discussed here as
the rationale for shipping code. If the code referenced the
specification license, I'd be ok with it. But a specification license
is not ALv2 the last time I read both, side by side.
> and that spec has an xsd that describes information needed to
> implement the spec, then our implementation must contain code that
> stores that same information as is described by the spec, and must
> contain code that translates the information from a valid document
> per the spec into the data structures defined by the code.
>
> We get to license all that under asl,
I don't follow this leap. I hear you claiming that anything you copy
from a JCP specification can be licensed under ALv2 and I just don't
see anything in the spec license that would permit that. The spec
licenses from Sun have evolved so we would have to look at the
license under which the specifications were released to see if they
contain sub-licensing clauses. One I'm looking at right now contains
language restricting sub-licensing [1].
What I thought was a step in the right direction was to get Sun to
license the required specification code under a more permissive
license than the specification license, and that's why I thought that
the CDDL license would be a good thing.
> no matter how we create the code, whether its apache committers
> writing it after deep analysis, xmlbeans, jaxb, or a bunch of
> monkeys with typewriters.
I do make the distinction between copying files from a distribution
versus deep analysis, hand-coded Java classes, or monkeys at a
typewriter. Of course with the monkey technology you might spend a
lot of time looking through their failed efforts to find files that
passed the tck.
You might claim "fair use" to excerpt parts of the specification for
your own work, but I still fail to see how it is proper to copy files
byte-for-byte without attribution.
>
> If you disagree with this point of view, I'd like to know how
> apache could have a pre-cddl j2ee server and how it could now have
> a non-cddl javaee server. I've asked this quite a few times now
> with no response. Am I being that unclear?
Well, I wasn't around when the original Geronimo licensing
arrangements were being negotiated, so I don't know how the decision
was arrived at to license the xsd and dtd files under an ALv2. But
Apache is all about provenance of code, and to me it's clear that
copying code and not attributing it properly is not ok.
Bottom line,
Regards,
Craig
>
> thanks
> david jencks
[1] Excerpt from a specification license used at least once by Sun
License for the Distribution of Compliant Implementations. Sun also
grants
you a perpetual, non-exclusive, non-transferable, worldwide, fully
paid-up,
royalty free, limited license (without the right to sublicense) under
any
applicable copyrights or, subject to the provisions of subsection 4
below,
patent rights it may have covering the Specification to create and/or
distribute
an Independent Implementation of the Specification that: (a) fully
implements
the Specification including all its required interfaces and
functionality; (b)
does not modify, subset, superset or otherwise extend the Licensor
Name Space,
or include any public or protected packages, classes, Java
interfaces, fields or
methods within the Licensor Name Space other than those required/
authorized by
the Specification or Specifications being implemented; and (c) passes
the
Technology Compatibility Kit (including satisfying the requirements
of the
applicable TCK Users Guide) for such Specification ("Compliant
Implementation").
In addition, the foregoing license is expressly conditioned on your
not acting
outside its scope. No license is granted hereunder for any other purpose
(including, for example, modifying the Specification, other than to
the extent
of your fair use rights, or distributing the Specification to third
parties).
Craig Russell
DB PMC, OpenJPA PMC
clr@apache.org http://db.apache.org/jdo
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 4, 2007, at 12:15 PM, David Jencks wrote:
> 2. Hypothetically, starting from the cddl licensed schemas, what
> can we generate from them, what can we include in apache svn and
> releases, and what license is any of this under? The geronimo pmc
> has previously thought that generated source was under asl.
If you can clarify what you mean by "generated source" I can respond
to this. Seems to be an oxymoron. You were earlier talking about some
Java files that were generated by an xml-to-java tool. Are these what
you mean by "generated source"?
Craig Russell
DB PMC, OpenJPA PMC
clr@apache.org http://db.apache.org/jdo
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 4, 2007, at 12:15 PM, David Jencks wrote:
> 2. Hypothetically, starting from the cddl licensed schemas, what
> can we generate from them, what can we include in apache svn and
> releases, and what license is any of this under? The geronimo pmc
> has previously thought that generated source was under asl.
If you can clarify what you mean by "generated source" I can respond
to this. Seems to be an oxymoron. You were earlier talking about some
Java files that were generated by an xml-to-java tool. Are these what
you mean by "generated source"?
Craig Russell
DB PMC, OpenJPA PMC
clr@apache.org http://db.apache.org/jdo
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
On Aug 4, 2007, at 4:23 AM, Sam Ruby wrote:
> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>
>> BTW, the theory under which we (geronimo) has been operating is that
>> the sun copyright and legal statements apply to the text
>> documentation in the schemas and that once that is removed the rest
>> forms a part of the javaee specifications that we have a license to
>> implement, so we can translate it by any means we want (such as
>> xmlbeans, jaxb, castor, etc etc) to produce source code or class
>> files or pretty much anything else. I don't see how it's possible to
>> implement the specification without this: IMO without this
>> interpretation any javaee product must be cddl.
>
> I acknowledge that there was a time critical question in the portions
> that I snipped, but first I think that it is important that we come to
> a common understanding of what the problem is. Given that there are
> lawyers on this list, I'm sure that somebody will point out the
> thousands of tiny mistakes that I'm about to make, but I'm confident
> that I have the broad brush strokes right, so here goes...
>
> In order for us to legally distribute some Work, we must comply with
> all the terms and conditions in the licenses that contribute to that
> work. That's it. End of sentence.
>
> Presuming that we do that, do we have the right to distribute code
> under the CDDL? Yes, absolutely. Are there any terms or conditions
> in CDDL that we would find overly burdensome to *us* (the ones
> releasing the software)? Absolutely not.
>
> Furthermore, we even have the rights to distribute the version of XSDs
> that SUN PROPRIETARY/CONFIDENTIAL, even though Sun labeling it so
> brings into doubt what their true intentions were in licensing this
> materials, which makes our ability to demonstrate that we have
> complied with their intentions harder. Note that I said harder, I
> didn't say impossible. We have ample documentation to demonstrate
> that the ASF has the right to ship these XSDs, but who wants to have
> to go and explain all this time and time again, potentially to each
> and every new user of Geronimo?
>
> Back to CDDL. I have no personal knowledge as to why Sun picked this
> particular license, but let's look at it in context. Each of the XSDs
> in question represents a machine readable codification of a portion of
> a standard. As a standard means that you and I do something the same
> way, any modification means that you and I are doing something
> different, so it isn't a standard. So, effectively, we are taking
> these sources in and agreeing not to modify them, which makes them not
> open source. If you think we have heartburn on CDDL, think about the
> idea of the ASF shipping code that contains portions that are not open
> source.
>
> But, we are not about to say that standards are not a good thing. To
> the contrary.
>
> This is all absurd. You can see the source. You can change it, as
> long as you don't claim compatibility. Now, with CDDL, that is
> explicit. Yea!
>
> So, what's the problem here?
>
> The problem isn't with Sun. The problem is with the ASF. The ASF is
> about community (how we develop software) and license (what we permit
> users of our code to do).
>
> Our license is part of who we are. Others may distribute things under
> different licenses, and that, in part, defines who they are.
>
> Our license intentionally allows users to modify, sublicense, and
> distribute our code. All of it. If people want to contribute back
> their changes to us, they can join our communities. If people want to
> release their changes under their own license, they can do that too.
> If people want to retain their changes and only distribute binaries,
> that's OK too.
>
> Most of our code bases make it easy for our users. Everything comes
> under one license. A license that it relatively short, and well
> understood.
>
> Geronimo isn't one of those code bases. It contains many parts from
> many sources. In releasing Geronimo, we need to make sure that all of
> this is crystal clear. The bulk is under the ASF license, and people
> are free to modify that bulk as they see fit. Some portions are
> packaged with the distribution as a convenience (or in the case of
> these XSDs, as a necessity), but none of these subcomponents impose
> any additional restrictions on what you can do with the code that we
> produce, and all of it is clearly labeled.
>
> In particular, (and I may just be misreading your statement), it is
> NOT the case that "any javaee product must BE cddl", but rather "any
> javaee product must CONTAIN cddl" (actually, those files can be
> licensed under other licenses, but lets not digress).
>
> So... what is the ASF legal committee and the Geronimo PMC to do?
> Well, again, legally, Geronomo has the right to make releases as long
> as those releases comply with the appropriate licenses, so one could
> make the case that everything from that point on is up to the Geronimo
> PMC. And, in fact, this stuff is complicated enough that how you make
> the determination as to what makes sense in any particular situation
> depends very much on the situation, so again, it is Geronimo's
> problem.
>
> On the other hand, given that this stuff is complicated, it makes
> sense for us to pool our knowledge. Have a central place where
> projects can go to (and contribute back to) where general guidelines
> are captured and interesting special cases are referenced.
>
> Things like "yes, the license for foo.dtd requires people to provide
> source with any changes that they distribute, but project P only uses
> the dtd in a way that consumes the source itself directly at runtime,
> so that requirement doesn't apply in our situation", and "the license
> for bar.xsd requires that people provide source with any changes that
> they make, and we want to make this crystal clear to people. Since
> bar.xsd doesn't change very often, we compile it into .class (or .jar)
> files, and check that into SVN, along with instructions on where to
> find the original sources".
>
> I've rambled for long enough now... so let me close with this: let's
> suppose somebody gets this wrong (it happens). A bug report comes in.
> Where do you think such a bug report would be routed? To the board?
> To the legal committee? To Geronimo? If you guess the third, you
> would be right.
>
> How can I help? Well, for starters, I don't want to spend any of my
> time answering any time critical hypotheticals. Nor do I want
> somebody to back up a dump truck, and say "here's Geronimo, you figure
> it out". But if there are specific questions that we can jointly work
> through, I am here to help.
>
> If this makes sense, we can go back to your specific question(s). If
> not, let's see if we can come to a common understanding of the context
> before we proceed.
>
> Fair enough?
I hope so.
I think we've successfully derailed releasing any of the questionable
geronimo artifacts, so except for the geronimo community wanting to
get out our last years work the time critical element is gone.
As I see it there are two kinds of questions I'm asking:
1. Are the 6 questionable jars (4 I already mentioned plus a servlet
spec jar with some retyped sun xsds and dtds) OK to release?
Obviously the geronimo PMC thought so but this conversation has
thrown that into doubt as far as I am concerned. Is there some
information you (or anyone else) would like in order to give an
opinion? I tried to explain the process used to generate these jars
and the thinking behind the process already. Note that none of these
jars start from the cddl licensed sun schemas, they all start from or
relate to the pre-cddl schemas. I don't see these questions as being
hypothetical, and I hope 6 jars isn't a dump truck. The servlet spec
jar under vote is at http://people.apache.org/~mcconne/geronimo-
servlet_2.5_spec-1.1.tar.gz. The vote passed but AFAICT it has not
yet been called or the artifact actually released.
2. Hypothetically, starting from the cddl licensed schemas, what can
we generate from them, what can we include in apache svn and
releases, and what license is any of this under? The geronimo pmc
has previously thought that generated source was under asl. Craig is
claiming that generated source is cddl, however as I tried to explain
this point of view seems to me to lead to the entire server being
required to be cddl. In other words I think either Craig is wrong or
apache can't develop any javaee products. In addition I think
Craig's argument applied to the pre-cddl xsds would entirely prevent
apache releasing any j2ee or javaee products whatsoever.
Following onto 2, sometimes there are mistakes in the sun schemas
that, well, prevent using them directly in completely compliant
implementations. For instance the web-app-2.5.xsd had a incorrect
regular expression for http-method. Assuming we eventually do use
the cddl licensed schemas, and these are in publicly accessible
apache svn, can we fix these errors?
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
On Aug 4, 2007, at 4:23 AM, Sam Ruby wrote:
> On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>>
>> BTW, the theory under which we (geronimo) has been operating is that
>> the sun copyright and legal statements apply to the text
>> documentation in the schemas and that once that is removed the rest
>> forms a part of the javaee specifications that we have a license to
>> implement, so we can translate it by any means we want (such as
>> xmlbeans, jaxb, castor, etc etc) to produce source code or class
>> files or pretty much anything else. I don't see how it's possible to
>> implement the specification without this: IMO without this
>> interpretation any javaee product must be cddl.
>
> I acknowledge that there was a time critical question in the portions
> that I snipped, but first I think that it is important that we come to
> a common understanding of what the problem is. Given that there are
> lawyers on this list, I'm sure that somebody will point out the
> thousands of tiny mistakes that I'm about to make, but I'm confident
> that I have the broad brush strokes right, so here goes...
>
> In order for us to legally distribute some Work, we must comply with
> all the terms and conditions in the licenses that contribute to that
> work. That's it. End of sentence.
>
> Presuming that we do that, do we have the right to distribute code
> under the CDDL? Yes, absolutely. Are there any terms or conditions
> in CDDL that we would find overly burdensome to *us* (the ones
> releasing the software)? Absolutely not.
>
> Furthermore, we even have the rights to distribute the version of XSDs
> that SUN PROPRIETARY/CONFIDENTIAL, even though Sun labeling it so
> brings into doubt what their true intentions were in licensing this
> materials, which makes our ability to demonstrate that we have
> complied with their intentions harder. Note that I said harder, I
> didn't say impossible. We have ample documentation to demonstrate
> that the ASF has the right to ship these XSDs, but who wants to have
> to go and explain all this time and time again, potentially to each
> and every new user of Geronimo?
>
> Back to CDDL. I have no personal knowledge as to why Sun picked this
> particular license, but let's look at it in context. Each of the XSDs
> in question represents a machine readable codification of a portion of
> a standard. As a standard means that you and I do something the same
> way, any modification means that you and I are doing something
> different, so it isn't a standard. So, effectively, we are taking
> these sources in and agreeing not to modify them, which makes them not
> open source. If you think we have heartburn on CDDL, think about the
> idea of the ASF shipping code that contains portions that are not open
> source.
>
> But, we are not about to say that standards are not a good thing. To
> the contrary.
>
> This is all absurd. You can see the source. You can change it, as
> long as you don't claim compatibility. Now, with CDDL, that is
> explicit. Yea!
>
> So, what's the problem here?
>
> The problem isn't with Sun. The problem is with the ASF. The ASF is
> about community (how we develop software) and license (what we permit
> users of our code to do).
>
> Our license is part of who we are. Others may distribute things under
> different licenses, and that, in part, defines who they are.
>
> Our license intentionally allows users to modify, sublicense, and
> distribute our code. All of it. If people want to contribute back
> their changes to us, they can join our communities. If people want to
> release their changes under their own license, they can do that too.
> If people want to retain their changes and only distribute binaries,
> that's OK too.
>
> Most of our code bases make it easy for our users. Everything comes
> under one license. A license that it relatively short, and well
> understood.
>
> Geronimo isn't one of those code bases. It contains many parts from
> many sources. In releasing Geronimo, we need to make sure that all of
> this is crystal clear. The bulk is under the ASF license, and people
> are free to modify that bulk as they see fit. Some portions are
> packaged with the distribution as a convenience (or in the case of
> these XSDs, as a necessity), but none of these subcomponents impose
> any additional restrictions on what you can do with the code that we
> produce, and all of it is clearly labeled.
>
> In particular, (and I may just be misreading your statement), it is
> NOT the case that "any javaee product must BE cddl", but rather "any
> javaee product must CONTAIN cddl" (actually, those files can be
> licensed under other licenses, but lets not digress).
>
> So... what is the ASF legal committee and the Geronimo PMC to do?
> Well, again, legally, Geronomo has the right to make releases as long
> as those releases comply with the appropriate licenses, so one could
> make the case that everything from that point on is up to the Geronimo
> PMC. And, in fact, this stuff is complicated enough that how you make
> the determination as to what makes sense in any particular situation
> depends very much on the situation, so again, it is Geronimo's
> problem.
>
> On the other hand, given that this stuff is complicated, it makes
> sense for us to pool our knowledge. Have a central place where
> projects can go to (and contribute back to) where general guidelines
> are captured and interesting special cases are referenced.
>
> Things like "yes, the license for foo.dtd requires people to provide
> source with any changes that they distribute, but project P only uses
> the dtd in a way that consumes the source itself directly at runtime,
> so that requirement doesn't apply in our situation", and "the license
> for bar.xsd requires that people provide source with any changes that
> they make, and we want to make this crystal clear to people. Since
> bar.xsd doesn't change very often, we compile it into .class (or .jar)
> files, and check that into SVN, along with instructions on where to
> find the original sources".
>
> I've rambled for long enough now... so let me close with this: let's
> suppose somebody gets this wrong (it happens). A bug report comes in.
> Where do you think such a bug report would be routed? To the board?
> To the legal committee? To Geronimo? If you guess the third, you
> would be right.
>
> How can I help? Well, for starters, I don't want to spend any of my
> time answering any time critical hypotheticals. Nor do I want
> somebody to back up a dump truck, and say "here's Geronimo, you figure
> it out". But if there are specific questions that we can jointly work
> through, I am here to help.
>
> If this makes sense, we can go back to your specific question(s). If
> not, let's see if we can come to a common understanding of the context
> before we proceed.
>
> Fair enough?
I hope so.
I think we've successfully derailed releasing any of the questionable
geronimo artifacts, so except for the geronimo community wanting to
get out our last years work the time critical element is gone.
As I see it there are two kinds of questions I'm asking:
1. Are the 6 questionable jars (4 I already mentioned plus a servlet
spec jar with some retyped sun xsds and dtds) OK to release?
Obviously the geronimo PMC thought so but this conversation has
thrown that into doubt as far as I am concerned. Is there some
information you (or anyone else) would like in order to give an
opinion? I tried to explain the process used to generate these jars
and the thinking behind the process already. Note that none of these
jars start from the cddl licensed sun schemas, they all start from or
relate to the pre-cddl schemas. I don't see these questions as being
hypothetical, and I hope 6 jars isn't a dump truck. The servlet spec
jar under vote is at http://people.apache.org/~mcconne/geronimo-
servlet_2.5_spec-1.1.tar.gz. The vote passed but AFAICT it has not
yet been called or the artifact actually released.
2. Hypothetically, starting from the cddl licensed schemas, what can
we generate from them, what can we include in apache svn and
releases, and what license is any of this under? The geronimo pmc
has previously thought that generated source was under asl. Craig is
claiming that generated source is cddl, however as I tried to explain
this point of view seems to me to lead to the entire server being
required to be cddl. In other words I think either Craig is wrong or
apache can't develop any javaee products. In addition I think
Craig's argument applied to the pre-cddl xsds would entirely prevent
apache releasing any j2ee or javaee products whatsoever.
Following onto 2, sometimes there are mistakes in the sun schemas
that, well, prevent using them directly in completely compliant
implementations. For instance the web-app-2.5.xsd had a incorrect
regular expression for http-method. Assuming we eventually do use
the cddl licensed schemas, and these are in publicly accessible
apache svn, can we fix these errors?
thanks
david jencks
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@apache.org>.
On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>
> BTW, the theory under which we (geronimo) has been operating is that
> the sun copyright and legal statements apply to the text
> documentation in the schemas and that once that is removed the rest
> forms a part of the javaee specifications that we have a license to
> implement, so we can translate it by any means we want (such as
> xmlbeans, jaxb, castor, etc etc) to produce source code or class
> files or pretty much anything else. I don't see how it's possible to
> implement the specification without this: IMO without this
> interpretation any javaee product must be cddl.
I acknowledge that there was a time critical question in the portions
that I snipped, but first I think that it is important that we come to
a common understanding of what the problem is. Given that there are
lawyers on this list, I'm sure that somebody will point out the
thousands of tiny mistakes that I'm about to make, but I'm confident
that I have the broad brush strokes right, so here goes...
In order for us to legally distribute some Work, we must comply with
all the terms and conditions in the licenses that contribute to that
work. That's it. End of sentence.
Presuming that we do that, do we have the right to distribute code
under the CDDL? Yes, absolutely. Are there any terms or conditions
in CDDL that we would find overly burdensome to *us* (the ones
releasing the software)? Absolutely not.
Furthermore, we even have the rights to distribute the version of XSDs
that SUN PROPRIETARY/CONFIDENTIAL, even though Sun labeling it so
brings into doubt what their true intentions were in licensing this
materials, which makes our ability to demonstrate that we have
complied with their intentions harder. Note that I said harder, I
didn't say impossible. We have ample documentation to demonstrate
that the ASF has the right to ship these XSDs, but who wants to have
to go and explain all this time and time again, potentially to each
and every new user of Geronimo?
Back to CDDL. I have no personal knowledge as to why Sun picked this
particular license, but let's look at it in context. Each of the XSDs
in question represents a machine readable codification of a portion of
a standard. As a standard means that you and I do something the same
way, any modification means that you and I are doing something
different, so it isn't a standard. So, effectively, we are taking
these sources in and agreeing not to modify them, which makes them not
open source. If you think we have heartburn on CDDL, think about the
idea of the ASF shipping code that contains portions that are not open
source.
But, we are not about to say that standards are not a good thing. To
the contrary.
This is all absurd. You can see the source. You can change it, as
long as you don't claim compatibility. Now, with CDDL, that is
explicit. Yea!
So, what's the problem here?
The problem isn't with Sun. The problem is with the ASF. The ASF is
about community (how we develop software) and license (what we permit
users of our code to do).
Our license is part of who we are. Others may distribute things under
different licenses, and that, in part, defines who they are.
Our license intentionally allows users to modify, sublicense, and
distribute our code. All of it. If people want to contribute back
their changes to us, they can join our communities. If people want to
release their changes under their own license, they can do that too.
If people want to retain their changes and only distribute binaries,
that's OK too.
Most of our code bases make it easy for our users. Everything comes
under one license. A license that it relatively short, and well
understood.
Geronimo isn't one of those code bases. It contains many parts from
many sources. In releasing Geronimo, we need to make sure that all of
this is crystal clear. The bulk is under the ASF license, and people
are free to modify that bulk as they see fit. Some portions are
packaged with the distribution as a convenience (or in the case of
these XSDs, as a necessity), but none of these subcomponents impose
any additional restrictions on what you can do with the code that we
produce, and all of it is clearly labeled.
In particular, (and I may just be misreading your statement), it is
NOT the case that "any javaee product must BE cddl", but rather "any
javaee product must CONTAIN cddl" (actually, those files can be
licensed under other licenses, but lets not digress).
So... what is the ASF legal committee and the Geronimo PMC to do?
Well, again, legally, Geronomo has the right to make releases as long
as those releases comply with the appropriate licenses, so one could
make the case that everything from that point on is up to the Geronimo
PMC. And, in fact, this stuff is complicated enough that how you make
the determination as to what makes sense in any particular situation
depends very much on the situation, so again, it is Geronimo's
problem.
On the other hand, given that this stuff is complicated, it makes
sense for us to pool our knowledge. Have a central place where
projects can go to (and contribute back to) where general guidelines
are captured and interesting special cases are referenced.
Things like "yes, the license for foo.dtd requires people to provide
source with any changes that they distribute, but project P only uses
the dtd in a way that consumes the source itself directly at runtime,
so that requirement doesn't apply in our situation", and "the license
for bar.xsd requires that people provide source with any changes that
they make, and we want to make this crystal clear to people. Since
bar.xsd doesn't change very often, we compile it into .class (or .jar)
files, and check that into SVN, along with instructions on where to
find the original sources".
I've rambled for long enough now... so let me close with this: let's
suppose somebody gets this wrong (it happens). A bug report comes in.
Where do you think such a bug report would be routed? To the board?
To the legal committee? To Geronimo? If you guess the third, you
would be right.
How can I help? Well, for starters, I don't want to spend any of my
time answering any time critical hypotheticals. Nor do I want
somebody to back up a dump truck, and say "here's Geronimo, you figure
it out". But if there are specific questions that we can jointly work
through, I am here to help.
If this makes sense, we can go back to your specific question(s). If
not, let's see if we can come to a common understanding of the context
before we proceed.
Fair enough?
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@apache.org>.
On 8/4/07, David Jencks <da...@yahoo.com> wrote:
>
> BTW, the theory under which we (geronimo) has been operating is that
> the sun copyright and legal statements apply to the text
> documentation in the schemas and that once that is removed the rest
> forms a part of the javaee specifications that we have a license to
> implement, so we can translate it by any means we want (such as
> xmlbeans, jaxb, castor, etc etc) to produce source code or class
> files or pretty much anything else. I don't see how it's possible to
> implement the specification without this: IMO without this
> interpretation any javaee product must be cddl.
I acknowledge that there was a time critical question in the portions
that I snipped, but first I think that it is important that we come to
a common understanding of what the problem is. Given that there are
lawyers on this list, I'm sure that somebody will point out the
thousands of tiny mistakes that I'm about to make, but I'm confident
that I have the broad brush strokes right, so here goes...
In order for us to legally distribute some Work, we must comply with
all the terms and conditions in the licenses that contribute to that
work. That's it. End of sentence.
Presuming that we do that, do we have the right to distribute code
under the CDDL? Yes, absolutely. Are there any terms or conditions
in CDDL that we would find overly burdensome to *us* (the ones
releasing the software)? Absolutely not.
Furthermore, we even have the rights to distribute the version of XSDs
that SUN PROPRIETARY/CONFIDENTIAL, even though Sun labeling it so
brings into doubt what their true intentions were in licensing this
materials, which makes our ability to demonstrate that we have
complied with their intentions harder. Note that I said harder, I
didn't say impossible. We have ample documentation to demonstrate
that the ASF has the right to ship these XSDs, but who wants to have
to go and explain all this time and time again, potentially to each
and every new user of Geronimo?
Back to CDDL. I have no personal knowledge as to why Sun picked this
particular license, but let's look at it in context. Each of the XSDs
in question represents a machine readable codification of a portion of
a standard. As a standard means that you and I do something the same
way, any modification means that you and I are doing something
different, so it isn't a standard. So, effectively, we are taking
these sources in and agreeing not to modify them, which makes them not
open source. If you think we have heartburn on CDDL, think about the
idea of the ASF shipping code that contains portions that are not open
source.
But, we are not about to say that standards are not a good thing. To
the contrary.
This is all absurd. You can see the source. You can change it, as
long as you don't claim compatibility. Now, with CDDL, that is
explicit. Yea!
So, what's the problem here?
The problem isn't with Sun. The problem is with the ASF. The ASF is
about community (how we develop software) and license (what we permit
users of our code to do).
Our license is part of who we are. Others may distribute things under
different licenses, and that, in part, defines who they are.
Our license intentionally allows users to modify, sublicense, and
distribute our code. All of it. If people want to contribute back
their changes to us, they can join our communities. If people want to
release their changes under their own license, they can do that too.
If people want to retain their changes and only distribute binaries,
that's OK too.
Most of our code bases make it easy for our users. Everything comes
under one license. A license that it relatively short, and well
understood.
Geronimo isn't one of those code bases. It contains many parts from
many sources. In releasing Geronimo, we need to make sure that all of
this is crystal clear. The bulk is under the ASF license, and people
are free to modify that bulk as they see fit. Some portions are
packaged with the distribution as a convenience (or in the case of
these XSDs, as a necessity), but none of these subcomponents impose
any additional restrictions on what you can do with the code that we
produce, and all of it is clearly labeled.
In particular, (and I may just be misreading your statement), it is
NOT the case that "any javaee product must BE cddl", but rather "any
javaee product must CONTAIN cddl" (actually, those files can be
licensed under other licenses, but lets not digress).
So... what is the ASF legal committee and the Geronimo PMC to do?
Well, again, legally, Geronomo has the right to make releases as long
as those releases comply with the appropriate licenses, so one could
make the case that everything from that point on is up to the Geronimo
PMC. And, in fact, this stuff is complicated enough that how you make
the determination as to what makes sense in any particular situation
depends very much on the situation, so again, it is Geronimo's
problem.
On the other hand, given that this stuff is complicated, it makes
sense for us to pool our knowledge. Have a central place where
projects can go to (and contribute back to) where general guidelines
are captured and interesting special cases are referenced.
Things like "yes, the license for foo.dtd requires people to provide
source with any changes that they distribute, but project P only uses
the dtd in a way that consumes the source itself directly at runtime,
so that requirement doesn't apply in our situation", and "the license
for bar.xsd requires that people provide source with any changes that
they make, and we want to make this crystal clear to people. Since
bar.xsd doesn't change very often, we compile it into .class (or .jar)
files, and check that into SVN, along with instructions on where to
find the original sources".
I've rambled for long enough now... so let me close with this: let's
suppose somebody gets this wrong (it happens). A bug report comes in.
Where do you think such a bug report would be routed? To the board?
To the legal committee? To Geronimo? If you guess the third, you
would be right.
How can I help? Well, for starters, I don't want to spend any of my
time answering any time critical hypotheticals. Nor do I want
somebody to back up a dump truck, and say "here's Geronimo, you figure
it out". But if there are specific questions that we can jointly work
through, I am here to help.
If this makes sense, we can go back to your specific question(s). If
not, let's see if we can come to a common understanding of the context
before we proceed.
Fair enough?
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 4, 2007, at 3:23 AM, David Jencks wrote:
<snip>
>
> OK, on to a more specific and time-critical question.
>
> Geronimo has the pre-cddl j2ee 1.4 and javaee5 schemas in the
> hidden tck svn repo, and we use xmlbeans to generate classes from
> them. Previously we've released source and .class jars for the
> j2ee 1.4 schemas. We are currently voting on new source and .class
> jars for both the j2ee 1.4 and javaee5 schemas. This vote will end
> aug 4 at 7:17 PST and unless we receive clear notice to the
> contrary will be released to the apache maven repo and thence the
> maven central repo shortly thereafter.
> The stuff being voted on is at
> http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
> http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz
David,
Given the current state of this discussion, I don't think that the
vote on these releases can be passed. As you have noted on
dev@geronimo the same condition would apply to our geronimo-
servlet_2.5_spec vote. Until we've resolved this CDDL issue, IMO we
won't be able to make these releases. I've noted my opinion on the
relevant vote threads.
--kevan
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 4, 2007, at 3:23 AM, David Jencks wrote:
<snip>
>
> OK, on to a more specific and time-critical question.
>
> Geronimo has the pre-cddl j2ee 1.4 and javaee5 schemas in the
> hidden tck svn repo, and we use xmlbeans to generate classes from
> them. Previously we've released source and .class jars for the
> j2ee 1.4 schemas. We are currently voting on new source and .class
> jars for both the j2ee 1.4 and javaee5 schemas. This vote will end
> aug 4 at 7:17 PST and unless we receive clear notice to the
> contrary will be released to the apache maven repo and thence the
> maven central repo shortly thereafter.
> The stuff being voted on is at
> http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
> http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz
David,
Given the current state of this discussion, I don't think that the
vote on these releases can be passed. As you have noted on
dev@geronimo the same condition would apply to our geronimo-
servlet_2.5_spec vote. Until we've resolved this CDDL issue, IMO we
won't be able to make these releases. I've noted my opinion on the
relevant vote threads.
--kevan
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
On Aug 3, 2007, at 6:45 PM, Craig L Russell wrote:
>
> On Aug 3, 2007, at 6:20 PM, Stefano Bagnara wrote:
>
>> Sam Ruby ha scritto:
>>> Until the dust settles, I'm asking that all SUN
>>> PROPRIETARY/CONFIDENTIAL dtd's and xsd's be removed. For the
>>> moment,
>>> they can be be replaced by CDDL licensed equivalents (if available)
>>> but only if the only ways that particular product uses these
>>> materials
>>> is directly via their original source form. If, however, any of
>>> these
>>> files are used by the product in question as input to a 'compilation
>>> step' of any sort, then they should be replaced by the binary
>>> outputs
>>> instead (i.e., class "B" artifacts).
>>>
>>> If anybody has any problem with this (either affected products as
>>> this
>>> is an unreasonable burden, or legal-internal folks as this
>>> inconsistent with ASF principles), please let me know ASAP. In the
>>> event that I don't hear any objection in the next 72 hours, I will
>>> make a minor update to the 3party draft some time next week.
I don't think I understand exactly what you mean, I don't think it
makes sense, and just in case I do understand you this will prevent
geronimo from releasing artifacts now under vote. See below.
>>>
>>> - Sam Ruby
>
> Just a clarification. If a dtd or xsd file is "compiled" into a
> binary form, my assumption is that the project still needs to
> identify the resulting file as licensed under the CDDL license of
> the original source. So the distribution will still need the
> LICENSE.txt file identifying the binary and calling out the CDDL
> license.
I'm rapidly coming to the conclusion that apache should not even
think about trying to host or release anything even vaguely related
to a sun licensed schema.
Can you explain which of these should be asf licensed and which cddl
licensed and how exactly you draw the line?
Lets start with the cddl licensed javaee 5 xsds.
1. use xmlbeans to compile the xsds as part of a build process.
Basically all you can specify is the package of the resulting java
source files.
2. use jaxb to generate classes corresponding to the xsds as part of
a build process. I think this is basically the same as (1)
3. use jaxb to generate classes corresponding to the xsds, check the
code into svn, and modify it by hand
4. write some classes with basically the same infomation content as
the schema, and use a rule based approach such as digester to
transfer the information from the xml to the objects. I'm curious
about the status of the rules and the data classes.
5. write some classes with basically the same information content as
the schema and write some say STAX based code to transfer the info
between xml and objects. (i.e. write a subset of xmlbeans or jaxb by
hand).
In all of these cases, when is the source code, whether written by
hand or generated, cddl, when is it asl, and when can it be
distributed as part of an apache project. What would the license be
for jars containing .class files for these classes? What about rules
for (4) if they are in human-readable form?
I can't really see any difference between these cases, so if anyone
else can I'd really appreciate a clear detailed explanation of why
they are different. I also don't really see how a javaee app server
is any different from these source or class files, since it has to
contain data structures semantically equivalent to the xsds.
OK, on to a more specific and time-critical question.
Geronimo has the pre-cddl j2ee 1.4 and javaee5 schemas in the hidden
tck svn repo, and we use xmlbeans to generate classes from them.
Previously we've released source and .class jars for the j2ee 1.4
schemas. We are currently voting on new source and .class jars for
both the j2ee 1.4 and javaee5 schemas. This vote will end aug 4 at
7:17 PST and unless we receive clear notice to the contrary will be
released to the apache maven repo and thence the maven central repo
shortly thereafter.
The stuff being voted on is at
http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz
In our naivete we have included the asf2 license in these jars and,
as the source code is entirely generated, not added any license
header to the .java files.
What's the correct license for the generated source java files?
xmlbeans also generates some binary data files from the schemas. I
think (but am by no means certain) that they are serialized java
objects representing the schema: in any case they have almost the
same infomation content as the schemas). What is the correct
license for them?
After the generated java source files get compiled, what is the
correct license for them?
Can any of these be distributed from apache? If not, if we moved
this stuff to say codehaus or sourceforge, and generated exactly the
same code and jars (except for the package name), could we use those
jars in geronimo?
BTW, the theory under which we (geronimo) has been operating is that
the sun copyright and legal statements apply to the text
documentation in the schemas and that once that is removed the rest
forms a part of the javaee specifications that we have a license to
implement, so we can translate it by any means we want (such as
xmlbeans, jaxb, castor, etc etc) to produce source code or class
files or pretty much anything else. I don't see how it's possible to
implement the specification without this: IMO without this
interpretation any javaee product must be cddl.
david jencks
>
> Craig
>
> Craig Russell
> DB PMC, OpenJPA PMC
> clr@apache.org http://db.apache.org/jdo
>
>
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
On Aug 3, 2007, at 6:45 PM, Craig L Russell wrote:
>
> On Aug 3, 2007, at 6:20 PM, Stefano Bagnara wrote:
>
>> Sam Ruby ha scritto:
>>> Until the dust settles, I'm asking that all SUN
>>> PROPRIETARY/CONFIDENTIAL dtd's and xsd's be removed. For the
>>> moment,
>>> they can be be replaced by CDDL licensed equivalents (if available)
>>> but only if the only ways that particular product uses these
>>> materials
>>> is directly via their original source form. If, however, any of
>>> these
>>> files are used by the product in question as input to a 'compilation
>>> step' of any sort, then they should be replaced by the binary
>>> outputs
>>> instead (i.e., class "B" artifacts).
>>>
>>> If anybody has any problem with this (either affected products as
>>> this
>>> is an unreasonable burden, or legal-internal folks as this
>>> inconsistent with ASF principles), please let me know ASAP. In the
>>> event that I don't hear any objection in the next 72 hours, I will
>>> make a minor update to the 3party draft some time next week.
I don't think I understand exactly what you mean, I don't think it
makes sense, and just in case I do understand you this will prevent
geronimo from releasing artifacts now under vote. See below.
>>>
>>> - Sam Ruby
>
> Just a clarification. If a dtd or xsd file is "compiled" into a
> binary form, my assumption is that the project still needs to
> identify the resulting file as licensed under the CDDL license of
> the original source. So the distribution will still need the
> LICENSE.txt file identifying the binary and calling out the CDDL
> license.
I'm rapidly coming to the conclusion that apache should not even
think about trying to host or release anything even vaguely related
to a sun licensed schema.
Can you explain which of these should be asf licensed and which cddl
licensed and how exactly you draw the line?
Lets start with the cddl licensed javaee 5 xsds.
1. use xmlbeans to compile the xsds as part of a build process.
Basically all you can specify is the package of the resulting java
source files.
2. use jaxb to generate classes corresponding to the xsds as part of
a build process. I think this is basically the same as (1)
3. use jaxb to generate classes corresponding to the xsds, check the
code into svn, and modify it by hand
4. write some classes with basically the same infomation content as
the schema, and use a rule based approach such as digester to
transfer the information from the xml to the objects. I'm curious
about the status of the rules and the data classes.
5. write some classes with basically the same information content as
the schema and write some say STAX based code to transfer the info
between xml and objects. (i.e. write a subset of xmlbeans or jaxb by
hand).
In all of these cases, when is the source code, whether written by
hand or generated, cddl, when is it asl, and when can it be
distributed as part of an apache project. What would the license be
for jars containing .class files for these classes? What about rules
for (4) if they are in human-readable form?
I can't really see any difference between these cases, so if anyone
else can I'd really appreciate a clear detailed explanation of why
they are different. I also don't really see how a javaee app server
is any different from these source or class files, since it has to
contain data structures semantically equivalent to the xsds.
OK, on to a more specific and time-critical question.
Geronimo has the pre-cddl j2ee 1.4 and javaee5 schemas in the hidden
tck svn repo, and we use xmlbeans to generate classes from them.
Previously we've released source and .class jars for the j2ee 1.4
schemas. We are currently voting on new source and .class jars for
both the j2ee 1.4 and javaee5 schemas. This vote will end aug 4 at
7:17 PST and unless we receive clear notice to the contrary will be
released to the apache maven repo and thence the maven central repo
shortly thereafter.
The stuff being voted on is at
http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz
In our naivete we have included the asf2 license in these jars and,
as the source code is entirely generated, not added any license
header to the .java files.
What's the correct license for the generated source java files?
xmlbeans also generates some binary data files from the schemas. I
think (but am by no means certain) that they are serialized java
objects representing the schema: in any case they have almost the
same infomation content as the schemas). What is the correct
license for them?
After the generated java source files get compiled, what is the
correct license for them?
Can any of these be distributed from apache? If not, if we moved
this stuff to say codehaus or sourceforge, and generated exactly the
same code and jars (except for the package name), could we use those
jars in geronimo?
BTW, the theory under which we (geronimo) has been operating is that
the sun copyright and legal statements apply to the text
documentation in the schemas and that once that is removed the rest
forms a part of the javaee specifications that we have a license to
implement, so we can translate it by any means we want (such as
xmlbeans, jaxb, castor, etc etc) to produce source code or class
files or pretty much anything else. I don't see how it's possible to
implement the specification without this: IMO without this
interpretation any javaee product must be cddl.
david jencks
>
> Craig
>
> Craig Russell
> DB PMC, OpenJPA PMC
> clr@apache.org http://db.apache.org/jdo
>
>
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 3, 2007, at 6:20 PM, Stefano Bagnara wrote:
> Sam Ruby ha scritto:
>> Until the dust settles, I'm asking that all SUN
>> PROPRIETARY/CONFIDENTIAL dtd's and xsd's be removed. For the moment,
>> they can be be replaced by CDDL licensed equivalents (if available)
>> but only if the only ways that particular product uses these
>> materials
>> is directly via their original source form. If, however, any of
>> these
>> files are used by the product in question as input to a 'compilation
>> step' of any sort, then they should be replaced by the binary outputs
>> instead (i.e., class "B" artifacts).
>>
>> If anybody has any problem with this (either affected products as
>> this
>> is an unreasonable burden, or legal-internal folks as this
>> inconsistent with ASF principles), please let me know ASAP. In the
>> event that I don't hear any objection in the next 72 hours, I will
>> make a minor update to the 3party draft some time next week.
>>
>> - Sam Ruby
Just a clarification. If a dtd or xsd file is "compiled" into a
binary form, my assumption is that the project still needs to
identify the resulting file as licensed under the CDDL license of the
original source. So the distribution will still need the LICENSE.txt
file identifying the binary and calling out the CDDL license.
Craig
Craig Russell
DB PMC, OpenJPA PMC
clr@apache.org http://db.apache.org/jdo
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
Sam Ruby ha scritto:
> On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Sam, I agree on this. ASF legal-team should provide an explicit
>> guideline in the 3rd party licenses to make clear what we are supposed
>> to do in this case.
>
> In case anybody missed the announcement, not only am I on the
> legal-team, but I'm also its current chair.
Sorry Sam, I was not ignoring your statements ;-) I read the
announcement. I'm asking for a generalization and clarification about
the issue.
Sorry for my english, what I wanted to tell is that I know that this
list is not considered an "official" way to give legal advice to
committers and policies for the ASF.
So I was asking to have it added to the specific page we already
reference for this issue (and I seem at the bottom of this mail, this is
exactly your plan ;-) ).
> Until the dust settles, I'm asking that all SUN
> PROPRIETARY/CONFIDENTIAL dtd's and xsd's be removed. For the moment,
> they can be be replaced by CDDL licensed equivalents (if available)
> but only if the only ways that particular product uses these materials
> is directly via their original source form. If, however, any of these
> files are used by the product in question as input to a 'compilation
> step' of any sort, then they should be replaced by the binary outputs
> instead (i.e., class "B" artifacts).
>
> If anybody has any problem with this (either affected products as this
> is an unreasonable burden, or legal-internal folks as this
> inconsistent with ASF principles), please let me know ASAP. In the
> event that I don't hear any objection in the next 72 hours, I will
> make a minor update to the 3party draft some time next week.
>
> - Sam Ruby
This update makes sense to me and fix the issue that worried me with
Apache JAMES including CDDL jars (mail.jar and activation.jar) including
text files that could be identified as "Source Code" under the CDDL terms.
If I understood it well it does not solve the problem others have in
other projects but having solved my issues I leave to them the
discussion of their specific issues.
Thank you,
Stefano
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@intertwingly.net>.
On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> Sam, I agree on this. ASF legal-team should provide an explicit
> guideline in the 3rd party licenses to make clear what we are supposed
> to do in this case.
In case anybody missed the announcement, not only am I on the
legal-team, but I'm also its current chair.
Until the dust settles, I'm asking that all SUN
PROPRIETARY/CONFIDENTIAL dtd's and xsd's be removed. For the moment,
they can be be replaced by CDDL licensed equivalents (if available)
but only if the only ways that particular product uses these materials
is directly via their original source form. If, however, any of these
files are used by the product in question as input to a 'compilation
step' of any sort, then they should be replaced by the binary outputs
instead (i.e., class "B" artifacts).
If anybody has any problem with this (either affected products as this
is an unreasonable burden, or legal-internal folks as this
inconsistent with ASF principles), please let me know ASAP. In the
event that I don't hear any objection in the next 72 hours, I will
make a minor update to the 3party draft some time next week.
- Sam Ruby
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 1, 2007, at 12:28 AM, Remy Maucherat wrote:
> Craig L Russell wrote:
>> Remy Maucherat wrote:
>>>
>>> AFAIK, a version of these files without the problematic headers
>>> exists in the various specification documents.
>> This unfortunately doesn't help. The license for the
>> specifications is not an Apache-compatible license.
>
> This would mean we cannot ship a proper Servlet API JAR, and I see
> no way an ASF project can hope to implement any JCP specifications
> then :)
Let me clarify. I should have said that the license for the
specifications is not an Apache license.
My point is that just because an API is published in a specification
does not mean that an Apache project can assign an Apache license to
it after typing it into machine-readable form.
The intellectual property remains with the specification, which is
governed by the specification license unless superseded by another
license in the machine-readable code.
Sun recently released the older specification xsd's under a joint GPL/
CDDL license which should solve this issue for all relevant Sun-led
JSRs.
And just to be clear, I'm not talking about the specific files that
were being developed by Sun in Apache. That's the issue that started
this thread but not the issue being discussed now.
Craig
>
> Rémy
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > The license for the specifications is not an Apache-compatible license.
> This would mean we cannot ship a proper Servlet API JAR, and I see no
> way an ASF project can hope to implement any JCP specifications then :)
It would depends on the specification license, and other JSR spec leads are
taking a different licensing approach from Sun.
--- Noel
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Remy Maucherat <re...@apache.org>.
Craig L Russell wrote:
>> I was still at Sun at this time, although I left soon after that. I
>> was doing setup of the Tomcat 5.0.x repository on their behalf at the
>> time, and would be fully supported by the other Sun employees working
>> on Tomcat at the time.
>>
>> AFAIK, a version of these files without the problematic headers exists
>> in the various specification documents.
>
> This unfortunately doesn't help. The license for the specifications is
> not an Apache-compatible license.
This would mean we cannot ship a proper Servlet API JAR, and I see no
way an ASF project can hope to implement any JCP specifications then :)
Rémy
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
Sorry, I wrote this before reading Sam Ruby reply in another part of the
message tree.
His "guideline", IMO, solve the JAMES Server specific issue I was
describing here.
Stefano
Stefano Bagnara ha scritto:
> That's what I'm trying to say: we need to understand what is the ASF
> policy wrt non class files included in CDDL licensed jars.
>
> The mail-1.4.jar example is what I committed to our svn repository
> believing I was committing a category B artifact and now I'm not sure I
> could have done it as it includes also some text file that we cannot
> consider binary. As I don't want to be individually responsible for such
> things, should I write our PMC about this and should we stop
> distributing JAMES Server? Or is this only a missing piece in the ASF
> policy?
>
> The most important thing is that I don't want any individual
> responsibility for this: if the PMC decision to release does not protect
> me then I will remove the CDDL jar tomorrow and someone else will try to
> understand if the ASF policies allow us to include it or not ;-)
>
> I agree with everything else you wrote.
>
> Stefano
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
Roy T. Fielding ha scritto:
> On Aug 3, 2007, at 1:22 AM, Stefano Bagnara wrote:
>> Santiago Gala ha scritto:
>>> I'm not really sure what we are trying to achieve here, but a file
>>> committed by a Sun employee, that has signed a CLA, while working under
>>> Sun direction, etc. *is licensed under AL 2.0*
>>
>> This is a very dangerous "statement". I committed many files to the ASF
>> repositories under the CDDL, the BSD, the MIT, the MPL licenses (being
>> them jars, xmls or other files) but this does not means they are now AL
>> 2.0 and copyrighted to ASF.
>
> No, and Santiago didn't say anything like that either. In this case,
> Sun has a long-standing agreement with the ASF which says that
> all Sun-copyrighted content that their employees commit to Tomcat
> is contributed under license to the ASF and we may relicense it
> at will provided the license is consistent with our open source,
> nonprofit purpose. That was part of our agreement to accept the
> Tomcat code (and logo) as an Apache project.
>
> Second, we are not responsible for any actions by individuals.
> If a committer submits code that they do not have the legal right
> to submit, then they will not be defended by Apache. What the ASF
> defends are the decisions of our PMCs to make a release, not the
> decisions by individual committers to ignore our policies.
That's what I'm trying to say: we need to understand what is the ASF
policy wrt non class files included in CDDL licensed jars.
The mail-1.4.jar example is what I committed to our svn repository
believing I was committing a category B artifact and now I'm not sure I
could have done it as it includes also some text file that we cannot
consider binary. As I don't want to be individually responsible for such
things, should I write our PMC about this and should we stop
distributing JAMES Server? Or is this only a missing piece in the ASF
policy?
The most important thing is that I don't want any individual
responsibility for this: if the PMC decision to release does not protect
me then I will remove the CDDL jar tomorrow and someone else will try to
understand if the ASF policies allow us to include it or not ;-)
I agree with everything else you wrote.
Stefano
> Third, unless specifically stated otherwise in a contribution and
> accepted as such by the PMC, all contributions are under the Apache
> license. NOBODY has the right to commit non-Apache-Licensed source
> to an ASF project without prior approval of the responsible PMC.
>
> I don't know the specific background of the files in myfaces, unlike
> the ones in Tomcat. I do know Craig was mentoring the project and
> that he was the spec lead at the time, so whoever did commit those
> files to MyFaces did so with his permission.
>
> None of that changes the copyright on these files. The copyright
> is still owned by Sun. However, we cannot publish misleading and
> incorrect license notices within our releases. The files committed
> to our repository with permission of the copyright owner must have
> a license header consistent with the license they gave to the ASF.
> The copyright ownership notice should remain. Only the header info
> about the no-longer-applicable license is removed. If the copyright
> owner disagrees with a specific contribution, it is their
> responsibility to notify us. Once that notice is received, we will
> take whatever action is warranted aside from changing history -- we
> will not change old (approved) releases just because a copyright
> owner has changed their mind about a past commit.
>
> In any case, if these files are updated to the most recent specs or
> new files are suggested for commit, it is the committer's and PMC's
> responsibility to ensure that permission is obtained from the
> copyright owner and that the result of that permission is reflected
> in the license headers. That will always be a requirement, no
> matter what our policies say about third-party licenses.
>
> ....Roy
>
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Aug 3, 2007, at 1:22 AM, Stefano Bagnara wrote:
> Santiago Gala ha scritto:
>> I'm not really sure what we are trying to achieve here, but a file
>> committed by a Sun employee, that has signed a CLA, while working
>> under
>> Sun direction, etc. *is licensed under AL 2.0*
>
> This is a very dangerous "statement". I committed many files to the
> ASF
> repositories under the CDDL, the BSD, the MIT, the MPL licenses (being
> them jars, xmls or other files) but this does not means they are
> now AL
> 2.0 and copyrighted to ASF.
No, and Santiago didn't say anything like that either. In this case,
Sun has a long-standing agreement with the ASF which says that
all Sun-copyrighted content that their employees commit to Tomcat
is contributed under license to the ASF and we may relicense it
at will provided the license is consistent with our open source,
nonprofit purpose. That was part of our agreement to accept the
Tomcat code (and logo) as an Apache project.
Second, we are not responsible for any actions by individuals.
If a committer submits code that they do not have the legal right
to submit, then they will not be defended by Apache. What the ASF
defends are the decisions of our PMCs to make a release, not the
decisions by individual committers to ignore our policies.
Third, unless specifically stated otherwise in a contribution and
accepted as such by the PMC, all contributions are under the Apache
license. NOBODY has the right to commit non-Apache-Licensed source
to an ASF project without prior approval of the responsible PMC.
I don't know the specific background of the files in myfaces, unlike
the ones in Tomcat. I do know Craig was mentoring the project and
that he was the spec lead at the time, so whoever did commit those
files to MyFaces did so with his permission.
None of that changes the copyright on these files. The copyright
is still owned by Sun. However, we cannot publish misleading and
incorrect license notices within our releases. The files committed
to our repository with permission of the copyright owner must have
a license header consistent with the license they gave to the ASF.
The copyright ownership notice should remain. Only the header info
about the no-longer-applicable license is removed. If the copyright
owner disagrees with a specific contribution, it is their
responsibility to notify us. Once that notice is received, we will
take whatever action is warranted aside from changing history -- we
will not change old (approved) releases just because a copyright
owner has changed their mind about a past commit.
In any case, if these files are updated to the most recent specs or
new files are suggested for commit, it is the committer's and PMC's
responsibility to ensure that permission is obtained from the
copyright owner and that the result of that permission is reflected
in the license headers. That will always be a requirement, no
matter what our policies say about third-party licenses.
....Roy
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@intertwingly.net>.
On 8/3/07, David Jencks <da...@yahoo.com> wrote:
>
> 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.
>
> 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)
First a note: the license of the compiler itself may not matter much.
I routinely use gcc.
> 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?
It may very well turn out that the policy is usage dependent.
Referencing a DTD in a <!DOCTYPE> declaration is quite a different
proposition than providing an XSD as input to JAXB. This may lead to
surprising conclusions, for example it may end up being the case that
ASF Policy would be OK with MyFaces shipping a given file but not OK
with Geronimo shipping that exact same file based on the intended
usage.
Let me emphasize that this is a policy issue, not a legal issue.
Legally we can't ship source to things that are marked SUN
PROPRIETARY/CONFIDENTIAL, but not only can we ship code that is
licensed under CDDL, we are free to relicense entire codebases under
that license.
Of the three things mentioned in the first paragraph, we need to stop
doing the first, we won't ever do the third, and we need to
collectively decide when we will allow the second.
- Sam Ruby
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
Sam Ruby ha scritto:
> On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>> 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?
>
> The xsd files in question are Source Code.
>
>> 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?
>
> Nothing. But I can point another corporation, namely the ASF, which might.
>
> - Sam Ruby
Sam, I agree on this. ASF legal-team should provide an explicit
guideline in the 3rd party licenses to make clear what we are supposed
to do in this case.
Here we are only (I was only) discussing what is our interpretation of
the legal requirements.
ASF legal-team should take into considerations whether their "added"
restrictions/guidelines will prevent some ASF product to be released or not.
The strict interpretation of the 3rd party license page wrt xml (and
other text based files) files distributed under a category B is that we
cannot distribute them at all. Given that MOST software out there
include something more that simple binary class files (most jars include
at least 1 xml/xsd/properties file that is not strictly a binary even if
it is part of the jar) then most of ASF releases including category B
software are not following the current guidelines.
As an example in Apache JAMES we redistribute CDDL licensed JavaMail
1.4. In the META-INF folder of the mail-1.4.jar file we can find some
text file (defined "Source Code" in a strict interpretation of the above
CDDL points). namely they are mailcap, javamail.charset.map,
javamail.default.providers, javamail.default.address.map.
I'm not a lawyer, so we need the ASF to explain us what we have to do: I
want to be protected by ASF if something goes wrong with an Apache JAMES
release because we included some file, so I want to be sure I'm
following the guidelines ;-)
Stefano
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Sam Ruby <ru...@intertwingly.net>.
On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> 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?
The xsd files in question are Source Code.
> 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?
Nothing. But I can point another corporation, namely the ASF, which might.
- Sam Ruby
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
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?
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by David Jencks <da...@yahoo.com>.
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.
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
>
> Stefano
>
>
> ---------------------------------------------------------------------
> 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
>
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
Santiago Gala ha scritto:
> El vie, 03-08-2007 a las 10:22 +0200, Stefano Bagnara escribió:
>> Santiago Gala ha scritto:
>>> I'm not really sure what we are trying to achieve here, but a file
>>> committed by a Sun employee, that has signed a CLA, while working
>> under
>>> Sun direction, etc. *is licensed under AL 2.0*
>> This is a very dangerous "statement". I committed many files to the
>> ASF
>> repositories under the CDDL, the BSD, the MIT, the MPL licenses (being
>> them jars, xmls or other files) but this does not means they are now
>> AL
>> 2.0 and copyrighted to ASF.
>>
>>
>
> Sorry, but copying from Hen's previous email in the thread: "is an
> example of a file with both Apache permissive licensing, and a Sun
> extremely unpermissive header." if I read correctly, the file had *two
> license headers* one AL 2.0 and the other one Sun's proprietary (no OS
> license there).
>
> So:
>
>> About this specific issue I don't think that the ASF should treat a
>> SUN
>> employee differently from any other committer: if the file has been
>> committed with the ASF header then you are right, otherwise the people
>> that changed the header is responsible for the licensing mistake.
>
> (I take the "you are right" route, please correct me if I'm wrong)
I just looked at the 2 files linked in the first post and I see that the
first commit for both does not include an ASF header:
As you can see this was committed in 2003 by manolito and had no header
at all. royalts in 2004 updated it with a new file including the sun
copyright header. "grantsmith" added the ASF header on top of it on May
2007.
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_0.dtd?revision=166024&view=markup
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_0.dtd?r1=166024&r2=166226
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_0.dtd?r1=410138&r2=540374
Similar thing for the other file. Here the file was resurrected from a
previous delete (I did not track this before) and already had the sun
copyright. Then "grantsmith" added the ASF header on top of it on May 2007:
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_1.dtd?revision=374886&view=markup
http://svn.apache.org/viewvc/myfaces/core/trunk/impl/src/main/resources/org/apache/myfaces/resource/web-facesconfig_1_1.dtd?r1=410138&r2=540374
So, if Grant Smith is a SUN employee or he is the copyright holder for
that file then "you are right", otherwise this change is a mistake (I
hope a mistake).
AFAIK ASF protects his committers from this mistakes (when they
recognize it was a mistake and not an intended abuse) and in this case
the right solution IMHO is to revert to the copyrighted work and if it
is incompatible with ASF 3rd party guidelines then remove it instead of
adding arbitrary headers.
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.
Stefano
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Santiago Gala <sg...@apache.org>.
El vie, 03-08-2007 a las 10:22 +0200, Stefano Bagnara escribió:
> Santiago Gala ha scritto:
> > I'm not really sure what we are trying to achieve here, but a file
> > committed by a Sun employee, that has signed a CLA, while working
> under
> > Sun direction, etc. *is licensed under AL 2.0*
>
> This is a very dangerous "statement". I committed many files to the
> ASF
> repositories under the CDDL, the BSD, the MIT, the MPL licenses (being
> them jars, xmls or other files) but this does not means they are now
> AL
> 2.0 and copyrighted to ASF.
>
>
Sorry, but copying from Hen's previous email in the thread: "is an
example of a file with both Apache permissive licensing, and a Sun
extremely unpermissive header." if I read correctly, the file had *two
license headers* one AL 2.0 and the other one Sun's proprietary (no OS
license there).
So:
> About this specific issue I don't think that the ASF should treat a
> SUN
> employee differently from any other committer: if the file has been
> committed with the ASF header then you are right, otherwise the people
> that changed the header is responsible for the licensing mistake.
(I take the "you are right" route, please correct me if I'm wrong)
I assume that if a Sun employee, under CLA and active Sun management,
adds a AL header to a file he commits to a ASF project, this is the
License, *unless Sun officially claims otherwise*. This is what I
posted.. The officially word is important, because we have in this
thread at least one Sun employee speaking from a Sun.com account
(Craig), and it is not clear at all to me which hat he is using. My
email was mostly oriented to "hat clarification" of what is the official
position of Sun with regards to a file that a Sun employee put under
Apache License forgetting to remove the former Sun license provisions.
(this is my view of the issue).
Answering Niclas: I want Sun to say, officially if keeping the Sun
proprietary header in a *essential but minor* file Sun's employees are
contributing under CLA to a Free Software project is, in his words, a
mistake (so the file is to be considered as AL licensed), ignorance
(which means we need to sort the intended terms of license for the file
they contributed starting from the facts: a AL header put on by Sun's
people under Sun command) or malicious (which I hope not, and requires
the same actions as "ignorance")
This is, naturally, personal opinion. I'm no longer ASF officer, just a
member of the foundation.
Regards
Santiago
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Stefano Bagnara <ap...@bago.org>.
Santiago Gala ha scritto:
> I'm not really sure what we are trying to achieve here, but a file
> committed by a Sun employee, that has signed a CLA, while working under
> Sun direction, etc. *is licensed under AL 2.0*
This is a very dangerous "statement". I committed many files to the ASF
repositories under the CDDL, the BSD, the MIT, the MPL licenses (being
them jars, xmls or other files) but this does not means they are now AL
2.0 and copyrighted to ASF.
We knew I could commit them because their license allow us to
redistribute/use them inside our ASLv2 projects but this doesn't means
they are now ALv2 (and the LICENSE in the root of our redistributable
has a specific footer to explain what are the licenses for this files)
Sometimes I submitted java files created by me and without the license
headers (by mistake): the approach of my PMC to this issues was to ask
me if I was the author of that files and ask me to add the license
header because they thought it was not obvious that a file committed by
me without the license header was explicitly contributed under the CLA.
IMHO the interpretation of my PMC was correct: otherwise I fear that
most ASF around already violated copyrights for many files they committed.
About this specific issue I don't think that the ASF should treat a SUN
employee differently from any other committer: if the file has been
committed with the ASF header then you are right, otherwise the people
that changed the header is responsible for the licensing mistake. If
using the original header the file was not compliant with ASF 3rd party
"rules" then the PMC should have oversight on this and fixed the issue
speaking to the committer and not altering the header to their preference.
Stefano
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Santiago Gala <sg...@apache.org>.
El mar, 31-07-2007 a las 18:59 -0700, Craig L Russell escribió:
> On Jul 31, 2007, at 10:34 AM, Remy Maucherat wrote:
>
> > Roy T. Fielding wrote:
> >> On Jul 31, 2007, at 8:56 AM, Henri Yandell wrote:
> >>> On 5/21/07, Kevan Miller <ke...@gmail.com> wrote:
> >>>
> >>>> I raised a similar issue on the Tomcat dev list some months back.
> >>>> Tomcat contains Sun xsd's and dtd's (e.g. http://svn.apache.org/
> >>>> repos/
> >>>> asf/tomcat/trunk/java/javax/servlet/resources/j2ee_1_4.xsd)
> >>>> which are
> >>>> Sun copyright and contain the following restrictions of use:
> >>>>
> >>>> This document and the technology which it describes are
> >>>> distributed under licenses restricting their use, copying,
> >>>> distribution, and decompilation. No part of this document
> >>>> may be reproduced in any form by any means without prior
> >>>> written authorization of Sun and its licensors, if any.
> >>>>
> >>>> I was told that there might be documents in the Foundation svn
> >>>> repository that grant Apache the right to redistribute these files.
> >>>> I've never seen these documents, despite requesting the information
> >>>> from Tomcat. Nor do I know how any rights granted by Sun to Apache
> >>>> might transfer to a third party...
> >>>
> >>> Anyone have more info on this one?
> >>>
> >>> http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-
> >>> jsp2.0-tc5.x/jsr154/src/share/dtd/web-app_2_4.xsd
> >>>
> >>> is an example of a file with both Apache permissive licensing, and a
> >>> Sun extremely unpermissive header. It's come up in Freemarker as an
> >>> issue:
> >>>
> >>> http://sourceforge.net/tracker/index.php?
> >>> func=detail&aid=1754236&group_id=794&atid=100794
> >>>
> >>> Hen
> >> Well, it would help if people did the homework instead of asking
> >> the legal folks to do it for them. The above file was added by Remy
> >> as part of
> >> r266968 | remm | 2002-08-13 09:20:53 -0700 (Tue, 13 Aug 2002) | 2
> >> lines
> >> Remy, were you still an employee of Sun at that time? Was the file
> >> contributed with the permission of Sun?
> >
> > I was still at Sun at this time, although I left soon after that. I
> > was doing setup of the Tomcat 5.0.x repository on their behalf at
> > the time, and would be fully supported by the other Sun employees
> > working on Tomcat at the time.
> >
> > AFAIK, a version of these files without the problematic headers
> > exists in the various specification documents.
>
> This unfortunately doesn't help. The license for the specifications
> is not an Apache-compatible license.
>
> Craig
> >
What is difficult to understand in Roy's statement:
> The file was checked in by a Sun employee under the direction of Sun
> and licensed to the ASF under our CLA. As such, it came under our
> license in 2002 and the old Sun header should have been removed.
I think the issue is settled from the ASF side (and with ASF hats). My
view of it is that the old header be removed with Roy's sentence (real
names, etc) as commit message.
I'm not really sure what we are trying to achieve here, but a file
committed by a Sun employee, that has signed a CLA, while working under
Sun direction, etc. *is licensed under AL 2.0*
If you think the Sun employee was acting mistakenly or out of
prerogatives, we will sure have someone at Sun with the authority tell
the fact *officially*. While this happens, let us remove the old header
and proceed.
Regards
Santiago
> >> If yes, then the restrictive header can be removed because it was
> >> licensed to the ASF under a CLA. If no, then the file must be
> >> deleted
> >> until it can be properly licensed.
> >
> > Rémy
> >
> > ---------------------------------------------------------------------
> > 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
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 31, 2007, at 10:34 AM, Remy Maucherat wrote:
> Roy T. Fielding wrote:
>> On Jul 31, 2007, at 8:56 AM, Henri Yandell wrote:
>>> On 5/21/07, Kevan Miller <ke...@gmail.com> wrote:
>>>
>>>> I raised a similar issue on the Tomcat dev list some months back.
>>>> Tomcat contains Sun xsd's and dtd's (e.g. http://svn.apache.org/
>>>> repos/
>>>> asf/tomcat/trunk/java/javax/servlet/resources/j2ee_1_4.xsd)
>>>> which are
>>>> Sun copyright and contain the following restrictions of use:
>>>>
>>>> This document and the technology which it describes are
>>>> distributed under licenses restricting their use, copying,
>>>> distribution, and decompilation. No part of this document
>>>> may be reproduced in any form by any means without prior
>>>> written authorization of Sun and its licensors, if any.
>>>>
>>>> I was told that there might be documents in the Foundation svn
>>>> repository that grant Apache the right to redistribute these files.
>>>> I've never seen these documents, despite requesting the information
>>>> from Tomcat. Nor do I know how any rights granted by Sun to Apache
>>>> might transfer to a third party...
>>>
>>> Anyone have more info on this one?
>>>
>>> http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-
>>> jsp2.0-tc5.x/jsr154/src/share/dtd/web-app_2_4.xsd
>>>
>>> is an example of a file with both Apache permissive licensing, and a
>>> Sun extremely unpermissive header. It's come up in Freemarker as an
>>> issue:
>>>
>>> http://sourceforge.net/tracker/index.php?
>>> func=detail&aid=1754236&group_id=794&atid=100794
>>>
>>> Hen
>> Well, it would help if people did the homework instead of asking
>> the legal folks to do it for them. The above file was added by Remy
>> as part of
>> r266968 | remm | 2002-08-13 09:20:53 -0700 (Tue, 13 Aug 2002) | 2
>> lines
>> Remy, were you still an employee of Sun at that time? Was the file
>> contributed with the permission of Sun?
>
> I was still at Sun at this time, although I left soon after that. I
> was doing setup of the Tomcat 5.0.x repository on their behalf at
> the time, and would be fully supported by the other Sun employees
> working on Tomcat at the time.
>
> AFAIK, a version of these files without the problematic headers
> exists in the various specification documents.
This unfortunately doesn't help. The license for the specifications
is not an Apache-compatible license.
Craig
>
>> If yes, then the restrictive header can be removed because it was
>> licensed to the ASF under a CLA. If no, then the file must be
>> deleted
>> until it can be properly licensed.
>
> Rémy
>
> ---------------------------------------------------------------------
> 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
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Remy Maucherat <re...@apache.org>.
Roy T. Fielding wrote:
> On Jul 31, 2007, at 8:56 AM, Henri Yandell wrote:
>
>> On 5/21/07, Kevan Miller <ke...@gmail.com> wrote:
>>
>>> I raised a similar issue on the Tomcat dev list some months back.
>>> Tomcat contains Sun xsd's and dtd's (e.g. http://svn.apache.org/repos/
>>> asf/tomcat/trunk/java/javax/servlet/resources/j2ee_1_4.xsd) which are
>>> Sun copyright and contain the following restrictions of use:
>>>
>>> This document and the technology which it describes are
>>> distributed under licenses restricting their use, copying,
>>> distribution, and decompilation. No part of this document
>>> may be reproduced in any form by any means without prior
>>> written authorization of Sun and its licensors, if any.
>>>
>>> I was told that there might be documents in the Foundation svn
>>> repository that grant Apache the right to redistribute these files.
>>> I've never seen these documents, despite requesting the information
>>> from Tomcat. Nor do I know how any rights granted by Sun to Apache
>>> might transfer to a third party...
>>
>> Anyone have more info on this one?
>>
>> http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-tc5.x/jsr154/src/share/dtd/web-app_2_4.xsd
>>
>>
>> is an example of a file with both Apache permissive licensing, and a
>> Sun extremely unpermissive header. It's come up in Freemarker as an
>> issue:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1754236&group_id=794&atid=100794
>>
>>
>> Hen
>
> Well, it would help if people did the homework instead of asking
> the legal folks to do it for them. The above file was added by Remy
> as part of
>
> r266968 | remm | 2002-08-13 09:20:53 -0700 (Tue, 13 Aug 2002) | 2 lines
>
> Remy, were you still an employee of Sun at that time? Was the file
> contributed with the permission of Sun?
I was still at Sun at this time, although I left soon after that. I was
doing setup of the Tomcat 5.0.x repository on their behalf at the time,
and would be fully supported by the other Sun employees working on
Tomcat at the time.
AFAIK, a version of these files without the problematic headers exists
in the various specification documents.
> If yes, then the restrictive header can be removed because it was
> licensed to the ASF under a CLA. If no, then the file must be deleted
> until it can be properly licensed.
Rémy
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 31, 2007, at 8:56 AM, Henri Yandell wrote:
> On 5/21/07, Kevan Miller <ke...@gmail.com> wrote:
>
>> I raised a similar issue on the Tomcat dev list some months back.
>> Tomcat contains Sun xsd's and dtd's (e.g. http://svn.apache.org/
>> repos/
>> asf/tomcat/trunk/java/javax/servlet/resources/j2ee_1_4.xsd) which are
>> Sun copyright and contain the following restrictions of use:
>>
>> This document and the technology which it describes are
>> distributed under licenses restricting their use, copying,
>> distribution, and decompilation. No part of this document
>> may be reproduced in any form by any means without prior
>> written authorization of Sun and its licensors, if any.
>>
>> I was told that there might be documents in the Foundation svn
>> repository that grant Apache the right to redistribute these files.
>> I've never seen these documents, despite requesting the information
>> from Tomcat. Nor do I know how any rights granted by Sun to Apache
>> might transfer to a third party...
>
> Anyone have more info on this one?
>
> http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-
> tc5.x/jsr154/src/share/dtd/web-app_2_4.xsd
>
> is an example of a file with both Apache permissive licensing, and a
> Sun extremely unpermissive header. It's come up in Freemarker as an
> issue:
>
> http://sourceforge.net/tracker/index.php?
> func=detail&aid=1754236&group_id=794&atid=100794
>
> Hen
Well, it would help if people did the homework instead of asking
the legal folks to do it for them. The above file was added by Remy
as part of
r266968 | remm | 2002-08-13 09:20:53 -0700 (Tue, 13 Aug 2002) | 2 lines
Remy, were you still an employee of Sun at that time? Was the file
contributed with the permission of Sun?
If yes, then the restrictive header can be removed because it was
licensed to the ASF under a CLA. If no, then the file must be deleted
until it can be properly licensed.
....Roy
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jul 31, 2007, at 11:01 AM, Roy T. Fielding wrote:
> On Jul 31, 2007, at 10:40 AM, Craig L Russell wrote:
>
>> The checked-in file is clearly a mistake that should be researched
>> to see who erroneously added an Apache license to a clearly non-
>> Apache-licensed piece of work.
>
> The file was checked in by a Sun employee under the direction of Sun
> and licensed to the ASF under our CLA. As such, it came under our
> license in 2002 and the old Sun header should have been removed.
Having just been through the more general issue (many .xsd files with
suspicious licenses), I jumped to the conclusion that the file was
incorrectly re-licensed. I won't comment on that except to note that
most of such files were not licensed under the Apache license. But
they have been re-licensed under GPL and CDDL.
Craig
>
>> The file in question has been re-issued and relicensed by Sun
>> under GPL and CDDL. The checked-in file needs to be refreshed with
>> the version that Sun recently posted.
>>
>> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
>
> That is a different issue that the project can determine on its own.
>
> ....Roy
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 31, 2007, at 10:40 AM, Craig L Russell wrote:
> The checked-in file is clearly a mistake that should be researched
> to see who erroneously added an Apache license to a clearly non-
> Apache-licensed piece of work.
The file was checked in by a Sun employee under the direction of Sun
and licensed to the ASF under our CLA. As such, it came under our
license in 2002 and the old Sun header should have been removed.
> The file in question has been re-issued and relicensed by Sun under
> GPL and CDDL. The checked-in file needs to be refreshed with the
> version that Sun recently posted.
>
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
That is a different issue that the project can determine on its own.
....Roy
---------------------------------------------------------------------
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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
Posted by Craig L Russell <Cr...@Sun.COM>.
The checked-in file is clearly a mistake that should be researched to
see who erroneously added an Apache license to a clearly non-Apache-
licensed piece of work.
The file in question has been re-issued and relicensed by Sun under
GPL and CDDL. The checked-in file needs to be refreshed with the
version that Sun recently posted.
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd
Craig
On Jul 31, 2007, at 8:56 AM, Henri Yandell wrote:
> On 5/21/07, Kevan Miller <ke...@gmail.com> wrote:
>
>> I raised a similar issue on the Tomcat dev list some months back.
>> Tomcat contains Sun xsd's and dtd's (e.g. http://svn.apache.org/
>> repos/
>> asf/tomcat/trunk/java/javax/servlet/resources/j2ee_1_4.xsd) which are
>> Sun copyright and contain the following restrictions of use:
>>
>> This document and the technology which it describes are
>> distributed under licenses restricting their use, copying,
>> distribution, and decompilation. No part of this document
>> may be reproduced in any form by any means without prior
>> written authorization of Sun and its licensors, if any.
>>
>> I was told that there might be documents in the Foundation svn
>> repository that grant Apache the right to redistribute these files.
>> I've never seen these documents, despite requesting the information
>> from Tomcat. Nor do I know how any rights granted by Sun to Apache
>> might transfer to a third party...
>
> Anyone have more info on this one?
>
> http://svn.apache.org/repos/asf/tomcat/servletapi/servlet2.4-jsp2.0-
> tc5.x/jsr154/src/share/dtd/web-app_2_4.xsd
>
> is an example of a file with both Apache permissive licensing, and a
> Sun extremely unpermissive header. It's come up in Freemarker as an
> issue:
>
> http://sourceforge.net/tracker/index.php?
> func=detail&aid=1754236&group_id=794&atid=100794
>
> Hen
>
> ---------------------------------------------------------------------
> 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
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!