You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by David Nalley <da...@gnsa.us> on 2014/02/20 14:37:46 UTC
[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?
Posted by John Kinsella <jl...@stratosec.co>.
+1 well put.
On Feb 26, 2014, at 6:44 AM, Chip Childers <ch...@apache.org> wrote:
> On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
> <an...@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?
Posted by Chip Childers <ch...@apache.org>.
On Wed, Feb 26, 2014 at 4:24 PM, Animesh Chaturvedi
<an...@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?
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: Chip Childers [mailto:chipchilders@apache.org]
> Sent: Wednesday, February 26, 2014 6:44 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Policy blocker?
>
> On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
> <an...@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?
>
>
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
Re: [DISCUSS] Policy blocker?
Posted by Abhinandan Prateek <Ab...@citrix.com>.
+1 this is reasonable.
On 26/02/14 8:14 pm, "Chip Childers" <ch...@apache.org> wrote:
>On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
><an...@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?
Posted by Chip Childers <ch...@apache.org>.
On Tue, Feb 25, 2014 at 7:13 PM, Animesh Chaturvedi
<an...@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?
Posted by Animesh Chaturvedi <an...@citrix.com>.
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:david@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 <ru...@gmail.com>
> wrote:
> >
> > On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi
> <an...@citrix.com> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: David Nalley [mailto:david@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?
Posted by David Nalley <da...@gnsa.us>.
On Sat, Feb 22, 2014 at 3:07 AM, Sebastien Goasguen <ru...@gmail.com> wrote:
>
> On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi <an...@citrix.com> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: David Nalley [mailto:david@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?
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi <an...@citrix.com> wrote:
>
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@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?
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@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
Re: [DISCUSS] Policy blocker?
Posted by David Nalley <da...@gnsa.us>.
>> 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?
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@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?
Posted by David Nalley <da...@gnsa.us>.
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?
Posted by Wido den Hollander <wi...@widodh.nl>.
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?
Posted by Nate Gordon <na...@appcore.com>.
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 <hu...@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.namathponnan@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:david@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.gordon@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?
Posted by Hugo Trippaers <hu...@trippaers.nl>.
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 <ra...@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:david@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?
Posted by Rayees Namathponnan <ra...@citrix.com>.
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:david@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?
Posted by David Nalley <da...@gnsa.us>.
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?
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 20, 2014, at 5:10 PM, Chip Childers <ch...@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 <ch...@apache.org> wrote:
>> On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi
>> <an...@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?
Posted by Daan Hoogland <da...@gmail.com>.
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 <ru...@gmail.com> wrote:
>
> On Feb 20, 2014, at 10:33 PM, Francois Gaudreault <fg...@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
>>> <fg...@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
>> fgaudreault@cloudops.com
>> 514-629-6775
>> - - -
>> CloudOps
>> 420 rue Guy
>> Montréal QC H3J 1S6
>> www.cloudops.com
>> @CloudOps_
>>
>
--
Daan
Re: [DISCUSS] Policy blocker?
Posted by Sebastien Goasguen <ru...@gmail.com>.
On Feb 20, 2014, at 10:33 PM, Francois Gaudreault <fg...@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
>> <fg...@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
> fgaudreault@cloudops.com
> 514-629-6775
> - - -
> CloudOps
> 420 rue Guy
> Montréal QC H3J 1S6
> www.cloudops.com
> @CloudOps_
>
Re: [DISCUSS] Policy blocker?
Posted by Francois Gaudreault <fg...@cloudops.com>.
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
> <fg...@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
fgaudreault@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
Re: [DISCUSS] Policy blocker?
Posted by David Nalley <da...@gnsa.us>.
On Thu, Feb 20, 2014 at 9:10 PM, Francois Gaudreault
<fg...@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?
Posted by Francois Gaudreault <fg...@cloudops.com>.
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 <ch...@apache.org> wrote:
>> On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi
>> <an...@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
fgaudreault@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC H3J 1S6
www.cloudops.com
@CloudOps_
Re: [DISCUSS] Policy blocker?
Posted by Chip Childers <ch...@apache.org>.
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 <ch...@apache.org> wrote:
> On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi
> <an...@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?
Posted by Chip Childers <ch...@apache.org>.
On Thu, Feb 20, 2014 at 1:44 PM, Animesh Chaturvedi
<an...@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?
Posted by David Nalley <da...@gnsa.us>.
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
<Da...@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.Reddy@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.Reddy@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:david@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 <an...@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:chipchilders@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
>>> <ch...@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?
Posted by Hugo Trippaers <hu...@trippaers.nl>.
Damodar,
Did you see my review comments?
Cheers,
Hugo
On 21 feb. 2014, at 16:00, Damoder Reddy <Da...@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.Reddy@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.Reddy@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:david@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 <an...@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:chipchilders@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
>>> <ch...@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?
Posted by Damoder Reddy <Da...@citrix.com>.
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.Reddy@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.Reddy@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:david@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 <an...@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:chipchilders@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
>> <ch...@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?
Posted by Damoder Reddy <Da...@citrix.com>.
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.Reddy@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:david@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 <an...@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:chipchilders@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
>> <ch...@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?
Posted by Damoder Reddy <Da...@citrix.com>.
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:david@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 <an...@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:chipchilders@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
>> <ch...@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?
Posted by David Nalley <da...@gnsa.us>.
On Thu, Feb 20, 2014 at 3:08 PM, Nate Gordon <na...@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?
Posted by Nate Gordon <na...@appcore.com>.
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
> <an...@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:chipchilders@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 <
> chipchilders@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.gordon@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?
Posted by David Nalley <da...@gnsa.us>.
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
<an...@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:chipchilders@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 <ch...@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?
Posted by Animesh Chaturvedi <an...@citrix.com>.
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:chipchilders@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 <ch...@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?
Posted by Chip Childers <ch...@apache.org>.
On Thu, Feb 20, 2014 at 11:32 AM, Chip Childers <ch...@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?
Posted by Chip Childers <ch...@apache.org>.
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