Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
On 8/4/07, David Jencks [EMAIL PROTECTED] 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
Re: SUN PROPRIETARY/CONFIDENTIAL code in myfaces
On 8/4/07, David Jencks [EMAIL PROTECTED] 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: ActiveMQ Graduation From Incubator
Dain Sundstrom wrote: On Mar 13, 2006, at 5:05 PM, Rodent of Unusual Size wrote: Dain Sundstrom wrote: I understand this concern and agree with the solution, but we should remember that AMQ entered the incubator before this was a rule, so I for one didn't think it appled to them, since they are so close to graduation. 'So close to graduation'? Whence comes that? I think that proximity is still very much up in the air, particularly given Noel's opinion that If you read the email history, you will see that it was stated that the new rules would only apply to projects close to gradation. So I hope you can see my point, regardless of if you agree with that point. .. and the ASF community building is only just getting started. No PPMC, yet, for which we need more Mentors. These have nothing to do with when it entered incubation; the need for a PPMC has been there right along, and the 'ASF community building' is a sine qua non. (I have no opinion, myself, about the degree of 'ASF community building' that has occurred in ActiveMQ.) When AMQ entered the incubator as a sponsored project from Geronimo, the current understanding of incubator rules was that AMQ would simply use the Geronimo pmc since the Geronimo pmc is expected to be the home for the project. Since then the incubator rules have been rewritten several time and based on the emails I saw today, the current rules that Noel is promoting (3+ mentors) hasn't even be approved by the incubator. I personally find this incredibly frustrating, so please take my comments with a grain of salt. If you ask me setting up a separate pmc for these projects is an incrediably bad idea. Our objective is to create a single community between Geronimo, ActiveMQ, OpenEJB, ServiceMix and WADI. Putting these projects into separate boxes makes this very difficult. I would like to know, why have the incubator rules changed to, in my opinion, force all projects TLP? Maybe the incubator is the wrong place to bring these types projects. Is there another process to bring in a project we plan on integrating? If not, maybe the board should consider setting something else up. If you love someone, set them free. If they come back they're yours; if they don't they never were I firmly believe that the destination for a code base should be determined at the EXIT of incubation. If each and every one of these ultimately ends up at Geronimo by general consent of all the parties involved, then (by definition) everybody is happy. What I am unconfortable with is codebases being proposed with a precondition being placed on where they land. A sponsor is needed to inject a bit of accountability into the process, and to reduce the tendency towards the ASF becoming a sourceforge with lots of abandoned projects. But that pretty much is the extent of sponsorship. Every code base should be looked at with the possibility of being a TLP. And with the possibility of being incorporated within an existing project. Saying I want ActiveMQ at the ASF, and saying I think ActiveMQ would make a fine addition to Geronimo are both reasonable things to say. Saying I want ActiveMQ at the ASF, but only if it is destined to be a part of Geronimo is not. - Sam Ruby
