You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Eugen Stan <eu...@netdava.com> on 2020/07/02 10:43:58 UTC
Are gradle / maven build scans acceptable on builds.apache.org ?
Hello,
Is it ok to accept the terms and conditions automatically on
builds.apache.org - https://gradle.com/terms-of-service ?
We are migrating James from maven to gradle.
To aid the migration we use gradle build scans .
A build scan is a report that gradle generates by reading all sorts of
information relating to the build and the environment it runs in.
How to generate a build scan and a link to the build scan for Apache
James, produced on a contributors machine.
|./gradlew clean build -x test --scan|
->https://scans.gradle.com/s/xvchoumy2msda
A build scan is published on a Gradle service and for that we need to
approve some terms and conditionsthat are linked above.
We can do that by applying the following configuration:
|gradleEnterprise {buildScan {termsOfServiceUrl
='https://gradle.com/terms-of-service'termsOfServiceAgree ='yes'}}|
The question I have is :
Can we do this for builds running on builds.apache.org ?
https://guides.gradle.org/creating-build-scans/
https://docs.gradle.com/enterprise/gradle-plugin/#applying_the_plugin
Thanks,
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by Eugen Stan <eu...@netdava.com>.
Thank you Daniel for presenting another side and Roy for the deeper
explanation.
This is very insightful conversation for me.
It is going to help me going further for sure.
Regards,
Eugen
La 05.07.2020 10:18, Roman Shaposhnik a scris:
> On Sat, Jul 4, 2020 at 11:42 AM Roy T. Fielding <fi...@gbiv.com> wrote:
>> On Jul 3, 2020, at 7:47 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>> Are we really happy to accept terms [8(g)] that forbid us from publicly
>>> discussing the "performance" of the service we're given? That term
>>> could be taken to mean not only "the amount of time it takes to produce
>>> an answer" but also the quality of the answer (e.g., its specificity and
>>> sensitivity). For instance, it means that if we find a gradle bug we
>>> won't be allowed to discuss it on public lists, let alone to raise
>>> awareness of it among non-Apache users of gradle (just like git, hg, and
>>> svn issued a coordinated security advisory when a vulnerability affected
>>> all three of them).
>>>
>>> Last I checked, this sort of term wasn't standard in TOSes, and I don't
>>> see why we should accept it. It's not in our interest to use a service
>>> that forbids its users to publicly discuss its shortcomings. (By the
>>> way, the ability to publicly discuss a product's shortcomings is one
>>> reason people choose open source over alternatives.)
>>>
>>> @Roy, I don't quite follow your AFAYCT argument. You seem to argue we
>>> should go ahead and ignore the gag, and risk our usage being terminated.
>>> Isn't that pretty much diametrically opposite to the ASF's view on third
>>> party copyright licenses, where we honour copyright owners' wishes even
>>> when those aren't legally enforceable?
>> No. Copyright is enforced by international law with national fines.
>> It's impossible to know what is enforceable until after a judgement.
>>
>> We respect their wishes both because they have standing to sue and
>> because we want them (as creators) to be happy just like us.
>> We want a license specifically because that is what we are asking
>> permission to do (redistribute and create derivative works).
>>
>> In this case, we are agreeing to the contract with an intent to use
>> their service, not with an intent to publicly evaluate their service.
>> We are supposedly making them happy by using their service, provided
>> that we follow their terms. Since our intent is to follow those terms
>> to the extent that *we* interpret them, that's okay.
>>
>> We have no obligation to guess what the ToS restrictions mean, nor
>> do we need to police ourselves, since the only restriction is that
>> they can discontinue that service to us if they become unhappy with
>> our adherence to the terms.
>>
>> A gag restriction without any associated penalty other than "cancel
>> the contract that gags us" is a very different beast. It is a common
>> clause in private contracts. That doesn't make it enforceable, nor
>> does it require Gradle to enforce it. It's not meant for us.
>>
>>> Seems to me we should ask them to remove or modify 8(g) as a condition
>>> to our accepting the terms.
>> They are providing a service. AFAIK, that service costs us nothing.
>> It's a gift horse (or at least a loaner).
>>
>> In contrast, if we negotiate with them over terms, then we impose
>> legal costs on us and them for what is obviously a kitchen sink
>> contract that applies to all of their users. We've had many random
>> corporate lawyers come to us demanding random changes to the CCLA
>> or Apache License, just for their own client, and our response
>> has been a consistent "no".
>>
>> If they were to come back and complain to us about some honest comment
>> about their services, threatening to cut off the service if we don't
>> remove the comment from our archives, that's when we tell them where
>> they can shove it. Not before.
> +1
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Jul 5, 2020, at 7:31 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Roman Shaposhnik wrote on Sun, Jul 05, 2020 at 00:18:06 -0700:
>> On Sat, Jul 4, 2020 at 11:42 AM Roy T. Fielding <fi...@gbiv.com> wrote:
>>>
>>> On Jul 3, 2020, at 7:47 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>>>>
>>>> Are we really happy to accept terms [8(g)] that forbid us from publicly
>>>> discussing the "performance" of the service we're given? That term
>>>> could be taken to mean not only "the amount of time it takes to produce
>>>> an answer" but also the quality of the answer (e.g., its specificity and
>>>> sensitivity). For instance, it means that if we find a gradle bug we
>>>> won't be allowed to discuss it on public lists, let alone to raise
>>>> awareness of it among non-Apache users of gradle (just like git, hg, and
>>>> svn issued a coordinated security advisory when a vulnerability affected
>>>> all three of them).
>>>>
>>>> Last I checked, this sort of term wasn't standard in TOSes, and I don't
>>>> see why we should accept it. It's not in our interest to use a service
>>>> that forbids its users to publicly discuss its shortcomings. (By the
>>>> way, the ability to publicly discuss a product's shortcomings is one
>>>> reason people choose open source over alternatives.)
>>>>
>>>> @Roy, I don't quite follow your AFAYCT argument. You seem to argue we
>>>> should go ahead and ignore the gag, and risk our usage being terminated.
>>>> Isn't that pretty much diametrically opposite to the ASF's view on third
>>>> party copyright licenses, where we honour copyright owners' wishes even
>>>> when those aren't legally enforceable?
>>>
>>> No. Copyright is enforced by international law with national fines.
>>> It's impossible to know what is enforceable until after a judgement.
>>>
>>> We respect their wishes both because they have standing to sue and
>>> because we want them (as creators) to be happy just like us.
>>> We want a license specifically because that is what we are asking
>>> permission to do (redistribute and create derivative works).
>
> OK
>
>>> In this case, we are agreeing to the contract with an intent to use
>>> their service, not with an intent to publicly evaluate their service.
>
> If projects use the service, they will inevitably discuss it publicly,
> just like projects discuss compiler bugs publicly. Having such
> discussions isn't our primary purpose, but those discussions will
> certainly happen anyway.
Yes, the clause does not prevent that.
Look, this is a public list. I am not going to discuss this further
on a public list because it has nothing to do with our license or
open source in general. Nor am I going to explain the meaning of
defined terms in RFC2119 (because this is not the IETF), nor the
reason why applied logic is irrelevant to US contract law (IANAL).
....Roy
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Roman Shaposhnik wrote on Sun, Jul 05, 2020 at 00:18:06 -0700:
> On Sat, Jul 4, 2020 at 11:42 AM Roy T. Fielding <fi...@gbiv.com> wrote:
> >
> > On Jul 3, 2020, at 7:47 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > >
> > > Are we really happy to accept terms [8(g)] that forbid us from publicly
> > > discussing the "performance" of the service we're given? That term
> > > could be taken to mean not only "the amount of time it takes to produce
> > > an answer" but also the quality of the answer (e.g., its specificity and
> > > sensitivity). For instance, it means that if we find a gradle bug we
> > > won't be allowed to discuss it on public lists, let alone to raise
> > > awareness of it among non-Apache users of gradle (just like git, hg, and
> > > svn issued a coordinated security advisory when a vulnerability affected
> > > all three of them).
> > >
> > > Last I checked, this sort of term wasn't standard in TOSes, and I don't
> > > see why we should accept it. It's not in our interest to use a service
> > > that forbids its users to publicly discuss its shortcomings. (By the
> > > way, the ability to publicly discuss a product's shortcomings is one
> > > reason people choose open source over alternatives.)
> > >
> > > @Roy, I don't quite follow your AFAYCT argument. You seem to argue we
> > > should go ahead and ignore the gag, and risk our usage being terminated.
> > > Isn't that pretty much diametrically opposite to the ASF's view on third
> > > party copyright licenses, where we honour copyright owners' wishes even
> > > when those aren't legally enforceable?
> >
> > No. Copyright is enforced by international law with national fines.
> > It's impossible to know what is enforceable until after a judgement.
> >
> > We respect their wishes both because they have standing to sue and
> > because we want them (as creators) to be happy just like us.
> > We want a license specifically because that is what we are asking
> > permission to do (redistribute and create derivative works).
OK
> > In this case, we are agreeing to the contract with an intent to use
> > their service, not with an intent to publicly evaluate their service.
If projects use the service, they will inevitably discuss it publicly,
just like projects discuss compiler bugs publicly. Having such
discussions isn't our primary purpose, but those discussions will
certainly happen anyway.
> > We are supposedly making them happy by using their service, provided
> > that we follow their terms. Since our intent is to follow those terms
> > to the extent that *we* interpret them, that's okay.
> >
> > We have no obligation to guess what the ToS restrictions mean, nor
> > do we need to police ourselves, since the only restriction is that
> > they can discontinue that service to us if they become unhappy with
> > our adherence to the terms.
How is that the "only" restriction? AFAICT, the ToS do not forbid
Gradle from _also_ suing us, over and above terminating our usage.
> > A gag restriction without any associated penalty other than "cancel
> > the contract that gags us" is a very different beast. It is a common
> > clause in private contracts. That doesn't make it enforceable, nor
> > does it require Gradle to enforce it. It's not meant for us.
So if I understand correctly, you're saying that whenever gradle
says "MUST NOT" lest the contract be cancelled, we are to take it
as "SHOULD NOT". [For convenience, the definitions are quoted in
a footnote.]
Would you be happy with ALv2 consumers treating it the same way? For
example, how would you feel if a (political) party you didn't vote for
ignored the "must" in ALv2 §4(b) because they interpreted that condition
as "not meant for [them]" and assumed that ASF wouldn't do anything
other than possibly rescind the §2/§3 grants? I'm sure they'd be as
convinced that the ALv2 §4(b) restriction doesn't apply to them as you
are that the ToS §8(g) restriction doesn't apply to ASF.
Assume the hypothesized dispute were governed by the laws of Delaware.
[#include <any-resemblance-to-reality-is-accidental.h>]
> > > Seems to me we should ask them to remove or modify 8(g) as a condition
> > > to our accepting the terms.
> >
> > They are providing a service. AFAIK, that service costs us nothing.
If 8(g) isn't a problem for gratis services, then you may consider it to
apply, _mutatis mutandis_, to my future contributions to this mailing
list and to Subversion's buildbots and cron jobs. Those, too, are
"services that cost [ASF] nothing".
> > It's a gift horse (or at least a loaner).
It's somewhat like a loaned book that the loanee is forbidden to
publicly review. Most loanees wouldn't do that anyway, but the loanee
in question is an internationally-famous non-profit English class that
publishes its classroom sessions' transcripts and the book is
a dictionary that has spelling errors in some of its entries.
> > In contrast, if we negotiate with them over terms, then we impose
> > legal costs on us and them for what is obviously a kitchen sink
> > contract that applies to all of their users. We've had many random
> > corporate lawyers come to us demanding random changes to the CCLA
> > or Apache License, just for their own client, and our response
> > has been a consistent "no".
Accurate, but fallacious.
> > If they were to come back and complain to us about some honest comment
> > about their services, threatening to cut off the service if we don't
> > remove the comment from our archives, that's when we tell them where
> > they can shove it. Not before.
>
> +1
Allow me to release you from the courtesy of responding.
Daniel
<rfc2119>
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
</rfc2119>
<ToS 8(g)>
Except as otherwise expressly permitted in this Agreement, you
will not […] publicly disseminate information regarding the
performance of the Products.
</ToS 8(g)>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Jul 4, 2020 at 11:42 AM Roy T. Fielding <fi...@gbiv.com> wrote:
>
> On Jul 3, 2020, at 7:47 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> >
> > Are we really happy to accept terms [8(g)] that forbid us from publicly
> > discussing the "performance" of the service we're given? That term
> > could be taken to mean not only "the amount of time it takes to produce
> > an answer" but also the quality of the answer (e.g., its specificity and
> > sensitivity). For instance, it means that if we find a gradle bug we
> > won't be allowed to discuss it on public lists, let alone to raise
> > awareness of it among non-Apache users of gradle (just like git, hg, and
> > svn issued a coordinated security advisory when a vulnerability affected
> > all three of them).
> >
> > Last I checked, this sort of term wasn't standard in TOSes, and I don't
> > see why we should accept it. It's not in our interest to use a service
> > that forbids its users to publicly discuss its shortcomings. (By the
> > way, the ability to publicly discuss a product's shortcomings is one
> > reason people choose open source over alternatives.)
> >
> > @Roy, I don't quite follow your AFAYCT argument. You seem to argue we
> > should go ahead and ignore the gag, and risk our usage being terminated.
> > Isn't that pretty much diametrically opposite to the ASF's view on third
> > party copyright licenses, where we honour copyright owners' wishes even
> > when those aren't legally enforceable?
>
> No. Copyright is enforced by international law with national fines.
> It's impossible to know what is enforceable until after a judgement.
>
> We respect their wishes both because they have standing to sue and
> because we want them (as creators) to be happy just like us.
> We want a license specifically because that is what we are asking
> permission to do (redistribute and create derivative works).
>
> In this case, we are agreeing to the contract with an intent to use
> their service, not with an intent to publicly evaluate their service.
> We are supposedly making them happy by using their service, provided
> that we follow their terms. Since our intent is to follow those terms
> to the extent that *we* interpret them, that's okay.
>
> We have no obligation to guess what the ToS restrictions mean, nor
> do we need to police ourselves, since the only restriction is that
> they can discontinue that service to us if they become unhappy with
> our adherence to the terms.
>
> A gag restriction without any associated penalty other than "cancel
> the contract that gags us" is a very different beast. It is a common
> clause in private contracts. That doesn't make it enforceable, nor
> does it require Gradle to enforce it. It's not meant for us.
>
> > Seems to me we should ask them to remove or modify 8(g) as a condition
> > to our accepting the terms.
>
> They are providing a service. AFAIK, that service costs us nothing.
> It's a gift horse (or at least a loaner).
>
> In contrast, if we negotiate with them over terms, then we impose
> legal costs on us and them for what is obviously a kitchen sink
> contract that applies to all of their users. We've had many random
> corporate lawyers come to us demanding random changes to the CCLA
> or Apache License, just for their own client, and our response
> has been a consistent "no".
>
> If they were to come back and complain to us about some honest comment
> about their services, threatening to cut off the service if we don't
> remove the comment from our archives, that's when we tell them where
> they can shove it. Not before.
+1
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jul 3, 2020, at 7:47 AM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Are we really happy to accept terms [8(g)] that forbid us from publicly
> discussing the "performance" of the service we're given? That term
> could be taken to mean not only "the amount of time it takes to produce
> an answer" but also the quality of the answer (e.g., its specificity and
> sensitivity). For instance, it means that if we find a gradle bug we
> won't be allowed to discuss it on public lists, let alone to raise
> awareness of it among non-Apache users of gradle (just like git, hg, and
> svn issued a coordinated security advisory when a vulnerability affected
> all three of them).
>
> Last I checked, this sort of term wasn't standard in TOSes, and I don't
> see why we should accept it. It's not in our interest to use a service
> that forbids its users to publicly discuss its shortcomings. (By the
> way, the ability to publicly discuss a product's shortcomings is one
> reason people choose open source over alternatives.)
>
> @Roy, I don't quite follow your AFAYCT argument. You seem to argue we
> should go ahead and ignore the gag, and risk our usage being terminated.
> Isn't that pretty much diametrically opposite to the ASF's view on third
> party copyright licenses, where we honour copyright owners' wishes even
> when those aren't legally enforceable?
No. Copyright is enforced by international law with national fines.
It's impossible to know what is enforceable until after a judgement.
We respect their wishes both because they have standing to sue and
because we want them (as creators) to be happy just like us.
We want a license specifically because that is what we are asking
permission to do (redistribute and create derivative works).
In this case, we are agreeing to the contract with an intent to use
their service, not with an intent to publicly evaluate their service.
We are supposedly making them happy by using their service, provided
that we follow their terms. Since our intent is to follow those terms
to the extent that *we* interpret them, that's okay.
We have no obligation to guess what the ToS restrictions mean, nor
do we need to police ourselves, since the only restriction is that
they can discontinue that service to us if they become unhappy with
our adherence to the terms.
A gag restriction without any associated penalty other than "cancel
the contract that gags us" is a very different beast. It is a common
clause in private contracts. That doesn't make it enforceable, nor
does it require Gradle to enforce it. It's not meant for us.
> Seems to me we should ask them to remove or modify 8(g) as a condition
> to our accepting the terms.
They are providing a service. AFAIK, that service costs us nothing.
It's a gift horse (or at least a loaner).
In contrast, if we negotiate with them over terms, then we impose
legal costs on us and them for what is obviously a kitchen sink
contract that applies to all of their users. We've had many random
corporate lawyers come to us demanding random changes to the CCLA
or Apache License, just for their own client, and our response
has been a consistent "no".
If they were to come back and complain to us about some honest comment
about their services, threatening to cut off the service if we don't
remove the comment from our archives, that's when we tell them where
they can shove it. Not before.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Are we really happy to accept terms [8(g)] that forbid us from publicly
discussing the "performance" of the service we're given? That term
could be taken to mean not only "the amount of time it takes to produce
an answer" but also the quality of the answer (e.g., its specificity and
sensitivity). For instance, it means that if we find a gradle bug we
won't be allowed to discuss it on public lists, let alone to raise
awareness of it among non-Apache users of gradle (just like git, hg, and
svn issued a coordinated security advisory when a vulnerability affected
all three of them).
Last I checked, this sort of term wasn't standard in TOSes, and I don't
see why we should accept it. It's not in our interest to use a service
that forbids its users to publicly discuss its shortcomings. (By the
way, the ability to publicly discuss a product's shortcomings is one
reason people choose open source over alternatives.)
@Roy, I don't quite follow your AFAYCT argument. You seem to argue we
should go ahead and ignore the gag, and risk our usage being terminated.
Isn't that pretty much diametrically opposite to the ASF's view on third
party copyright licenses, where we honour copyright owners' wishes even
when those aren't legally enforceable?
Seems to me we should ask them to remove or modify 8(g) as a condition
to our accepting the terms.
Gavin McDonald wrote on Fri, 03 Jul 2020 10:17 +00:00:
> Hi,
>
> I have checked it out and am happy with auto-accept of the Gradle terms and
> conditions within builds on our CI Infra.
>
> Gav... (ASF Infra)
>
>
> On 2020/07/02 18:18:50, "Roy T. Fielding" <fi...@gbiv.com> wrote:
> > > On Jul 2, 2020, at 3:43 AM, Eugen Stan <eu...@netdava.com> wrote:
> > >
> > > Hello,
> > >
> > > Is it ok to accept the terms and conditions automatically on
> > > builds.apache.org - https://gradle.com/terms-of-service ?
> >
> > That would depend on who is agreeing to use those services and
> > what the service entails. It would be better to ask Infra to agree
> > first, on behalf of the ASF, and after that point we can just
> > accept the the mechanism's ToS automatically if their service
> > permits use for automated builds (some don't because it would
> > overload the service).
> >
> > BTW, that is an impressive ToS. It covers everything, including
> > its own use of open source, and nicely limits the IP grants so
> > that it doesn't override our license. The only issue you need
> > to be aware of is the section 8 Restrictions:
> >
> > 8. Restrictions. Except as otherwise expressly permitted in this
> > Agreement, you will not: (a) rent, lease, reproduce, modify,
> > adapt, create derivative works of, distribute, sell, sublicense,
> > transfer, or provide access to the Products to a third party,
> > (b) use the Products for the benefit of any third party,
> > (c) incorporate any Products into a product or service you
> > provide to a third party, (d) interfere with any license key
> > mechanism in the Products or otherwise circumvent mechanisms
> > in the Products intended to limit your use, (e) reverse engineer,
> > disassemble, decompile, translate, or otherwise seek to obtain
> > or derive the source code, underlying ideas, algorithms,
> > file formats or non-public APIs to any Products, except as
> > permitted by law, (f) remove or obscure any proprietary or
> > other notices contained in any Product, or (g) publicly
> > disseminate information regarding the performance of the Products.
> >
> > Note that (b) is debatable for an ASF project given that our
> > project participants come from many third parties, and
> > (g) is a gag restriction on complaining about their product.
> > However, AFAICT, this simply gives them grounds for terminating
> > access to their Product if they happen to disagree with our usage.
> >
> > > We are migrating James from maven to gradle.
> > >
> > > To aid the migration we use gradle build scans .
> > >
> > > A build scan is a report that gradle generates by reading all sorts of
> > > information relating to the build and the environment it runs in.
> > >
> > > How to generate a build scan and a link to the build scan for Apache
> > > James, produced on a contributors machine.
> > >
> > > |./gradlew clean build -x test --scan|
> > > ->https://scans.gradle.com/s/xvchoumy2msda
> > >
> > >
> > > A build scan is published on a Gradle service and for that we need to
> > > approve some terms and conditionsthat are linked above.
> > >
> > > We can do that by applying the following configuration:
> > >
> > > |gradleEnterprise {buildScan {termsOfServiceUrl
> > > ='https://gradle.com/terms-of-service'termsOfServiceAgree ='yes'}}|
> > >
> > >
> > > The question I have is :
> > >
> > > Can we do this for builds running on builds.apache.org ?
> > >
> > > https://guides.gradle.org/creating-build-scans/
> > >
> > > https://docs.gradle.com/enterprise/gradle-plugin/#applying_the_plugin
> >
> > You should ask Infra about agreeing to it as the ASF. The terms are okay,
> > so it's not a legal issue as far as I can see (and if it were, this public
> > list is not the right place to discuss it). Once Infra agrees, automating
> > repeat of that agreement is not a concern.
> >
> > ....Roy
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by Eugen Stan <eu...@netdava.com>.
Thank you both Roy and Gavin for your support.
I would also like to acknowledge Gavin and @chirst 's support on Slack
Infra channel.
They have both been prompt and very helpful with this request and others
I had.
Thank you all,
--
Eugen Stan
+40720 898 747 / netdava.com
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by Gavin McDonald <gm...@apache.org>.
Hi,
I have checked it out and am happy with auto-accept of the Gradle terms and
conditions within builds on our CI Infra.
Gav... (ASF Infra)
On 2020/07/02 18:18:50, "Roy T. Fielding" <fi...@gbiv.com> wrote:
> > On Jul 2, 2020, at 3:43 AM, Eugen Stan <eu...@netdava.com> wrote:
> >
> > Hello,
> >
> > Is it ok to accept the terms and conditions automatically on
> > builds.apache.org - https://gradle.com/terms-of-service ?
>
> That would depend on who is agreeing to use those services and
> what the service entails. It would be better to ask Infra to agree
> first, on behalf of the ASF, and after that point we can just
> accept the the mechanism's ToS automatically if their service
> permits use for automated builds (some don't because it would
> overload the service).
>
> BTW, that is an impressive ToS. It covers everything, including
> its own use of open source, and nicely limits the IP grants so
> that it doesn't override our license. The only issue you need
> to be aware of is the section 8 Restrictions:
>
> 8. Restrictions. Except as otherwise expressly permitted in this
> Agreement, you will not: (a) rent, lease, reproduce, modify,
> adapt, create derivative works of, distribute, sell, sublicense,
> transfer, or provide access to the Products to a third party,
> (b) use the Products for the benefit of any third party,
> (c) incorporate any Products into a product or service you
> provide to a third party, (d) interfere with any license key
> mechanism in the Products or otherwise circumvent mechanisms
> in the Products intended to limit your use, (e) reverse engineer,
> disassemble, decompile, translate, or otherwise seek to obtain
> or derive the source code, underlying ideas, algorithms,
> file formats or non-public APIs to any Products, except as
> permitted by law, (f) remove or obscure any proprietary or
> other notices contained in any Product, or (g) publicly
> disseminate information regarding the performance of the Products.
>
> Note that (b) is debatable for an ASF project given that our
> project participants come from many third parties, and
> (g) is a gag restriction on complaining about their product.
> However, AFAICT, this simply gives them grounds for terminating
> access to their Product if they happen to disagree with our usage.
>
> > We are migrating James from maven to gradle.
> >
> > To aid the migration we use gradle build scans .
> >
> > A build scan is a report that gradle generates by reading all sorts of
> > information relating to the build and the environment it runs in.
> >
> > How to generate a build scan and a link to the build scan for Apache
> > James, produced on a contributors machine.
> >
> > |./gradlew clean build -x test --scan|
> > ->https://scans.gradle.com/s/xvchoumy2msda
> >
> >
> > A build scan is published on a Gradle service and for that we need to
> > approve some terms and conditionsthat are linked above.
> >
> > We can do that by applying the following configuration:
> >
> > |gradleEnterprise {buildScan {termsOfServiceUrl
> > ='https://gradle.com/terms-of-service'termsOfServiceAgree ='yes'}}|
> >
> >
> > The question I have is :
> >
> > Can we do this for builds running on builds.apache.org ?
> >
> > https://guides.gradle.org/creating-build-scans/
> >
> > https://docs.gradle.com/enterprise/gradle-plugin/#applying_the_plugin
>
> You should ask Infra about agreeing to it as the ASF. The terms are okay,
> so it's not a legal issue as far as I can see (and if it were, this public
> list is not the right place to discuss it). Once Infra agrees, automating
> repeat of that agreement is not a concern.
>
> ....Roy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Are gradle / maven build scans acceptable on builds.apache.org ?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Jul 2, 2020, at 3:43 AM, Eugen Stan <eu...@netdava.com> wrote:
>
> Hello,
>
> Is it ok to accept the terms and conditions automatically on
> builds.apache.org - https://gradle.com/terms-of-service ?
That would depend on who is agreeing to use those services and
what the service entails. It would be better to ask Infra to agree
first, on behalf of the ASF, and after that point we can just
accept the the mechanism's ToS automatically if their service
permits use for automated builds (some don't because it would
overload the service).
BTW, that is an impressive ToS. It covers everything, including
its own use of open source, and nicely limits the IP grants so
that it doesn't override our license. The only issue you need
to be aware of is the section 8 Restrictions:
8. Restrictions. Except as otherwise expressly permitted in this
Agreement, you will not: (a) rent, lease, reproduce, modify,
adapt, create derivative works of, distribute, sell, sublicense,
transfer, or provide access to the Products to a third party,
(b) use the Products for the benefit of any third party,
(c) incorporate any Products into a product or service you
provide to a third party, (d) interfere with any license key
mechanism in the Products or otherwise circumvent mechanisms
in the Products intended to limit your use, (e) reverse engineer,
disassemble, decompile, translate, or otherwise seek to obtain
or derive the source code, underlying ideas, algorithms,
file formats or non-public APIs to any Products, except as
permitted by law, (f) remove or obscure any proprietary or
other notices contained in any Product, or (g) publicly
disseminate information regarding the performance of the Products.
Note that (b) is debatable for an ASF project given that our
project participants come from many third parties, and
(g) is a gag restriction on complaining about their product.
However, AFAICT, this simply gives them grounds for terminating
access to their Product if they happen to disagree with our usage.
> We are migrating James from maven to gradle.
>
> To aid the migration we use gradle build scans .
>
> A build scan is a report that gradle generates by reading all sorts of
> information relating to the build and the environment it runs in.
>
> How to generate a build scan and a link to the build scan for Apache
> James, produced on a contributors machine.
>
> |./gradlew clean build -x test --scan|
> ->https://scans.gradle.com/s/xvchoumy2msda
>
>
> A build scan is published on a Gradle service and for that we need to
> approve some terms and conditionsthat are linked above.
>
> We can do that by applying the following configuration:
>
> |gradleEnterprise {buildScan {termsOfServiceUrl
> ='https://gradle.com/terms-of-service'termsOfServiceAgree ='yes'}}|
>
>
> The question I have is :
>
> Can we do this for builds running on builds.apache.org ?
>
> https://guides.gradle.org/creating-build-scans/
>
> https://docs.gradle.com/enterprise/gradle-plugin/#applying_the_plugin
You should ask Infra about agreeing to it as the ASF. The terms are okay,
so it's not a legal issue as far as I can see (and if it were, this public
list is not the right place to discuss it). Once Infra agrees, automating
repeat of that agreement is not a concern.
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org