Re: Basing Apache releases on releases from incubating projects
- Original Message From: Owen O'Malley omal...@apache.org To: general@incubator.apache.org Sent: Wed, December 1, 2010 10:48:48 AM Subject: Basing Apache releases on releases from incubating projects In http://bit.ly/fhCxIt , Steve argued that it isn't permitted for non-podling releases to depend on the artifacts that come out of podlings. I believe that to be false, but I can't find a relevant statement in the FAQ. Can I get clarification? False (IMO). - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
I agree with Joe. a) I've been involved in a number of such releases. b) A podling can be evaluated for license compatibility like any external dependency -- but I don't see how a podling has any business making any releases before their IP clearance is pretty darn clear. --benson On Wed, Dec 1, 2010 at 10:51 AM, Joe Schaefer joe_schae...@yahoo.com wrote: - Original Message From: Owen O'Malley omal...@apache.org To: general@incubator.apache.org Sent: Wed, December 1, 2010 10:48:48 AM Subject: Basing Apache releases on releases from incubating projects In http://bit.ly/fhCxIt , Steve argued that it isn't permitted for non-podling releases to depend on the artifacts that come out of podlings. I believe that to be false, but I can't find a relevant statement in the FAQ. Can I get clarification? False (IMO). - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
On 12/1/2010 16:48, Owen O'Malley wrote: In http://bit.ly/fhCxIt , Steve argued that it isn't permitted for non-podling releases to depend on the artifacts that come out of podlings. I believe that to be false, but I can't find a relevant statement in the FAQ. Can I get clarification? This has been discussed in the past, see for example http://markmail.org/message/e76qmv5weevpqwc4 --Thilo Thanks, Owen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Owen, It's my understanding that Apache software can depend on other software that falls within the guidelines here [1]. ASF Podlings, by definition are software (released or not) that fall under the confines of Category A from [1], so it's fine to depend on them (again, *released* or not). Cheers, Chris [1] http://www.apache.org/legal/3party.html On Dec 1, 2010, at 7:48 AM, Owen O'Malley wrote: In http://bit.ly/fhCxIt , Steve argued that it isn't permitted for non- podling releases to depend on the artifacts that come out of podlings. I believe that to be false, but I can't find a relevant statement in the FAQ. Can I get clarification? Thanks, Owen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Benson Margulies bimargul...@gmail.com To: general@incubator.apache.org Sent: Wed, December 1, 2010 10:53:35 AM Subject: Re: Basing Apache releases on releases from incubating projects I agree with Joe. a) I've been involved in a number of such releases. b) A podling can be evaluated for license compatibility like any external dependency -- but I don't see how a podling has any business making any releases before their IP clearance is pretty darn clear. Right. Looking over Steve's argument I see he was referring to Thrift. ISTR issues around Thrift not having released and Cassandra (still in incubation) shipping Thrift jars, but that problem has been resolved (hopefully) by Cassandra only shipping Thrift releases instead of code from trunk. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 10:57:48 AM Subject: Re: Basing Apache releases on releases from incubating projects Hi Owen, It's my understanding that Apache software can depend on other software that falls within the guidelines here [1]. ASF Podlings, by definition are software (released or not) that fall under the confines of Category A from [1], so it's fine to depend on them (again, *released* or not). Not so fast. We don't require podlings to have their legal issues fully resolved until it's time to release, so other projects should *not* be shipping a podling's non-released codebase. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
On Dec 1, 2010, at 8:04 AM, Joe Schaefer wrote: - Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 10:57:48 AM Subject: Re: Basing Apache releases on releases from incubating projects Hi Owen, It's my understanding that Apache software can depend on other software that falls within the guidelines here [1]. ASF Podlings, by definition are software (released or not) that fall under the confines of Category A from [1], so it's fine to depend on them (again, *released* or not). Not so fast. We don't require podlings to have their legal issues fully resolved until it's time to release, so other projects should *not* be shipping a podling's non-released codebase. Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? So, I don't agree with your point. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
On 12/1/2010 17:38, Mattmann, Chris A (388J) wrote: On Dec 1, 2010, at 8:04 AM, Joe Schaefer wrote: - Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 10:57:48 AM Subject: Re: Basing Apache releases on releases from incubating projects Hi Owen, It's my understanding that Apache software can depend on other software that falls within the guidelines here [1]. ASF Podlings, by definition are software (released or not) that fall under the confines of Category A from [1], so it's fine to depend on them (again, *released* or not). Not so fast. We don't require podlings to have their legal issues fully resolved until it's time to release, so other projects should *not* be shipping a podling's non-released codebase. Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? The difference is that the incubator code comes from Apache, with all the ASF IP due diligence. If we use a third-party library that's under the AL, we mention that it's not from Apache. Our customers can then decide for themselves how much they trust that other source. My understanding. --Thilo So, I don't agree with your point. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 11:38:31 AM Subject: Re: Basing Apache releases on releases from incubating projects On Dec 1, 2010, at 8:04 AM, Joe Schaefer wrote: - Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 10:57:48 AM Subject: Re: Basing Apache releases on releases from incubating projects Hi Owen, It's my understanding that Apache software can depend on other software that falls within the guidelines here [1]. ASF Podlings, by definition are software (released or not) that fall under the confines of Category A from [1], so it's fine to depend on them (again, *released* or not). Not so fast. We don't require podlings to have their legal issues fully resolved until it's time to release, so other projects should *not* be shipping a podling's non-released codebase. Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? So, I don't agree with your point. The major issues with liability are always tied up in who releases stuff. We aren't all that liable for code we are redistributing from someone else's release. But we are liable for releasing code that is only being otherwise distributed out of our svn repo. Don't believe the remarks of Niclas and others who live in countries where all copyright infringement violators are subject to public stonings. In the US damages are assessed based on how many times and for what purpose those infringements are actually done. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Thilo, The difference is that the incubator code comes from Apache, with all the ASF IP due diligence. If we use a third-party library that's under the AL, we mention that it's not from Apache. Our customers can then decide for themselves how much they trust that other source. My understanding. Thanks, gotcha. Well, it would seem to me then that we could employ the same process to include Incubator code via the same fashion (e.g., via any number of existing mechanisms like NOTICE.txt, etc.) Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
On Wed, Dec 1, 2010 at 5:46 PM, Thilo Götz twgo...@gmx.de wrote: On 12/1/2010 17:38, Mattmann, Chris A (388J) wrote: ... Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? The difference is that the incubator code comes from Apache, with all the ASF IP due diligence. If we use a third-party library that's under the AL, we mention that it's not from Apache. Our customers can then decide for themselves how much they trust that other source. My understanding It is common for podlings to import their code here and only then start cleaning up dependencies that do not comply with ASF requirements. So if another project release contains unreleased code from a podling, it might not be clean. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hey Joe, Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? So, I don't agree with your point. The major issues with liability are always tied up in who releases stuff. We aren't all that liable for code we are redistributing from someone else's release. But we are liable for releasing code that is only being otherwise distributed out of our svn repo. Don't believe the remarks of Niclas and others who live in countries where all copyright infringement violators are subject to public stonings. In the US damages are assessed based on how many times and for what purpose those infringements are actually done. I hear ya, and I believe you have way more experience in this particular area than I do. I'm just saying that it would be nice if we could eat our own dog food in this particular accord, otherwise, what's the Incubator other than an Apache-branded area of code that's subject to *even stricter* guises. If you what you say is true, then it would seem to me that projects would benefit then from going to Google Code first, saying they are ASLv2 over there, and then being included over here in Apache projects (in source or binary form) -- they wouldn't be subject to the same scrutiny that our Incubator podlings are. But OTOH, it would be nice if we could reward Incubator podlings for choosing to do it the Apache Way to begin with by making some sort of easier mechanism for their code to be included in other Apache projects, right? After all the discussion about making it easier on podlings, I would hope we are striving to make this the reality. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Bertrand, The difference is that the incubator code comes from Apache, with all the ASF IP due diligence. If we use a third-party library that's under the AL, we mention that it's not from Apache. Our customers can then decide for themselves how much they trust that other source. My understanding It is common for podlings to import their code here and only then start cleaning up dependencies that do not comply with ASF requirements. So if another project release contains unreleased code from a podling, it might not be clean. In what way would it be any more unclean compared with including unreleased ASLv2 licensed code from e.g., Google Code or Sourceforge (which I've seen done before)? Why should we be holding *our own ASF podlings* to a higher accord as downstream dependencies and limiting the ability of downstream projects to include the great work being done in the Incubator? I simply don't agree with that. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
On 12/1/2010 17:56, Mattmann, Chris A (388J) wrote: Hey Joe, Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? So, I don't agree with your point. The major issues with liability are always tied up in who releases stuff. We aren't all that liable for code we are redistributing from someone else's release. But we are liable for releasing code that is only being otherwise distributed out of our svn repo. Don't believe the remarks of Niclas and others who live in countries where all copyright infringement violators are subject to public stonings. In the US damages are assessed based on how many times and for what purpose those infringements are actually done. I hear ya, and I believe you have way more experience in this particular area than I do. I'm just saying that it would be nice if we could eat our own dog food in this particular accord, otherwise, what's the Incubator other than an Apache-branded area of code that's subject to *even stricter* guises. If you what you say is true, then it would seem to me that projects would benefit then from going to Google Code first, saying they are ASLv2 over there, and then being included over here in Apache projects (in source or binary form) -- they wouldn't be subject to the same scrutiny that our Incubator podlings are. Oh but they are. I'm a committer on the new OpenNLP incubator project that's just starting up. It's Apache licensed, but that saves us nothing. We're doing a code grant, ICLAs from all current and previous contributors, etc etc, the whole nine yards. The fact that the code is already under the Apache license makes hardly any difference. --Thilo But OTOH, it would be nice if we could reward Incubator podlings for choosing to do it the Apache Way to begin with by making some sort of easier mechanism for their code to be included in other Apache projects, right? After all the discussion about making it easier on podlings, I would hope we are striving to make this the reality. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Thilo, I hear ya, and I believe you have way more experience in this particular area than I do. I'm just saying that it would be nice if we could eat our own dog food in this particular accord, otherwise, what's the Incubator other than an Apache-branded area of code that's subject to *even stricter* guises. If you what you say is true, then it would seem to me that projects would benefit then from going to Google Code first, saying they are ASLv2 over there, and then being included over here in Apache projects (in source or binary form) -- they wouldn't be subject to the same scrutiny that our Incubator podlings are. Oh but they are. I'm a committer on the new OpenNLP incubator project that's just starting up. It's Apache licensed, but that saves us nothing. I wouldn't agree with that, actually. It saves you a ton. Postulated scenario: You guys publish SNAPSHOT (unreleased JAR of OpenNLP) based on current source code available as downstream dependency at some Maven consumable site. I'm over here in Apache project X. I update my Apache project X to consume your SNAPSHOT OpenNLP jar from Google Code. That's just an example of where it might save you (and me from Apache project X that wants to depend on your ASLv2 licensed, unreleased Google Code whiz bang feature Y). We're doing a code grant, ICLAs from all current and previous contributors, etc etc, the whole nine yards. The fact that the code is already under the Apache license makes hardly any difference. Yep I've had to do this myself on several podlings. That's an IP issue more than anything else and just cleaner all around since you guys are doing a code drop over here at Apache, no? That said, IP is a little bit of a different beast (as are SGA or ICLA) than what I'm getting at. Basically what I'm saying is that if we've got ASF Incubator Podlings, that is, Apache branded code that isn't fully endorsed yet here at Apache yes, but that is *here at Apache*, then there should be some easier mechanism than making a release to include that good work going on in the ASF Incubator. Releases do not occur often enough in my experience to make it the gate to include an Incubator podling's code that is itself ASLv2 licensed. There should be an easier way (read: reward) for projects coming over here and being willing to do it our way, from the start. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 11:56:49 AM Subject: Re: Basing Apache releases on releases from incubating projects Hey Joe, Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? So, I don't agree with your point. The major issues with liability are always tied up in who releases stuff. We aren't all that liable for code we are redistributing from someone else's release. But we are liable for releasing code that is only being otherwise distributed out of our svn repo. Don't believe the remarks of Niclas and others who live in countries where all copyright infringement violators are subject to public stonings. In the US damages are assessed based on how many times and for what purpose those infringements are actually done. I hear ya, and I believe you have way more experience in this particular area than I do. I'm just saying that it would be nice if we could eat our own dog food in this particular accord, otherwise, what's the Incubator other than an Apache-branded area of code that's subject to *even stricter* guises. If you what you say is true, then it would seem to me that projects would benefit then from going to Google Code first, saying they are ASLv2 over there, and then being included over here in Apache projects (in source or binary form) -- they wouldn't be subject to the same scrutiny that our Incubator podlings are. True, but they also don't have the Foundation's corporate umbrella to protect them over at google code. When an ASF project releases code, the org accepts liability for it. That fact doesn't come for free; people are expected to do the appropriate due diligence themselves to *earn* that protection. But OTOH, it would be nice if we could reward Incubator podlings for choosing to do it the Apache Way to begin with by making some sort of easier mechanism for their code to be included in other Apache projects, right? After all the discussion about making it easier on podlings, I would hope we are striving to make this the reality. What's so hard about the release early, release often mantra? All we expect is that your releases are legally sound- once you pass that bar there are really no organizational issues to prevent you from releasing save for the formal 3 +1's from PMC members requirement. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
On Dec 1, 2010, at 8:51 AM, Bertrand Delacretaz wrote: It is common for podlings to import their code here and only then start cleaning up dependencies that do not comply with ASF requirements. So if another project release contains unreleased code from a podling, it might not be clean. In general, TLP releases shouldn't depend on unreleased artifacts of podlings or other TLP. As you point out unreleased podling artifacts are even more likely to be problematic. If someone wants to depend on it, their effort would probably be best spent helping the podling to release. But consensus seems to agree that TLP can depend on podling releases, right? -- Owen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hey Joe, But OTOH, it would be nice if we could reward Incubator podlings for choosing to do it the Apache Way to begin with by making some sort of easier mechanism for their code to be included in other Apache projects, right? After all the discussion about making it easier on podlings, I would hope we are striving to make this the reality. What's so hard about the release early, release often mantra? All we expect is that your releases are legally sound- once you pass that bar there are really no organizational issues to prevent you from releasing save for the formal 3 +1's from PMC members requirement. True dat. I guess I'm just thinking based on experience from watching podlings (including my own for a while but also others) it seems that releases don't occur as often as say me as a dev on some Apache project X that wants to include Incubator podling Y's new feature Z (ahhh alphabet soup!). I guess arguably if I live in Apache project X and I want that Incubator podling Y's feature Z, I could go over to that community and start pounding my chest (or better yet, pick up a shovel and help dig the hole to bury the release in). I just think it would be nice if it were easier than that. Not a huge deal though and I'm not the type of person to start a million email thread, so I'm happy to drop it. I think I can work the process by digging the hole or pounding my chest to get Podling Y to release (with feature Z) if I absolutely had to, though. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Chris, On 12/1/2010 18:08, Mattmann, Chris A (388J) wrote: Hi Thilo, I hear ya, and I believe you have way more experience in this particular area than I do. I'm just saying that it would be nice if we could eat our own dog food in this particular accord, otherwise, what's the Incubator other than an Apache-branded area of code that's subject to *even stricter* guises. If you what you say is true, then it would seem to me that projects would benefit then from going to Google Code first, saying they are ASLv2 over there, and then being included over here in Apache projects (in source or binary form) -- they wouldn't be subject to the same scrutiny that our Incubator podlings are. Oh but they are. I'm a committer on the new OpenNLP incubator project that's just starting up. It's Apache licensed, but that saves us nothing. I wouldn't agree with that, actually. It saves you a ton. Postulated scenario: You guys publish SNAPSHOT (unreleased JAR of OpenNLP) based on current source code available as downstream dependency at some Maven consumable site. I'm over here in Apache project X. I update my Apache project X to consume your SNAPSHOT OpenNLP jar from Google Code. That's just an example of where it might save you (and me from Apache project X that wants to depend on your ASLv2 licensed, unreleased Google Code whiz bang feature Y). Is it just me, or have we come full circle ;-) We're doing a code grant, ICLAs from all current and previous contributors, etc etc, the whole nine yards. The fact that the code is already under the Apache license makes hardly any difference. Yep I've had to do this myself on several podlings. That's an IP issue more than anything else and just cleaner all around since you guys are doing a code drop over here at Apache, no? That said, IP is a little bit of a different beast (as are SGA or ICLA) than what I'm getting at. Basically what I'm saying is that if we've got ASF Incubator Podlings, that is, Apache branded code that isn't fully endorsed yet here at Apache yes, but that is *here at Apache*, then there should be some easier mechanism than making a release to include that good work going on in the ASF Incubator. Releases do not occur often enough in my experience to make it the gate to include an Incubator podling's code that is itself ASLv2 licensed. There should be an easier way (read: reward) for projects coming over here and being willing to do it our way, from the start. But it's all about IP. We're releasing under the Apache license. That license makes some pretty strong claims about the code. The ASF needs to be able to defend these claims in a court of law, so that's not a minor thing. If some guys somewhere distribute their code under the Apache license but never really think about what that means, well, that's their problem. --Thilo Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hey Thilo, Is it just me, or have we come full circle ;-) LOL, yep! We're doing a code grant, ICLAs from all current and previous contributors, etc etc, the whole nine yards. The fact that the code is already under the Apache license makes hardly any difference. Yep I've had to do this myself on several podlings. That's an IP issue more than anything else and just cleaner all around since you guys are doing a code drop over here at Apache, no? That said, IP is a little bit of a different beast (as are SGA or ICLA) than what I'm getting at. Basically what I'm saying is that if we've got ASF Incubator Podlings, that is, Apache branded code that isn't fully endorsed yet here at Apache yes, but that is *here at Apache*, then there should be some easier mechanism than making a release to include that good work going on in the ASF Incubator. Releases do not occur often enough in my experience to make it the gate to include an Incubator podling's code that is itself ASLv2 licensed. There should be an easier way (read: reward) for projects coming over here and being willing to do it our way, from the start. But it's all about IP. We're releasing under the Apache license. That license makes some pretty strong claims about the code. The ASF needs to be able to defend these claims in a court of law, so that's not a minor thing. If some guys somewhere distribute their code under the Apache license but never really think about what that means, well, that's their problem. But, unfortunately this happens all the time and saying it's their problem doesn't remedy the situation that it happens all the time :( I guess if I could boil down my position to a single sentence it would be: It would be nice if Apache projects had a mechanism other than 'release the podling' to include podling (possibly unreleased) features in their own Apache projects. In effect this makes it very easy to 'eat our Apache Incubator podling dogfood and reward the podlings for trying to do the Apache Way from the start, rather than going to some other OSS provider and then coming here later. Maybe the answer here is that Apache Labs is already doing this (dunno), but it would be nice (but not strictly required since it's my take on it and I took off my BDFL belt the other day ^_^) if the Incubator was too. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Just about the most important thing a podling does is release. We shouldn't need mechanisms to ease the use of unreleased podling code. In my opinion. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Joe, than going to some other OSS provider and then coming here later. You're confused about the whole point of releases at Apache. They aren't necessarily meant to offer any promises about stability or suitability for a given purpose, they are simply meant as a means of getting the code out the door in a formal and responsible way (given that we *are* a corporation). Too many projects fail to release alpha and beta quality code, and that's not the org's, nor the Incubator's, fault. Not sure I'm confused, just poking actually, but near the end of my poking. Question: if podlings fail to make a release, but still have code checked into our Apache SVN and say they've went through a code grant, they've done ICLAs for all the committers, and everything looks OK, but the community dies, then how can folks depend on that code if it's got some nice features they want to include? What's the barrier there? The code is in our SVN, it's licensed using our license, there's been some diligence to check it (but maybe not full, etc.), etc. Anyhoo a lot of this is moot if the person is just willing to work the process to try and help make the podling release. But that doesn't work in all cases. There are some communities I can push on/help/etc., as much as I can, and they still won't make the release, that's just the nature of the beast. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
+1 also when considering the other options. Some of those incubator projects are JSR impls. And would you like to depend on a LGPL licensed external library instead? LieGrue, strub --- On Wed, 12/1/10, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov Subject: Re: Basing Apache releases on releases from incubating projects To: general@incubator.apache.org general@incubator.apache.org Date: Wednesday, December 1, 2010, 3:57 PM Hi Owen, It's my understanding that Apache software can depend on other software that falls within the guidelines here [1]. ASF Podlings, by definition are software (released or not) that fall under the confines of Category A from [1], so it's fine to depend on them (again, *released* or not). Cheers, Chris [1] http://www.apache.org/legal/3party.html On Dec 1, 2010, at 7:48 AM, Owen O'Malley wrote: In http://bit.ly/fhCxIt , Steve argued that it isn't permitted for non- podling releases to depend on the artifacts that come out of podlings. I believe that to be false, but I can't find a relevant statement in the FAQ. Can I get clarification? Thanks, Owen - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 1:14:03 PM Subject: Re: Basing Apache releases on releases from incubating projects Hi Joe, than going to some other OSS provider and then coming here later. You're confused about the whole point of releases at Apache. They aren't necessarily meant to offer any promises about stability or suitability for a given purpose, they are simply meant as a means of getting the code out the door in a formal and responsible way (given that we *are* a corporation). Too many projects fail to release alpha and beta quality code, and that's not the org's, nor the Incubator's, fault. Not sure I'm confused, just poking actually, but near the end of my poking. Question: if podlings fail to make a release, but still have code checked into our Apache SVN and say they've went through a code grant, they've done ICLAs for all the committers, and everything looks OK, but the community dies, then how can folks depend on that code if it's got some nice features they want to include? What's the barrier there? The code is in our SVN, it's licensed using our license, there's been some diligence to check it (but maybe not full, etc.), etc. This is not an academic question. Ask Dims how things worked for Geronimo when they had such a dependency. Basically the expectation is that the dependent project will check the code into their own tree and finish whatever vetting needs to take place. It then becomes a part of *their* release process, not treated as an external dependency (how they bundle that software doesn't really matter). Anyhoo a lot of this is moot if the person is just willing to work the process to try and help make the podling release. But that doesn't work in all cases. There are some communities I can push on/help/etc., as much as I can, and they still won't make the release, that's just the nature of the beast. IMO part of the problem is that we still treat the IPMC as a bunch of super-special people with very-special responsibilities. Podlings tend to look at releases as a PITA because it's a hoop-jumping exercise performed at the behest of the IPMC, instead of something innately in their own best interests. My solution is to identify, as early as possible, people within the projects who both know the codebase and will perform competent review of commits and releases. Those people belong on the IPMC, and if we really took the vetting process seriously that's how things would work. Successful release managers are almost always natural candidates for IPMC membership. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Thilo, the point is that any mentor, champion or in other form involved ASF member MUST NOT give his +1 to any incubator RELEASE vote which is not IP clear! It might be that incubator snapshots are not IP cleared yet, but there is certainly a much higher grade of review in any incubator _release_. Otherwise we would have to introduce a new 'Apache Incubator Software License' or kind of weird construct when shipping incubator releases... LieGrue, strub --- On Wed, 12/1/10, Thilo Götz twgo...@gmx.de wrote: From: Thilo Götz twgo...@gmx.de Subject: Re: Basing Apache releases on releases from incubating projects To: general@incubator.apache.org Date: Wednesday, December 1, 2010, 5:01 PM On 12/1/2010 17:56, Mattmann, Chris A (388J) wrote: Hey Joe, Hrm, umm, so what's the difference between this, and oh I don't know, some other library I pick up as a TLP off Google code who claims their source is ASLv2 licensed? I have no guarantee over there that the license issues are resolved either, yet we do that all the time over here in Apache? So, I don't agree with your point. The major issues with liability are always tied up in who releases stuff. We aren't all that liable for code we are redistributing from someone else's release. But we are liable for releasing code that is only being otherwise distributed out of our svn repo. Don't believe the remarks of Niclas and others who live in countries where all copyright infringement violators are subject to public stonings. In the US damages are assessed based on how many times and for what purpose those infringements are actually done. I hear ya, and I believe you have way more experience in this particular area than I do. I'm just saying that it would be nice if we could eat our own dog food in this particular accord, otherwise, what's the Incubator other than an Apache-branded area of code that's subject to *even stricter* guises. If you what you say is true, then it would seem to me that projects would benefit then from going to Google Code first, saying they are ASLv2 over there, and then being included over here in Apache projects (in source or binary form) -- they wouldn't be subject to the same scrutiny that our Incubator podlings are. Oh but they are. I'm a committer on the new OpenNLP incubator project that's just starting up. It's Apache licensed, but that saves us nothing. We're doing a code grant, ICLAs from all current and previous contributors, etc etc, the whole nine yards. The fact that the code is already under the Apache license makes hardly any difference. --Thilo But OTOH, it would be nice if we could reward Incubator podlings for choosing to do it the Apache Way to begin with by making some sort of easier mechanism for their code to be included in other Apache projects, right? After all the discussion about making it easier on podlings, I would hope we are striving to make this the reality. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hey Joe, I agree with pretty much everything you said below. One good thing (and correct me if I'm wrong) but is that I interpret what you are saying here: This is not an academic question. Ask Dims how things worked for Geronimo when they had such a dependency. Basically the expectation is that the dependent project will check the code into their own tree and finish whatever vetting needs to take place. It then becomes a part of *their* release process, not treated as an external dependency (how they bundle that software doesn't really matter). to mean that it's the decision of the project who is including the dependency's source code in their own source code (and that is a mechanism to achieve what I'm proposing). If that's what you are saying then I agree. Even if that's not, I think I more or less am fine with what you're saying and sorry for causing everyone the email spam! I'm putting my head back down to work for the rest of the day! :) Cheers, Chris On Dec 1, 2010, at 10:24 AM, Joe Schaefer wrote: - Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 1:14:03 PM Subject: Re: Basing Apache releases on releases from incubating projects Hi Joe, than going to some other OSS provider and then coming here later. You're confused about the whole point of releases at Apache. They aren't necessarily meant to offer any promises about stability or suitability for a given purpose, they are simply meant as a means of getting the code out the door in a formal and responsible way (given that we *are* a corporation). Too many projects fail to release alpha and beta quality code, and that's not the org's, nor the Incubator's, fault. Not sure I'm confused, just poking actually, but near the end of my poking. Question: if podlings fail to make a release, but still have code checked into our Apache SVN and say they've went through a code grant, they've done ICLAs for all the committers, and everything looks OK, but the community dies, then how can folks depend on that code if it's got some nice features they want to include? What's the barrier there? The code is in our SVN, it's licensed using our license, there's been some diligence to check it (but maybe not full, etc.), etc. This is not an academic question. Ask Dims how things worked for Geronimo when they had such a dependency. Basically the expectation is that the dependent project will check the code into their own tree and finish whatever vetting needs to take place. It then becomes a part of *their* release process, not treated as an external dependency (how they bundle that software doesn't really matter). Anyhoo a lot of this is moot if the person is just willing to work the process to try and help make the podling release. But that doesn't work in all cases. There are some communities I can push on/help/etc., as much as I can, and they still won't make the release, that's just the nature of the beast. IMO part of the problem is that we still treat the IPMC as a bunch of super-special people with very-special responsibilities. Podlings tend to look at releases as a PITA because it's a hoop-jumping exercise performed at the behest of the IPMC, instead of something innately in their own best interests. My solution is to identify, as early as possible, people within the projects who both know the codebase and will perform competent review of commits and releases. Those people belong on the IPMC, and if we really took the vetting process seriously that's how things would work. Successful release managers are almost always natural candidates for IPMC membership. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov To: general@incubator.apache.org general@incubator.apache.org Sent: Wed, December 1, 2010 1:42:47 PM Subject: Re: Basing Apache releases on releases from incubating projects Hey Joe, I agree with pretty much everything you said below. One good thing (and correct me if I'm wrong) but is that I interpret what you are saying here: This is not an academic question. Ask Dims how things worked for Geronimo when they had such a dependency. Basically the expectation is that the dependent project will check the code into their own tree and finish whatever vetting needs to take place. It then becomes a part of *their* release process, not treated as an external dependency (how they bundle that software doesn't really matter). to mean that it's the decision of the project who is including the dependency's source code in their own source code (and that is a mechanism to achieve what I'm proposing). If that's what you are saying then I agree. Even if that's not, I think I more or less am fine with what you're saying and sorry for causing everyone the email spam! I'm putting my head back down to work for the rest of the day! :) There is a practical difference here between what Geronimo did in their situation and what say Cassandra did with Thrift pre-release. Cassandra didn't work to do any vetting of the Thrift codebase, they just packaged up a jar rolled from trunk and put it up for inclusion in their release as an external dependency. The IPMC approved those releases without ever ascertaining whether the Thrift codebase in the Cassandra release had been vetted- and I know for a fact that it wasn't completely right. That's not a practice I'd like to see condoned going forward. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
Hi Chris, On Wed, Dec 1, 2010 at 7:42 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Joe, I agree with pretty much everything you said below. One good thing (and correct me if I'm wrong) but is that I interpret what you are saying here: This is not an academic question. Ask Dims how things worked for Geronimo when they had such a dependency. Basically the expectation is that the dependent project will check the code into their own tree and finish whatever vetting needs to take place. It then becomes a part of *their* release process, not treated as an external dependency (how they bundle that software doesn't really matter). to mean that it's the decision of the project who is including the dependency's source code in their own source code (and that is a mechanism to achieve what I'm proposing). If that's what you are saying then I agree... FWIW I agree with this - if a project includes unreleased code from another ASF project in their release, they take responsibility for that. If the included code comes from a podling, that's usually more risky than from a graduated project. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Bertrand Delacretaz bdelacre...@apache.org To: general@incubator.apache.org Sent: Wed, December 1, 2010 2:18:50 PM Subject: Re: Basing Apache releases on releases from incubating projects Hi Chris, On Wed, Dec 1, 2010 at 7:42 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hey Joe, I agree with pretty much everything you said below. One good thing (and correct me if I'm wrong) but is that I interpret what you are saying here: This is not an academic question. Ask Dims how things worked for Geronimo when they had such a dependency. Basically the expectation is that the dependent project will check the code into their own tree and finish whatever vetting needs to take place. It then becomes a part of *their* release process, not treated as an external dependency (how they bundle that software doesn't really matter). to mean that it's the decision of the project who is including the dependency's source code in their own source code (and that is a mechanism to achieve what I'm proposing). If that's what you are saying then I agree... FWIW I agree with this - if a project includes unreleased code from another ASF project in their release, they take responsibility for that. It's all the same org, so I don't see how they can take responsibility for anything. The whole point of the corporation is to shield people from liability, not to expose volunteers for taking on responsibility for code they aren't chartered to be developing and distributing. Releasing legally-vetted code is an organizational requirement, and a project's svn trunk is in a constant state of flux. Releases are the only distribution points we have that we are reasonably certain about their legal status. It should be up to each project to determine what and when it's appropriate to have their code released. If a project isn't performing releases as fast as you'd like, get involved in their community and help them release it. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Basing Apache releases on releases from incubating projects
- Original Message From: Owen O'Malley omal...@apache.org To: general@incubator.apache.org Sent: Wed, December 1, 2010 12:15:51 PM Subject: Re: Basing Apache releases on releases from incubating projects On Dec 1, 2010, at 8:51 AM, Bertrand Delacretaz wrote: It is common for podlings to import their code here and only then start cleaning up dependencies that do not comply with ASF requirements. So if another project release contains unreleased code from a podling, it might not be clean. In general, TLP releases shouldn't depend on unreleased artifacts of podlings or other TLP. As you point out unreleased podling artifacts are even more likely to be problematic. If someone wants to depend on it, their effort would probably be best spent helping the podling to release. But consensus seems to agree that TLP can depend on podling releases, right? +1. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
