Re: [DISCUSS] Policy blocker?
On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Folks since the liability of Release manager has been called out explicitly for the release I want to call out that I cannot take personal liability for a release and I am not sure why would anyone else in Release Manager role will take up personal liability. I don't see anything called out in our bylaws that states Release Manager being liable. That being said I am seeking advice from ASF mentors and will discuss it in PMC. I will proceed and build an RC after this issue is resolved. Thanks Animesh A couple of things: First, we don't have any mentors anymore... we're a TLP. Second, although the question of liability has been clarified in the private@ thread, I'll summarize briefly here: The reason that we follow the voting process (where the PMC votes are binding) and other ASF-wide policies, is so that any release is an act of the foundation and not an act of an individual. The point is that if someone were to purposefully ignore policy, then they put themselves at risk. The whole reason for the foundation to have it's policies is to protect all of the committers and contributors from personal liability! So the only thing that really matters is that if we follow the policies of the foundation, there's nothing to worry about. Being a release manager is nothing to worry about... the whole PMC is helping to ensure that we follow policies. As our current 4.3 issue has pointed out, sometimes this means we have to slow down to fix something. If something slipped through, it's still not a liability issue in practical terms. It's just a mistake that we would then work to correct. Make sense? -chip
Re: [DISCUSS] Policy blocker?
+1 well put. On Feb 26, 2014, at 6:44 AM, Chip Childers chipchild...@apache.org wrote: On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Folks since the liability of Release manager has been called out explicitly for the release I want to call out that I cannot take personal liability for a release and I am not sure why would anyone else in Release Manager role will take up personal liability. I don't see anything called out in our bylaws that states Release Manager being liable. That being said I am seeking advice from ASF mentors and will discuss it in PMC. I will proceed and build an RC after this issue is resolved. Thanks Animesh A couple of things: First, we don't have any mentors anymore... we're a TLP. Second, although the question of liability has been clarified in the private@ thread, I'll summarize briefly here: The reason that we follow the voting process (where the PMC votes are binding) and other ASF-wide policies, is so that any release is an act of the foundation and not an act of an individual. The point is that if someone were to purposefully ignore policy, then they put themselves at risk. The whole reason for the foundation to have it's policies is to protect all of the committers and contributors from personal liability! So the only thing that really matters is that if we follow the policies of the foundation, there's nothing to worry about. Being a release manager is nothing to worry about... the whole PMC is helping to ensure that we follow policies. As our current 4.3 issue has pointed out, sometimes this means we have to slow down to fix something. If something slipped through, it's still not a liability issue in practical terms. It's just a mistake that we would then work to correct. Make sense? -chip
Re: [DISCUSS] Policy blocker?
+1 this is reasonable. On 26/02/14 8:14 pm, Chip Childers chipchild...@apache.org wrote: On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Folks since the liability of Release manager has been called out explicitly for the release I want to call out that I cannot take personal liability for a release and I am not sure why would anyone else in Release Manager role will take up personal liability. I don't see anything called out in our bylaws that states Release Manager being liable. That being said I am seeking advice from ASF mentors and will discuss it in PMC. I will proceed and build an RC after this issue is resolved. Thanks Animesh A couple of things: First, we don't have any mentors anymore... we're a TLP. Second, although the question of liability has been clarified in the private@ thread, I'll summarize briefly here: The reason that we follow the voting process (where the PMC votes are binding) and other ASF-wide policies, is so that any release is an act of the foundation and not an act of an individual. The point is that if someone were to purposefully ignore policy, then they put themselves at risk. The whole reason for the foundation to have it's policies is to protect all of the committers and contributors from personal liability! So the only thing that really matters is that if we follow the policies of the foundation, there's nothing to worry about. Being a release manager is nothing to worry about... the whole PMC is helping to ensure that we follow policies. As our current 4.3 issue has pointed out, sometimes this means we have to slow down to fix something. If something slipped through, it's still not a liability issue in practical terms. It's just a mistake that we would then work to correct. Make sense? -chip
Re: [DISCUSS] Policy blocker?
On Wed, Feb 26, 2014 at 4:24 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: I am still not convinced or comfortable with release manager's liability for release content. It seems we are going with practical approach but since legality has been called out the legal instrument needs to be clearly defined. I will respond pack in private with more clarification Think of it this way (but remember INAL): If you do something for your $dayjob, if it's done as part of your job and done following your company's policies, your corporation (I would hope) protect you. That's because you are doing something you are authorized to do on behalf of your corporation. Similarly, we follow ASF policies and procedures so that things we do in our project are something that the foundation considers an act of the foundation. Anyway, happy to discuss in private as well... -chip
RE: [DISCUSS] Policy blocker?
Folks since the liability of Release manager has been called out explicitly for the release I want to call out that I cannot take personal liability for a release and I am not sure why would anyone else in Release Manager role will take up personal liability. I don't see anything called out in our bylaws that states Release Manager being liable. That being said I am seeking advice from ASF mentors and will discuss it in PMC. I will proceed and build an RC after this issue is resolved. Thanks Animesh -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Saturday, February 22, 2014 12:34 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Sat, Feb 22, 2014 at 3:07 AM, Sebastien Goasguen run...@gmail.com wrote: On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 4:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. [Animesh] How do you define the release process being followed or not? Isn't Voting on a release the process and PMC and everyone voting responsible for it. Release Manager is a facilitator. Without the protection why would anyone want to incur liability as a release manager? In the links that you sent I have not seen specific reference to Release Manager being liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. [Animesh] What does foundation provide in that case? I read David note as saying that if we follow the release process properly - calling for votes, respecting bylaws timeframe, tallying...etc- then the ASF is liable for what's in the release. But if we were to not follow due process then the RM would be liable. In our case we follow process, so the Foundation is liable. Yes, if I wasn't clear - what Sebastien said was my intent. --David
Re: [DISCUSS] Policy blocker?
Guys, I did a quick check using the scanner at http://www.sonatype.com/application-health-check. According to that report we need to do some additional checking of our dependencies. Licenses: Copyleft: 2 Non-standard: 9 Weak-copyleft: 15 Liberal: 82 I can’t get the exact details as that requires the full report ($499 ouch..), but at least it warrants investigation before we can release. Here is the printout of the report: https://dl.dropboxusercontent.com/u/70226362/app-check.pdf Cheers, Hugo On 23 feb. 2014, at 07:24, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Hi David, One doubt, while building cloudstack we are using mysql-connector-java version 5.1.29; is it not mandatory we should supposed to use same version of mysql-connector during run time? Regards, Rayees -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Saturday, February 22, 2014 7:59 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? Hi folks: I think this issue is resolved in the 4.3 branch. The default build system no longer seems to grab the mysql jar, and I've adjusted tomcat to load the mysql jar from the system library. Commit 0c2ad0338e34f6117cecc24ec00c7746dd481465 should have the necessary changes. I did some quick testing, and this seems to work, but obviously it needs more eyes and testing. --David On Thu, Feb 20, 2014 at 8:37 AM, David Nalley da...@gnsa.us wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html
Re: [DISCUSS] Policy blocker?
Just to be thorough, is using provided scope good enough? Sure it doesn't pull it into the final product and isn't in transitive dependencies, but it is still downloaded for the compile process. From your previous emails, it sounded like we can not download it whatsoever during the build. Building cloud-framework-db still downloads the jar to build that specific sub project (Just validated off of latest 4.3), which is necessary for the overall project build. Not trying to be a pain, just trying to make sure we don't miss something, but I could be misunderstanding the situation. Thanks, -Nate On Mon, Feb 24, 2014 at 9:53 AM, Hugo Trippaers h...@trippaers.nl wrote: Guys, I did a quick check using the scanner at http://www.sonatype.com/application-health-check. According to that report we need to do some additional checking of our dependencies. Licenses: Copyleft: 2 Non-standard: 9 Weak-copyleft: 15 Liberal: 82 I can't get the exact details as that requires the full report ($499 ouch..), but at least it warrants investigation before we can release. Here is the printout of the report: https://dl.dropboxusercontent.com/u/70226362/app-check.pdf Cheers, Hugo On 23 feb. 2014, at 07:24, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Hi David, One doubt, while building cloudstack we are using mysql-connector-java version 5.1.29; is it not mandatory we should supposed to use same version of mysql-connector during run time? Regards, Rayees -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Saturday, February 22, 2014 7:59 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? Hi folks: I think this issue is resolved in the 4.3 branch. The default build system no longer seems to grab the mysql jar, and I've adjusted tomcat to load the mysql jar from the system library. Commit 0c2ad0338e34f6117cecc24ec00c7746dd481465 should have the necessary changes. I did some quick testing, and this seems to work, but obviously it needs more eyes and testing. --David On Thu, Feb 20, 2014 at 8:37 AM, David Nalley da...@gnsa.us wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html -- *Nate Gordon*Director of Technology | Appcore - the business of cloud computing(R) Office +1.800.735.7104 | Direct +1.515.612.7787 nate.gor...@appcore.com | www.appcore.com -- The information in this message is intended for the named recipients only. It may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message is strictly prohibited. If you have received this e-mail in error, do not print it or disseminate it or its contents. In such event, please notify the sender by return e-mail and delete the e-mail file immediately thereafter. Thank you.
Re: [DISCUSS] Policy blocker?
On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 4:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. [Animesh] How do you define the release process being followed or not? Isn't Voting on a release the process and PMC and everyone voting responsible for it. Release Manager is a facilitator. Without the protection why would anyone want to incur liability as a release manager? In the links that you sent I have not seen specific reference to Release Manager being liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. [Animesh] What does foundation provide in that case? I read David note as saying that if we follow the release process properly -calling for votes, respecting bylaws timeframe, tallying…etc- then the ASF is liable for what's in the release. But if we were to not follow due process then the RM would be liable. In our case we follow process, so the Foundation is liable. http://www.apache.org/dev/release.html#why https://www.apache.org/foundation/faq.html#why --David
Re: [DISCUSS] Policy blocker?
On Sat, Feb 22, 2014 at 3:07 AM, Sebastien Goasguen run...@gmail.com wrote: On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 4:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. [Animesh] How do you define the release process being followed or not? Isn't Voting on a release the process and PMC and everyone voting responsible for it. Release Manager is a facilitator. Without the protection why would anyone want to incur liability as a release manager? In the links that you sent I have not seen specific reference to Release Manager being liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. [Animesh] What does foundation provide in that case? I read David note as saying that if we follow the release process properly -calling for votes, respecting bylaws timeframe, tallying...etc- then the ASF is liable for what's in the release. But if we were to not follow due process then the RM would be liable. In our case we follow process, so the Foundation is liable. Yes, if I wasn't clear - what Sebastien said was my intent. --David
Re: [DISCUSS] Policy blocker?
Hi folks: I think this issue is resolved in the 4.3 branch. The default build system no longer seems to grab the mysql jar, and I've adjusted tomcat to load the mysql jar from the system library. Commit 0c2ad0338e34f6117cecc24ec00c7746dd481465 should have the necessary changes. I did some quick testing, and this seems to work, but obviously it needs more eyes and testing. --David On Thu, Feb 20, 2014 at 8:37 AM, David Nalley da...@gnsa.us wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html
RE: [DISCUSS] Policy blocker?
Hi David, One doubt, while building cloudstack we are using mysql-connector-java version 5.1.29; is it not mandatory we should supposed to use same version of mysql-connector during run time? Regards, Rayees -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Saturday, February 22, 2014 7:59 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? Hi folks: I think this issue is resolved in the 4.3 branch. The default build system no longer seems to grab the mysql jar, and I've adjusted tomcat to load the mysql jar from the system library. Commit 0c2ad0338e34f6117cecc24ec00c7746dd481465 should have the necessary changes. I did some quick testing, and this seems to work, but obviously it needs more eyes and testing. --David On Thu, Feb 20, 2014 at 8:37 AM, David Nalley da...@gnsa.us wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html
Re: [DISCUSS] Policy blocker?
On Feb 20, 2014, at 10:33 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: I find a little ironic that the internal policies are a lot more restrictive than the Apache license itself :S Meanwhile, isn't CloudStack falling into the MySQL FOSS exception? http://www.mysql.com/about/legal/licensing/foss-exception/ Reading it, it sure sounds like it. -sebastien Francois On 2/20/2014, 9:20 PM, David Nalley wrote: On Thu, Feb 20, 2014 at 9:10 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: I may be wrong here, and far from being an expert at this, but isn't the MariaDB connector doing the same thing, but under a Lesser GPL license? Which would solve a lot of licensing issues (no need to put CloudStack entirely on GPL). FG Hi Francois: L/GPL is also Cat X according to ASF Policy, and thus isn't effectively any better. --David -- Francois Gaudreault Architecte de Solution Cloud | Cloud Solutions Architect fgaudrea...@cloudops.com 514-629-6775 - - - CloudOps 420 rue Guy Montréal QC H3J 1S6 www.cloudops.com @CloudOps_
RE: [DISCUSS] Policy blocker?
For DB HA we have included a new class StaticStrategy.java which is having compile time dependency on mysql -connector-java. I will make change in pom, as provided scope dependency instead of compile time so that maven will not include in the bundle while packaging. Thanks Regards Damodar/ -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 12:24 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip For those following along at home, here are some relevant links: http://www.apache.org/legal/resolved.html http://www.apache.org/dev/licensing-howto.html
Re: [DISCUSS] Policy blocker?
FOSS seems to apply to us but the question is whether Apache recognises that. On Fri, Feb 21, 2014 at 10:40 AM, Sebastien Goasguen run...@gmail.com wrote: On Feb 20, 2014, at 10:33 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: I find a little ironic that the internal policies are a lot more restrictive than the Apache license itself :S Meanwhile, isn't CloudStack falling into the MySQL FOSS exception? http://www.mysql.com/about/legal/licensing/foss-exception/ Reading it, it sure sounds like it. -sebastien Francois On 2/20/2014, 9:20 PM, David Nalley wrote: On Thu, Feb 20, 2014 at 9:10 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: I may be wrong here, and far from being an expert at this, but isn't the MariaDB connector doing the same thing, but under a Lesser GPL license? Which would solve a lot of licensing issues (no need to put CloudStack entirely on GPL). FG Hi Francois: L/GPL is also Cat X according to ASF Policy, and thus isn't effectively any better. --David -- Francois Gaudreault Architecte de Solution Cloud | Cloud Solutions Architect fgaudrea...@cloudops.com 514-629-6775 - - - CloudOps 420 rue Guy Montréal QC H3J 1S6 www.cloudops.com @CloudOps_ -- Daan
RE: [DISCUSS] Policy blocker?
I have created a defect for this at: https://issues.apache.org/jira/browse/CLOUDSTACK-6152 I have put the patch in review board at : https://reviews.apache.org/r/18353/ Please review the same and commit it to the branch(4.3-forward) if these changes are fine. Otherwise please let me know if we need to put it into any other scope other than provided @Animesh : Please Cherry Pick it from 4.3.-forward once committed. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, 21 February 2014 5:19 PM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Policy blocker? For DB HA we have included a new class StaticStrategy.java which is having compile time dependency on mysql -connector-java. I will make change in pom, as provided scope dependency instead of compile time so that maven will not include in the bundle while packaging. Thanks Regards Damodar/ -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 12:24 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip For those following along at home, here are some relevant links: http://www.apache.org/legal/resolved.html http://www.apache.org/dev/licensing-howto.html
RE: [DISCUSS] Policy blocker?
Initially I thought my change caused to bundle the mysql-connector-java into RPM in 4.3... but after did more analysis I found that mysql-connector is already getting bundled into RPM in 4.2.x as well. Looks like issue is something else as well.. I am not sure this will fix the actual issue. Anyhow we need to apply this patch even after fixing the actual issue. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, February 21, 2014 6:24 PM To: dev@cloudstack.apache.org Cc: Animesh Chaturvedi Subject: RE: [DISCUSS] Policy blocker? I have created a defect for this at: https://issues.apache.org/jira/browse/CLOUDSTACK-6152 I have put the patch in review board at : https://reviews.apache.org/r/18353/ Please review the same and commit it to the branch(4.3-forward) if these changes are fine. Otherwise please let me know if we need to put it into any other scope other than provided @Animesh : Please Cherry Pick it from 4.3.-forward once committed. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, 21 February 2014 5:19 PM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Policy blocker? For DB HA we have included a new class StaticStrategy.java which is having compile time dependency on mysql -connector-java. I will make change in pom, as provided scope dependency instead of compile time so that maven will not include in the bundle while packaging. Thanks Regards Damodar/ -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 12:24 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things
Re: [DISCUSS] Policy blocker?
Damodar, Did you see my review comments? Cheers, Hugo On 21 feb. 2014, at 16:00, Damoder Reddy damoder.re...@citrix.com wrote: Initially I thought my change caused to bundle the mysql-connector-java into RPM in 4.3... but after did more analysis I found that mysql-connector is already getting bundled into RPM in 4.2.x as well. Looks like issue is something else as well.. I am not sure this will fix the actual issue. Anyhow we need to apply this patch even after fixing the actual issue. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, February 21, 2014 6:24 PM To: dev@cloudstack.apache.org Cc: Animesh Chaturvedi Subject: RE: [DISCUSS] Policy blocker? I have created a defect for this at: https://issues.apache.org/jira/browse/CLOUDSTACK-6152 I have put the patch in review board at : https://reviews.apache.org/r/18353/ Please review the same and commit it to the branch(4.3-forward) if these changes are fine. Otherwise please let me know if we need to put it into any other scope other than provided @Animesh : Please Cherry Pick it from 4.3.-forward once committed. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, 21 February 2014 5:19 PM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Policy blocker? For DB HA we have included a new class StaticStrategy.java which is having compile time dependency on mysql -connector-java. I will make change in pom, as provided scope dependency instead of compile time so that maven will not include in the bundle while packaging. Thanks Regards Damodar/ -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 12:24 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer
Re: [DISCUSS] Policy blocker?
Damoder: your patch merely piled on to an existing problem. I'll respond more to this in a bit, but I think your approach solves your bit of the problem. I have a much longer email that talks about why coming up. Thanks for working on getting a patch up so rapidly. --David On Fri, Feb 21, 2014 at 10:00 AM, Damoder Reddy damoder.re...@citrix.com wrote: Initially I thought my change caused to bundle the mysql-connector-java into RPM in 4.3... but after did more analysis I found that mysql-connector is already getting bundled into RPM in 4.2.x as well. Looks like issue is something else as well.. I am not sure this will fix the actual issue. Anyhow we need to apply this patch even after fixing the actual issue. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, February 21, 2014 6:24 PM To: dev@cloudstack.apache.org Cc: Animesh Chaturvedi Subject: RE: [DISCUSS] Policy blocker? I have created a defect for this at: https://issues.apache.org/jira/browse/CLOUDSTACK-6152 I have put the patch in review board at : https://reviews.apache.org/r/18353/ Please review the same and commit it to the branch(4.3-forward) if these changes are fine. Otherwise please let me know if we need to put it into any other scope other than provided @Animesh : Please Cherry Pick it from 4.3.-forward once committed. Thanks Regards Damodar/ -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, 21 February 2014 5:19 PM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Policy blocker? For DB HA we have included a new class StaticStrategy.java which is having compile time dependency on mysql -connector-java. I will make change in pom, as provided scope dependency instead of compile time so that maven will not include in the bundle while packaging. Thanks Regards Damodar/ -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 12:24 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system
Re: [DISCUSS] Policy blocker?
OK - so hoping to inject some clarification to this discussion - maybe it will make more sense. Lets start with definitions, and I'll try and use caps when referring to this definitions. LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, or the foundation itself. There are precious few real legal issues in this particular discussion, but many legal POLICY issues. POLICY - The ASF has a number of policy, including legal policies. Some of these exist for 'LEGAL' reasons as defined above, some of these are expectation/branding. There are precious few real LEGAL issues in this particular discussion, but many legal POLICY issues. So the legal POLICY says that we may not depend and automatically download GPL (or other Cat X) software. This is not necessarily because of LEGAL problems. (But does help the ASF avoid them) We clearly have a dependency on a number of GPL things - Linux, MySQL, KVM, XenServer, etc. The difference is that we don't automatically download those during the build of the project. E.g. people have to make a conscious decision to consume copyleft (or proprietary) software. It's fine for that decision to be mandatory (POLICY calls this a system requirement) but we don't allow people to be 'surprised' by ensuring that this is a conscious decision. Part of this is the expectation that the ASF releases permissively licensed software - 'sneaking' copyleft software in as a dependency is a bad thing for people whose expectation is otherwise; which brings us back to requiring the explicit action for such system requirements. The FLOSS exception is a moot point IMO unless VP Legal gives us a waiver; and I am not inclined to seek it out. The problem I see with the exception is that it deals with open source projects and not potential downstream consumers who might fork or release under another license. IMO Damoder has the right idea - we should specify that this is provided. I'll work on getting a patch that takes care of this in shortly. --David
RE: [DISCUSS] Policy blocker?
-Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 3:23 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? OK - so hoping to inject some clarification to this discussion - maybe it will make more sense. Lets start with definitions, and I'll try and use caps when referring to this definitions. LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. or the foundation itself. There are precious few real legal issues in this particular discussion, but many legal POLICY issues. POLICY - The ASF has a number of policy, including legal policies. Some of these exist for 'LEGAL' reasons as defined above, some of these are expectation/branding. There are precious few real LEGAL issues in this particular discussion, but many legal POLICY issues. So the legal POLICY says that we may not depend and automatically download GPL (or other Cat X) software. This is not necessarily because of LEGAL problems. (But does help the ASF avoid them) We clearly have a dependency on a number of GPL things - Linux, MySQL, KVM, XenServer, etc. The difference is that we don't automatically download those during the build of the project. E.g. people have to make a conscious decision to consume copyleft (or proprietary) software. It's fine for that decision to be mandatory (POLICY calls this a system requirement) but we don't allow people to be 'surprised' by ensuring that this is a conscious decision. Part of this is the expectation that the ASF releases permissively licensed software - 'sneaking' copyleft software in as a dependency is a bad thing for people whose expectation is otherwise; which brings us back to requiring the explicit action for such system requirements. The FLOSS exception is a moot point IMO unless VP Legal gives us a waiver; and I am not inclined to seek it out. The problem I see with the exception is that it deals with open source projects and not potential downstream consumers who might fork or release under another license. IMO Damoder has the right idea - we should specify that this is provided. I'll work on getting a patch that takes care of this in shortly. --David
Re: [DISCUSS] Policy blocker?
LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. http://www.apache.org/dev/release.html#why https://www.apache.org/foundation/faq.html#why --David
RE: [DISCUSS] Policy blocker?
-Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 4:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. [Animesh] How do you define the release process being followed or not? Isn't Voting on a release the process and PMC and everyone voting responsible for it. Release Manager is a facilitator. Without the protection why would anyone want to incur liability as a release manager? In the links that you sent I have not seen specific reference to Release Manager being liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. [Animesh] What does foundation provide in that case? http://www.apache.org/dev/release.html#why https://www.apache.org/foundation/faq.html#why --David
[DISCUSS] Policy blocker?
Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html
Re: [DISCUSS] Policy blocker?
On 02/20/2014 02:37 PM, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. My apologies, I didn't find the time to play with 4.3 at all. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? I'd say we are OK for now with this. We know it's a problem and it can be fixed in the next release imho. Wido --David [1] https://www.apache.org/legal/3party.html
Re: [DISCUSS] Policy blocker?
On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip
Re: [DISCUSS] Policy blocker?
On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip For those following along at home, here are some relevant links: http://www.apache.org/legal/resolved.html http://www.apache.org/dev/licensing-howto.html
RE: [DISCUSS] Policy blocker?
Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip For those following along at home, here are some relevant links: http://www.apache.org/legal/resolved.html http://www.apache.org/dev/licensing-howto.html
Re: [DISCUSS] Policy blocker?
I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip For those following along at home, here are some relevant links: http://www.apache.org/legal/resolved.html http://www.apache.org/dev/licensing-howto.html
Re: [DISCUSS] Policy blocker?
Will this cause issues with people running ACS from maven jetty (or any other maven operation that needs the db) if the connector isn't pulled in by the pom? I could see it being added to support that need. If they are running it from a tomcat instance managed by eclipse, it would be pretty easy to manage it as a system dep there and removing it from the pom. I've done that myself for other projects and not had a problem, it is just documentation. On Thu, Feb 20, 2014 at 12:54 PM, David Nalley da...@gnsa.us wrote: I will try to work on this a bit this evening, but others may be faster. --David On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers Thanks Animesh -Original Message- From: Chip Childers [mailto:chipchild...@apache.org] Sent: Thursday, February 20, 2014 10:13 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 08:37:46AM -0500, David Nalley wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html During incubation, this dependency was raised as an issue. Generally, there are 2 ways to deal with Category X dependencies within an ASF project: 1) Make it an optional part of the software. This is what we do with the nonoss build target, but won't work for the mysql-connector. 2) Make it a system dependency that is expected to be installed on the system prior to our software. mysql-connector-java (and the python equiv) were supposed to be handled using option 2 (system dependency). Currently, our RPM packaging depends on the relevant RPM to pull this in as a system dependency. I can't tell with the DEBs, but that would need to be reviewed. The problem is that our maven poms pull down the jar automatically right now. This is the blocker for us. I'm certainly not a lawyer, but my understanding of ASF policy is that we need to make some changes before making another release. So, there appear to be three things that have to happen: 1) Confirm that the mysql-connector-java is a system dependency in the DEB packaging. 2) Ensure that a normal build of the project using mvn does not automatically download the mysql-connector-java jar files. 3) Retest the project to ensure that the above changes work. Then we can re-spin an RC. -chip For those following along at home, here are some relevant links: http://www.apache.org/legal/resolved.html http://www.apache.org/dev/licensing-howto.html -- *Nate Gordon*Director of Technology | Appcore - the business of cloud computing® Office +1.800.735.7104 | Direct +1.515.612.7787 nate.gor...@appcore.com | www.appcore.com -- The information in this message is intended for the named recipients only. It may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message is strictly prohibited
Re: [DISCUSS] Policy blocker?
On Thu, Feb 20, 2014 at 3:08 PM, Nate Gordon nate.gor...@appcore.com wrote: Will this cause issues with people running ACS from maven jetty (or any other maven operation that needs the db) if the connector isn't pulled in by the pom? I could see it being added to support that need. If they are running it from a tomcat instance managed by eclipse, it would be pretty easy to manage it as a system dep there and removing it from the pom. I've done that myself for other projects and not had a problem, it is just documentation. Yes. A developer (or anyone else running ACS via jetty) will need to have the jar in the classpath. --David
Re: [DISCUSS] Policy blocker?
On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers I'm sorry to say that I do not have the available cycles. $dayjob + getting ready for a few days off has me pretty booked up. -chip
Re: [DISCUSS] Policy blocker?
Real quick, because I don't know if I will be able to track this thread in detail starting tonight... Take this as input to the discussion that the whole community needs to have about the *potential* problem with the current situation. Legal documentation as well as application of the valid license categories is tied to the bits in something we distribute. So that means that we have LICENSE and NOTICE for the source package (with all code either being valid licenses or developed at the ASF). This same logic applies to any binary distribution... they have their own legal documents, and they should pertain to all bits included in that distribution. Unlike other ASF projects, we do NOT offer binary builds from ASF infra. This is where things are fuzzy, and there needs to be a discussion. We offer packages that are pre-compiled. That being said, we actually offer RPMs that include the nonoss features, while our community hosted DEBs do not contain those bits. Theoretically though, the packages should be the place to depend on system dependencies. The other issue is one of default build not having any category X dependencies. There is a fine line between a system dependency and a dependency that is pulled down during the build. We had previously agreed that the cat X stuff would require manual work and not be pulled in automatically. Transitive dependencies are also an issue... if we package them, we should respect their license and actually need to have them in the legal docs. Not sure where they stand WRT being pulled in by the build process... So... no answers, just a bit of background. I'm going to be offline (mostly) until Wed of next week. I will try to watch this thread and rescind my -1 on the RC if we can work our way through this logic puzzle in a way that satisfies my concerns about the current state of things. -chip On Thu, Feb 20, 2014 at 5:01 PM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers I'm sorry to say that I do not have the available cycles. $dayjob + getting ready for a few days off has me pretty booked up. -chip
Re: [DISCUSS] Policy blocker?
I may be wrong here, and far from being an expert at this, but isn't the MariaDB connector doing the same thing, but under a Lesser GPL license? Which would solve a lot of licensing issues (no need to put CloudStack entirely on GPL). FG On 2/20/2014, 5:10 PM, Chip Childers wrote: Real quick, because I don't know if I will be able to track this thread in detail starting tonight... Take this as input to the discussion that the whole community needs to have about the *potential* problem with the current situation. Legal documentation as well as application of the valid license categories is tied to the bits in something we distribute. So that means that we have LICENSE and NOTICE for the source package (with all code either being valid licenses or developed at the ASF). This same logic applies to any binary distribution... they have their own legal documents, and they should pertain to all bits included in that distribution. Unlike other ASF projects, we do NOT offer binary builds from ASF infra. This is where things are fuzzy, and there needs to be a discussion. We offer packages that are pre-compiled. That being said, we actually offer RPMs that include the nonoss features, while our community hosted DEBs do not contain those bits. Theoretically though, the packages should be the place to depend on system dependencies. The other issue is one of default build not having any category X dependencies. There is a fine line between a system dependency and a dependency that is pulled down during the build. We had previously agreed that the cat X stuff would require manual work and not be pulled in automatically. Transitive dependencies are also an issue... if we package them, we should respect their license and actually need to have them in the legal docs. Not sure where they stand WRT being pulled in by the build process... So... no answers, just a bit of background. I'm going to be offline (mostly) until Wed of next week. I will try to watch this thread and rescind my -1 on the RC if we can work our way through this logic puzzle in a way that satisfies my concerns about the current state of things. -chip On Thu, Feb 20, 2014 at 5:01 PM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers I'm sorry to say that I do not have the available cycles. $dayjob + getting ready for a few days off has me pretty booked up. -chip -- Francois Gaudreault Architecte de Solution Cloud | Cloud Solutions Architect fgaudrea...@cloudops.com 514-629-6775 - - - CloudOps 420 rue Guy Montréal QC H3J 1S6 www.cloudops.com @CloudOps_
Re: [DISCUSS] Policy blocker?
On Thu, Feb 20, 2014 at 9:10 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: I may be wrong here, and far from being an expert at this, but isn't the MariaDB connector doing the same thing, but under a Lesser GPL license? Which would solve a lot of licensing issues (no need to put CloudStack entirely on GPL). FG Hi Francois: L/GPL is also Cat X according to ASF Policy, and thus isn't effectively any better. --David
Re: [DISCUSS] Policy blocker?
I find a little ironic that the internal policies are a lot more restrictive than the Apache license itself :S Meanwhile, isn't CloudStack falling into the MySQL FOSS exception? http://www.mysql.com/about/legal/licensing/foss-exception/ Francois On 2/20/2014, 9:20 PM, David Nalley wrote: On Thu, Feb 20, 2014 at 9:10 PM, Francois Gaudreault fgaudrea...@cloudops.com wrote: I may be wrong here, and far from being an expert at this, but isn't the MariaDB connector doing the same thing, but under a Lesser GPL license? Which would solve a lot of licensing issues (no need to put CloudStack entirely on GPL). FG Hi Francois: L/GPL is also Cat X according to ASF Policy, and thus isn't effectively any better. --David -- Francois Gaudreault Architecte de Solution Cloud | Cloud Solutions Architect fgaudrea...@cloudops.com 514-629-6775 - - - CloudOps 420 rue Guy Montréal QC H3J 1S6 www.cloudops.com @CloudOps_
Re: [DISCUSS] Policy blocker?
On Feb 20, 2014, at 5:10 PM, Chip Childers chipchild...@apache.org wrote: Real quick, because I don't know if I will be able to track this thread in detail starting tonight... Take this as input to the discussion that the whole community needs to have about the *potential* problem with the current situation. Legal documentation as well as application of the valid license categories is tied to the bits in something we distribute. So that means that we have LICENSE and NOTICE for the source package (with all code either being valid licenses or developed at the ASF). This same logic applies to any binary distribution... they have their own legal documents, and they should pertain to all bits included in that distribution. Unlike other ASF projects, we do NOT offer binary builds from ASF infra. This is where things are fuzzy, and there needs to be a discussion. We offer packages that are pre-compiled. I always thought that we do not offer packages. Wido does, not the project. We do build them on jenkins, but there are not official releases. That being said, we actually offer RPMs that include the nonoss features, while our community hosted DEBs do not contain those bits. Theoretically though, the packages should be the place to depend on system dependencies. The other issue is one of default build not having any category X dependencies. There is a fine line between a system dependency and a dependency that is pulled down during the build. We had previously agreed that the cat X stuff would require manual work and not be pulled in automatically. Transitive dependencies are also an issue... if we package them, we should respect their license and actually need to have them in the legal docs. Not sure where they stand WRT being pulled in by the build process... So... no answers, just a bit of background. I'm going to be offline (mostly) until Wed of next week. I will try to watch this thread and rescind my -1 on the RC if we can work our way through this logic puzzle in a way that satisfies my concerns about the current state of things. -chip On Thu, Feb 20, 2014 at 5:01 PM, Chip Childers chipchild...@apache.org wrote: On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: Chip, David thanks for the detailed explanation, is one of you taking care of fixing this issue or we need to find other volunteers I'm sorry to say that I do not have the available cycles. $dayjob + getting ready for a few days off has me pretty booked up. -chip
