You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Shane Curcuru <as...@shanecurcuru.org> on 2019/03/14 01:00:45 UTC
Re: Binary channels - why don't we support them?
There are a lot of detailed legal and policy discussions on this thread.
But I think we're missing the bigger ASF policy question:
- Why don't we officially allow projects to release binaries?
This is a serious question, and one that envisions a much larger scope
of work than perhaps we've historically bitten off, so... just put aside
all the "we've always done it that way" and "too hard" ideas and ponder.
1- We're a public charity. Clearly many - by sheer numbers of downloads
- the majority of people who use our software are using binaries, not
source code. Why shouldn't we officially support them?
This is not necessarily a blocking issue; clearly the "unofficial"
binaries many Apache projects provide - or third party packagers - are
physically meeting this need. But still, it's odd that as a public
charity, we're going through hoops to ensure our policies explicitly do
*not* serve these users by claiming we never release binaries.
2- A key purpose for incorporation was to be a legal shield for our
committers. Presumably this should include most project's release
managers, yes?
Isn't it a glaring hole that the ASF is explicitly saying - by omission
in our legal FAQs somewhere - that we do *not* protect any release
manager that puts binary releases on apache.org/dist?
There's a serious legal question here: if a binary does have a problem
which causes damage, it certainly seems like the release manager could
be personally liable (at least to the point that they actually get sued
[1]).
More importantly: this potential legal risk is probably not understood
by the majority of our release managers. Heck, we've had many of people
here deeply familiar with the ASF who still aren't sure of exact
agreement how all this works. How can we expect our release managers to
really understand the potential personal risk they're taking whenever
they ship binaries?
----
Note: solving this kind of issue is not something we could get done with
our existing volunteers. But I'm wondering if it's something that we
should invest some budget resources into.
So separately from the many questions I expect, my questions are:
- Does anyone reading this list think it would be important to have the
ASF provide official binaries? (Or rather: change policies/processes
such that PMCs could choose to do so).
- Do list readers believe release managers understand this issue, and
the fact that any binary releases are not official (i.e. are personal)?
--
- Shane
Director & Member
The Apache Software Foundation
[1] Sure, there's a "no warranty" and what-not in the license etc.,
which would be useful in a court case. But for a committer to be sued
*personally*, any legal defense they have to make will be personally
expensive and worrying, I would think.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by Shane Curcuru <as...@shanecurcuru.org>.
A couple of important clarifications to head off uneeded tangents on my
poor choice of word "support".
Roman Shaposhnik wrote on 3/14/19 5:39 PM:
> On Wed, Mar 13, 2019 at 6:01 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
>>
>> There are a lot of detailed legal and policy discussions on this thread.
>> But I think we're missing the bigger ASF policy question:
>>
>> - Why don't we officially allow projects to release binaries?
>>
>> This is a serious question, and one that envisions a much larger scope
>> of work than perhaps we've historically bitten off, so... just put aside
>> all the "we've always done it that way" and "too hard" ideas and ponder.
>>
>> 1- We're a public charity. Clearly many - by sheer numbers of downloads
>> - the majority of people who use our software are using binaries,
>
> That actually depends on the project (and to some extent the language/runtime
> ecosystem it lives in). As a blanket statement I don't think it is true.
Obviously it varies by project and technology, and depends on exact
meaning of user (i.e. human who personally downloads and uses vs. human
who downloads a 3rd party distro with our software in it, etc.) But in
terms of users in general, it still feels like a large number using
binaries of some form, even if we exclude AOO.
>> not source code. Why shouldn't we officially support them?
>
> "support" is way too loaded of a term to be used productively in this
> discussion, I think.
> After all, there are aspects of "support" that we don't provide for
> even source releases.
Apologies for the word choice, you're correct that I do not mean
"provide customer support for" in any way, but like you note below.
> Personally, I'd like to focus not on support, but rather on
> "recognition" (plz suggest
> a better term). So to me the real question is this: "Why shouldn't we officially
> recognize binary releases as an act of a foundation".
Even better along your lines: Why doesn't our official release policy
provide a way for PMCs to release binaries if they choose to?
>
>> This is not necessarily a blocking issue; clearly the "unofficial"
>> binaries many Apache projects provide - or third party packagers - are
>> physically meeting this need. But still, it's odd that as a public
>> charity, we're going through hoops to ensure our policies explicitly do
>> *not* serve these users by claiming we never release binaries.
>
> Let me start by answering part of your question. I'll use C/C++ ecosystem
> since it is easier to drive my point home: it will be very difficult for us to
> actually server those users on projects like httpd and subversion. The
> sheer # of variations that we would have to release and test is pretty
> staggering.
Huh? How is this pertinent? Remember, I'm only suggesting that our
policy allow PMCs to *choose* to support a binary release of whatever
kind they feel is best. This would never be a requirement, and it's
wholly up to the PMC to choose what to do.
(Feels like these paras we're talking past each other about different
topics on this para, perhaps?)
...snip...
> I do believe, however, that our current position puts RMs into a very
> unfortunate situation. So what DOES need to get resolved ASAP is
> whether we extend the shield or outlaw the binaries. We have to decide
> in my view.
>
>> - Do list readers believe release managers understand this issue, and
>> the fact that any binary releases are not official (i.e. are personal)?
>
> I believe you articulated a very important issue and I agree with your
> assessment.
Thanks, I was hoping I wasn't missing something obvious.
--
- Shane
Director & Member
The Apache Software Foundation
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> (2) A rush to hobble new communities by requiring Apache Releases as a binary choice - once your code is in then some are on a quest to eliminate all other release channels.
I’d say that’s an unfair characterisation. Release, distributions and trademark policy is very clear on what a podlings should and shouldn’t do and some podlings are not complying with them. You note the conversation was around how podlings can use other release channels not that they can’t use them. They just need guidance on how to use them. Note it's not only binary distributions that are the issue here as source distributions are being distributed this well as well.
Given some of the discussions that may allow podlings to make releases without IPMC involvement we may also have to consider if the current DISCLAIMER is enough or the legal protection extends to source releases with ASF policy violations (like containing category X code or having compiled code in a source release). Would the legal protection have to be increased if say 24%* of source releases coming out of podlings have these sort of issues?
Thanks,
Justin
* That is an accurate figure from reviewing 100’s of IPMC releases
Re: Binary channels - why don't we support them?
Posted by Dave Fisher <da...@comcast.net>.
Hi -
I was thinking about what Shane wrote from a couple of points of view and Roman writes narrowing the view beyond the reality of what really is happening.
Let me introduce a new problem that we have in the Incubator.
(1) Not enough Mentors to properly VOTE on Podling releases on the podling dev list.
(2) A rush to hobble new communities by requiring Apache Releases as a binary choice - once your code is in then some are on a quest to eliminate all other release channels.
This colors my thinking.
> On Mar 14, 2019, at 2:39 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Wed, Mar 13, 2019 at 6:01 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
>>
>> There are a lot of detailed legal and policy discussions on this thread.
>> But I think we're missing the bigger ASF policy question:
>>
>> - Why don't we officially allow projects to release binaries?
>>
>> This is a serious question, and one that envisions a much larger scope
>> of work than perhaps we've historically bitten off, so... just put aside
>> all the "we've always done it that way" and "too hard" ideas and ponder.
>>
>> 1- We're a public charity. Clearly many - by sheer numbers of downloads
>> - the majority of people who use our software are using binaries,
>
> That actually depends on the project (and to some extent the language/runtime
> ecosystem it lives in). As a blanket statement I don't think it is true.
OpenOffice is specifically allowed to create Binaries and there have been around 250 million on multiple platforms of those binaries.
Yes, it is an exception.
>
>> not source code. Why shouldn't we officially support them?
>
> "support" is way too loaded of a term to be used productively in this
> discussion, I think.
> After all, there are aspects of "support" that we don't provide for
> even source releases.
>
> Personally, I'd like to focus not on support, but rather on
> "recognition" (plz suggest
> a better term). So to me the real question is this: "Why shouldn't we officially
> recognize binary releases as an act of a foundation”.
I was thinking that we could “certify” a binary release as something different from a source release. Use the class A / class B distinctions.
In an analogous way we could “certify” a PPMC release as “Disclaimed” more than an IPMC release of a PPMC artifacts. This would give us a path to allowing podlings to release sooner and more often.
We would then put some process in place to add these “certifications” where they can be found.
>
>> This is not necessarily a blocking issue; clearly the "unofficial"
>> binaries many Apache projects provide - or third party packagers - are
>> physically meeting this need. But still, it's odd that as a public
>> charity, we're going through hoops to ensure our policies explicitly do
>> *not* serve these users by claiming we never release binaries.
>
> Let me start by answering part of your question. I'll use C/C++ ecosystem
> since it is easier to drive my point home: it will be very difficult for us to
> actually server those users on projects like httpd and subversion. The
> sheer # of variations that we would have to release and test is pretty
> staggering.
Have you been trying to build OpenOffice? Very few will be able to do it as it is a dark art.
>
> To be fair, it gets easier with Docker containers, so for those even httpd
> and subversion can have a canonical container that we recognize. But
> you know what? None of these container will ever be put into serious
> production. They are, however a pretty good "quick start" artifact.
These get huge and podlings want to do it.
>
> What I'm trying to say is this: from a "product management" perspective
> we should assume a very nuanced view of who these users actually
> are and how they are using our projects.
>
> That's a level of sophistication (and frankly the ammount of data points)
> that may not even be available to PMCs.
>
>> 2- A key purpose for incorporation was to be a legal shield for our
>> committers. Presumably this should include most project's release
>> managers, yes?
>>
>> Isn't it a glaring hole that the ASF is explicitly saying - by omission
>> in our legal FAQs somewhere - that we do *not* protect any release
>> manager that puts binary releases on apache.org/dist?
>
> To me -- this is a much more serious question. In fact, I'd rather us either
> outlaw binary releases completely OR protect the RMs. I honestly think
> these are the only two fair choices we have.
Does “certification” help?
>
>> There's a serious legal question here: if a binary does have a problem
>> which causes damage, it certainly seems like the release manager could
>> be personally liable (at least to the point that they actually get sued
>> [1]).
>>
>> More importantly: this potential legal risk is probably not understood
>> by the majority of our release managers. Heck, we've had many of people
>> here deeply familiar with the ASF who still aren't sure of exact
>> agreement how all this works. How can we expect our release managers to
>> really understand the potential personal risk they're taking whenever
>> they ship binaries?
>
> Yup. That's exactly why I think this in-between model is a really dangerous
> stance on our part.
>
>> Note: solving this kind of issue is not something we could get done with
>> our existing volunteers. But I'm wondering if it's something that we
>> should invest some budget resources into.
>>
>> So separately from the many questions I expect, my questions are:
>>
>> - Does anyone reading this list think it would be important to have the
>> ASF provide official binaries? (Or rather: change policies/processes
>> such that PMCs could choose to do so).
>
> I actually don't have a strong opinion here. Honestly, I think if we turn
> around and explicitly outlaw binary releases as part of ASF -- that'd be
> fine for most of our users (the 3d party binaries simply won't be available
> off of ASF distribution channel -- its not like they are going to disappear).
>
> I do believe, however, that our current position puts RMs into a very
> unfortunate situation. So what DOES need to get resolved ASAP is
> whether we extend the shield or outlaw the binaries. We have to decide
> in my view.
We should extend the shield.
>
>> - Do list readers believe release managers understand this issue, and
>> the fact that any binary releases are not official (i.e. are personal)?
>
> I believe you articulated a very important issue and I agree with your
> assessment.
The foundation documents are somewhat Byzantine and I doubt it.
But then there are some RMs like Jim who does not mind producing OpenOffice binaries.
Regards,
Dave
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Binary channels - why don't we support them?
Posted by Ben Laurie <be...@links.org>.
On Fri, 15 Mar 2019 at 12:56, Shane Curcuru <as...@shanecurcuru.org> wrote:
> Ben Laurie wrote on 3/15/19 6:32 AM:
> ...snip...
> >
> > Why not make it so we (or anyone else) can verify binaries? OK, only
> > possible where reproducible builds are possible, but that really ought
> > to be the norm. Given that, its relatively easy...
> >
> > 1. RMs have signing keys which ASF keeps a list of.
> >
> > 2. Releases are published in a verifiable append-only ledger, signed by
> > the RM. (Use Trillian: https://github.com/google/trillian)
> >
> > 3. Anyone who wants to can verify whether an alleged release is correct
> > or not and report to the ASF if not.
> >
> > 4. If found to be doing it wrong, appropriate steps are taken (likely
> > removing RM from the list of "OK RMs").
> >
> > This is not just about trusting/not trusting RMs, its about securing our
> > infrastructure.
>
> This, a thousand times this!
>
> Huge effort? Yes. One worth *investing* in (eyes operations@ list...)
>
I can't commit to much time, but I would be happy to help to the extent I
can. This is a topic I've thought a great deal about over the last several
years. I think it would set a new standard for open source security and
transparency...
Re: Binary channels - why don't we support them?
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Ben Laurie wrote on 3/15/19 6:32 AM:
...snip...
>
> Why not make it so we (or anyone else) can verify binaries? OK, only
> possible where reproducible builds are possible, but that really ought
> to be the norm. Given that, its relatively easy...
>
> 1. RMs have signing keys which ASF keeps a list of.
>
> 2. Releases are published in a verifiable append-only ledger, signed by
> the RM. (Use Trillian: https://github.com/google/trillian)
>
> 3. Anyone who wants to can verify whether an alleged release is correct
> or not and report to the ASF if not.
>
> 4. If found to be doing it wrong, appropriate steps are taken (likely
> removing RM from the list of "OK RMs").
>
> This is not just about trusting/not trusting RMs, its about securing our
> infrastructure.
This, a thousand times this!
Huge effort? Yes. One worth *investing* in (eyes operations@ list...)
--
- Shane
Director & Member
The Apache Software Foundation
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by Ben Laurie <be...@links.org>.
On Fri, 15 Mar 2019 at 09:37, Bertrand Delacretaz <bd...@apache.org>
wrote:
> On Thu, Mar 14, 2019 at 10:48 PM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > ...In fact, I'd rather us either
> > outlaw binary releases completely OR protect the RMs. I honestly think
> > these are the only two fair choices we have....
>
> From the "protect the RM" angle, a few weeks ago I asked here if a
> disclaimer on binaries [1] would help.
>
> Roughly summarizing Roy's reply in that thread, the ASF can get sued
> anyway no matter how we disclaim, but anything we can to do help
> demonstrate that users have read and (at least implicitly) agreed with
> our disclaimers is helpful.
>
> As Roy indicates, businesses often use click-through licenses where
> users declare that they have read and understood the licenses and
> disclaimers.
>
> We can't put click-through mechanisms if front of our release
> artifacts as they go through multiple channels, but how about setting
> up a click-through mechanisms *on the digests* that we distribute to
> verify our artifacts?
>
> Concretely, modify https://www.apache.org/info/verification to point
> to a verify.apache.org website where one has to click through agree to
> our license AND to a disclaimer on binaries as suggested at [1].
>
> IANAL but my understanding is that someone willing to sue the ASF on a
> problem caused by our binaries would have a hard time demonstrating
> that they didn't know about those disclaimers. Anyone who doesn't
> check the digests on binaries that they download from random places is
> not serious and cannot be trusted for anything anyway, right?
>
> -Bertrand
>
> [1]
> https://lists.apache.org/thread.html/7b45fcf8d24997c19edaf0481e5184adfb470e384b3007d0b4a1fe3a@%3Clegal-discuss.apache.org%3E
>
> which is basically: we think our binaries match our source code but
> cannot verify that so if you use them you're on your own
>
Why not make it so we (or anyone else) can verify binaries? OK, only
possible where reproducible builds are possible, but that really ought to
be the norm. Given that, its relatively easy...
1. RMs have signing keys which ASF keeps a list of.
2. Releases are published in a verifiable append-only ledger, signed by the
RM. (Use Trillian: https://github.com/google/trillian)
3. Anyone who wants to can verify whether an alleged release is correct or
not and report to the ASF if not.
4. If found to be doing it wrong, appropriate steps are taken (likely
removing RM from the list of "OK RMs").
This is not just about trusting/not trusting RMs, its about securing our
infrastructure.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: Binary channels - why don't we support them?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Mar 14, 2019 at 10:48 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> ...In fact, I'd rather us either
> outlaw binary releases completely OR protect the RMs. I honestly think
> these are the only two fair choices we have....
From the "protect the RM" angle, a few weeks ago I asked here if a
disclaimer on binaries [1] would help.
Roughly summarizing Roy's reply in that thread, the ASF can get sued
anyway no matter how we disclaim, but anything we can to do help
demonstrate that users have read and (at least implicitly) agreed with
our disclaimers is helpful.
As Roy indicates, businesses often use click-through licenses where
users declare that they have read and understood the licenses and
disclaimers.
We can't put click-through mechanisms if front of our release
artifacts as they go through multiple channels, but how about setting
up a click-through mechanisms *on the digests* that we distribute to
verify our artifacts?
Concretely, modify https://www.apache.org/info/verification to point
to a verify.apache.org website where one has to click through agree to
our license AND to a disclaimer on binaries as suggested at [1].
IANAL but my understanding is that someone willing to sue the ASF on a
problem caused by our binaries would have a hard time demonstrating
that they didn't know about those disclaimers. Anyone who doesn't
check the digests on binaries that they download from random places is
not serious and cannot be trusted for anything anyway, right?
-Bertrand
[1] https://lists.apache.org/thread.html/7b45fcf8d24997c19edaf0481e5184adfb470e384b3007d0b4a1fe3a@%3Clegal-discuss.apache.org%3E
which is basically: we think our binaries match our source code but
cannot verify that so if you use them you're on your own
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 14, 2019, at 2:39 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Wed, Mar 13, 2019 at 6:01 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
>
>> - Do list readers believe release managers understand this issue, and
>> the fact that any binary releases are not official (i.e. are personal)?
>
> I believe you articulated a very important issue and I agree with your
> assessment.
>
I have to disagree with the premise of this. If a PMC decides to release binaries in addition to source it is free to classify them as “official”. Nothing in a PMC’s charter says it isn’t allowed to do this. I don’t know of any PMC that releases binary that treats them in any other way as doing so would be irresponsible.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by Dave Fisher <da...@comcast.net>.
> On Mar 14, 2019, at 4:38 PM, Christopher <ct...@apache.org> wrote:
>
> I really like how Roman has framed it here... in terms of actionable
> choices to either outlaw binaries or protect RMs.
>
> I have observed that some projects make (possibly subconscious)
> decisions in their build systems that prioritize their own convenience
> binaries over buildability from source. A ban on binaries could force
> those projects to do a better job of supporting external/downstream
> builders, and could also help projects grow their communities to
> include more downstream packagers, both of which would be good.
>
> On the other hand, outlawing binaries could be very disruptive for
> established communities, and hurt users, especially for projects like
> Maven, where the upstream builds have (in my opinion) historically
> been higher quality than anything done to package them downstream
> (such as in various Linux distros) or when there are relatively few
> downstream packager alternatives, such as ZooKeeper (as opposed to
> projects which are packaged downstream in every Linux distro, like
> httpd and svn).
Apache NetBeans is about to graduate from the Apache Incubator.
There are currently 676 different release artifacts in their directory. I know because I’ve been revamping the Incubator clutch process which is years out of date. (It didn’t know about git projects for example.)
The bulk of the 676 are binary. Particularly if you look here: https://dist.apache.org/repos/dist/release/incubator/netbeans/incubating-netbeans/incubating-10.0/nbms/platform/ <https://dist.apache.org/repos/dist/release/incubator/netbeans/incubating-netbeans/incubating-10.0/nbms/platform/>. They are all essentially squashed down jar files.
Regards,
Dave
>
> I don't know what the better choice is, but either way, I'd like to
> see all our projects be easier to build from source, and want users to
> have a choice of who to trust for a binary built from our releases.
>
> On Thu, Mar 14, 2019 at 5:48 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>
>> On Wed, Mar 13, 2019 at 6:01 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
>>>
>>> There are a lot of detailed legal and policy discussions on this thread.
>>> But I think we're missing the bigger ASF policy question:
>>>
>>> - Why don't we officially allow projects to release binaries?
>>>
>>> This is a serious question, and one that envisions a much larger scope
>>> of work than perhaps we've historically bitten off, so... just put aside
>>> all the "we've always done it that way" and "too hard" ideas and ponder.
>>>
>>> 1- We're a public charity. Clearly many - by sheer numbers of downloads
>>> - the majority of people who use our software are using binaries,
>>
>> That actually depends on the project (and to some extent the language/runtime
>> ecosystem it lives in). As a blanket statement I don't think it is true.
>>
>>> not source code. Why shouldn't we officially support them?
>>
>> "support" is way too loaded of a term to be used productively in this
>> discussion, I think.
>> After all, there are aspects of "support" that we don't provide for
>> even source releases.
>>
>> Personally, I'd like to focus not on support, but rather on
>> "recognition" (plz suggest
>> a better term). So to me the real question is this: "Why shouldn't we officially
>> recognize binary releases as an act of a foundation".
>>
>>> This is not necessarily a blocking issue; clearly the "unofficial"
>>> binaries many Apache projects provide - or third party packagers - are
>>> physically meeting this need. But still, it's odd that as a public
>>> charity, we're going through hoops to ensure our policies explicitly do
>>> *not* serve these users by claiming we never release binaries.
>>
>> Let me start by answering part of your question. I'll use C/C++ ecosystem
>> since it is easier to drive my point home: it will be very difficult for us to
>> actually server those users on projects like httpd and subversion. The
>> sheer # of variations that we would have to release and test is pretty
>> staggering.
>>
>> To be fair, it gets easier with Docker containers, so for those even httpd
>> and subversion can have a canonical container that we recognize. But
>> you know what? None of these container will ever be put into serious
>> production. They are, however a pretty good "quick start" artifact.
>>
>> What I'm trying to say is this: from a "product management" perspective
>> we should assume a very nuanced view of who these users actually
>> are and how they are using our projects.
>>
>> That's a level of sophistication (and frankly the ammount of data points)
>> that may not even be available to PMCs.
>>
>>> 2- A key purpose for incorporation was to be a legal shield for our
>>> committers. Presumably this should include most project's release
>>> managers, yes?
>>>
>>> Isn't it a glaring hole that the ASF is explicitly saying - by omission
>>> in our legal FAQs somewhere - that we do *not* protect any release
>>> manager that puts binary releases on apache.org/dist?
>>
>> To me -- this is a much more serious question. In fact, I'd rather us either
>> outlaw binary releases completely OR protect the RMs. I honestly think
>> these are the only two fair choices we have.
>>
>>> There's a serious legal question here: if a binary does have a problem
>>> which causes damage, it certainly seems like the release manager could
>>> be personally liable (at least to the point that they actually get sued
>>> [1]).
>>>
>>> More importantly: this potential legal risk is probably not understood
>>> by the majority of our release managers. Heck, we've had many of people
>>> here deeply familiar with the ASF who still aren't sure of exact
>>> agreement how all this works. How can we expect our release managers to
>>> really understand the potential personal risk they're taking whenever
>>> they ship binaries?
>>
>> Yup. That's exactly why I think this in-between model is a really dangerous
>> stance on our part.
>>
>>> Note: solving this kind of issue is not something we could get done with
>>> our existing volunteers. But I'm wondering if it's something that we
>>> should invest some budget resources into.
>>>
>>> So separately from the many questions I expect, my questions are:
>>>
>>> - Does anyone reading this list think it would be important to have the
>>> ASF provide official binaries? (Or rather: change policies/processes
>>> such that PMCs could choose to do so).
>>
>> I actually don't have a strong opinion here. Honestly, I think if we turn
>> around and explicitly outlaw binary releases as part of ASF -- that'd be
>> fine for most of our users (the 3d party binaries simply won't be available
>> off of ASF distribution channel -- its not like they are going to disappear).
>>
>> I do believe, however, that our current position puts RMs into a very
>> unfortunate situation. So what DOES need to get resolved ASAP is
>> whether we extend the shield or outlaw the binaries. We have to decide
>> in my view.
>>
>>> - Do list readers believe release managers understand this issue, and
>>> the fact that any binary releases are not official (i.e. are personal)?
>>
>> I believe you articulated a very important issue and I agree with your
>> assessment.
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> 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: Binary channels - why don't we support them?
Posted by Christopher <ct...@apache.org>.
I really like how Roman has framed it here... in terms of actionable
choices to either outlaw binaries or protect RMs.
I have observed that some projects make (possibly subconscious)
decisions in their build systems that prioritize their own convenience
binaries over buildability from source. A ban on binaries could force
those projects to do a better job of supporting external/downstream
builders, and could also help projects grow their communities to
include more downstream packagers, both of which would be good.
On the other hand, outlawing binaries could be very disruptive for
established communities, and hurt users, especially for projects like
Maven, where the upstream builds have (in my opinion) historically
been higher quality than anything done to package them downstream
(such as in various Linux distros) or when there are relatively few
downstream packager alternatives, such as ZooKeeper (as opposed to
projects which are packaged downstream in every Linux distro, like
httpd and svn).
I don't know what the better choice is, but either way, I'd like to
see all our projects be easier to build from source, and want users to
have a choice of who to trust for a binary built from our releases.
On Thu, Mar 14, 2019 at 5:48 PM Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Wed, Mar 13, 2019 at 6:01 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
> >
> > There are a lot of detailed legal and policy discussions on this thread.
> > But I think we're missing the bigger ASF policy question:
> >
> > - Why don't we officially allow projects to release binaries?
> >
> > This is a serious question, and one that envisions a much larger scope
> > of work than perhaps we've historically bitten off, so... just put aside
> > all the "we've always done it that way" and "too hard" ideas and ponder.
> >
> > 1- We're a public charity. Clearly many - by sheer numbers of downloads
> > - the majority of people who use our software are using binaries,
>
> That actually depends on the project (and to some extent the language/runtime
> ecosystem it lives in). As a blanket statement I don't think it is true.
>
> > not source code. Why shouldn't we officially support them?
>
> "support" is way too loaded of a term to be used productively in this
> discussion, I think.
> After all, there are aspects of "support" that we don't provide for
> even source releases.
>
> Personally, I'd like to focus not on support, but rather on
> "recognition" (plz suggest
> a better term). So to me the real question is this: "Why shouldn't we officially
> recognize binary releases as an act of a foundation".
>
> > This is not necessarily a blocking issue; clearly the "unofficial"
> > binaries many Apache projects provide - or third party packagers - are
> > physically meeting this need. But still, it's odd that as a public
> > charity, we're going through hoops to ensure our policies explicitly do
> > *not* serve these users by claiming we never release binaries.
>
> Let me start by answering part of your question. I'll use C/C++ ecosystem
> since it is easier to drive my point home: it will be very difficult for us to
> actually server those users on projects like httpd and subversion. The
> sheer # of variations that we would have to release and test is pretty
> staggering.
>
> To be fair, it gets easier with Docker containers, so for those even httpd
> and subversion can have a canonical container that we recognize. But
> you know what? None of these container will ever be put into serious
> production. They are, however a pretty good "quick start" artifact.
>
> What I'm trying to say is this: from a "product management" perspective
> we should assume a very nuanced view of who these users actually
> are and how they are using our projects.
>
> That's a level of sophistication (and frankly the ammount of data points)
> that may not even be available to PMCs.
>
> > 2- A key purpose for incorporation was to be a legal shield for our
> > committers. Presumably this should include most project's release
> > managers, yes?
> >
> > Isn't it a glaring hole that the ASF is explicitly saying - by omission
> > in our legal FAQs somewhere - that we do *not* protect any release
> > manager that puts binary releases on apache.org/dist?
>
> To me -- this is a much more serious question. In fact, I'd rather us either
> outlaw binary releases completely OR protect the RMs. I honestly think
> these are the only two fair choices we have.
>
> > There's a serious legal question here: if a binary does have a problem
> > which causes damage, it certainly seems like the release manager could
> > be personally liable (at least to the point that they actually get sued
> > [1]).
> >
> > More importantly: this potential legal risk is probably not understood
> > by the majority of our release managers. Heck, we've had many of people
> > here deeply familiar with the ASF who still aren't sure of exact
> > agreement how all this works. How can we expect our release managers to
> > really understand the potential personal risk they're taking whenever
> > they ship binaries?
>
> Yup. That's exactly why I think this in-between model is a really dangerous
> stance on our part.
>
> > Note: solving this kind of issue is not something we could get done with
> > our existing volunteers. But I'm wondering if it's something that we
> > should invest some budget resources into.
> >
> > So separately from the many questions I expect, my questions are:
> >
> > - Does anyone reading this list think it would be important to have the
> > ASF provide official binaries? (Or rather: change policies/processes
> > such that PMCs could choose to do so).
>
> I actually don't have a strong opinion here. Honestly, I think if we turn
> around and explicitly outlaw binary releases as part of ASF -- that'd be
> fine for most of our users (the 3d party binaries simply won't be available
> off of ASF distribution channel -- its not like they are going to disappear).
>
> I do believe, however, that our current position puts RMs into a very
> unfortunate situation. So what DOES need to get resolved ASAP is
> whether we extend the shield or outlaw the binaries. We have to decide
> in my view.
>
> > - Do list readers believe release managers understand this issue, and
> > the fact that any binary releases are not official (i.e. are personal)?
>
> I believe you articulated a very important issue and I agree with your
> assessment.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Binary channels - why don't we support them?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Mar 13, 2019 at 6:01 PM Shane Curcuru <as...@shanecurcuru.org> wrote:
>
> There are a lot of detailed legal and policy discussions on this thread.
> But I think we're missing the bigger ASF policy question:
>
> - Why don't we officially allow projects to release binaries?
>
> This is a serious question, and one that envisions a much larger scope
> of work than perhaps we've historically bitten off, so... just put aside
> all the "we've always done it that way" and "too hard" ideas and ponder.
>
> 1- We're a public charity. Clearly many - by sheer numbers of downloads
> - the majority of people who use our software are using binaries,
That actually depends on the project (and to some extent the language/runtime
ecosystem it lives in). As a blanket statement I don't think it is true.
> not source code. Why shouldn't we officially support them?
"support" is way too loaded of a term to be used productively in this
discussion, I think.
After all, there are aspects of "support" that we don't provide for
even source releases.
Personally, I'd like to focus not on support, but rather on
"recognition" (plz suggest
a better term). So to me the real question is this: "Why shouldn't we officially
recognize binary releases as an act of a foundation".
> This is not necessarily a blocking issue; clearly the "unofficial"
> binaries many Apache projects provide - or third party packagers - are
> physically meeting this need. But still, it's odd that as a public
> charity, we're going through hoops to ensure our policies explicitly do
> *not* serve these users by claiming we never release binaries.
Let me start by answering part of your question. I'll use C/C++ ecosystem
since it is easier to drive my point home: it will be very difficult for us to
actually server those users on projects like httpd and subversion. The
sheer # of variations that we would have to release and test is pretty
staggering.
To be fair, it gets easier with Docker containers, so for those even httpd
and subversion can have a canonical container that we recognize. But
you know what? None of these container will ever be put into serious
production. They are, however a pretty good "quick start" artifact.
What I'm trying to say is this: from a "product management" perspective
we should assume a very nuanced view of who these users actually
are and how they are using our projects.
That's a level of sophistication (and frankly the ammount of data points)
that may not even be available to PMCs.
> 2- A key purpose for incorporation was to be a legal shield for our
> committers. Presumably this should include most project's release
> managers, yes?
>
> Isn't it a glaring hole that the ASF is explicitly saying - by omission
> in our legal FAQs somewhere - that we do *not* protect any release
> manager that puts binary releases on apache.org/dist?
To me -- this is a much more serious question. In fact, I'd rather us either
outlaw binary releases completely OR protect the RMs. I honestly think
these are the only two fair choices we have.
> There's a serious legal question here: if a binary does have a problem
> which causes damage, it certainly seems like the release manager could
> be personally liable (at least to the point that they actually get sued
> [1]).
>
> More importantly: this potential legal risk is probably not understood
> by the majority of our release managers. Heck, we've had many of people
> here deeply familiar with the ASF who still aren't sure of exact
> agreement how all this works. How can we expect our release managers to
> really understand the potential personal risk they're taking whenever
> they ship binaries?
Yup. That's exactly why I think this in-between model is a really dangerous
stance on our part.
> Note: solving this kind of issue is not something we could get done with
> our existing volunteers. But I'm wondering if it's something that we
> should invest some budget resources into.
>
> So separately from the many questions I expect, my questions are:
>
> - Does anyone reading this list think it would be important to have the
> ASF provide official binaries? (Or rather: change policies/processes
> such that PMCs could choose to do so).
I actually don't have a strong opinion here. Honestly, I think if we turn
around and explicitly outlaw binary releases as part of ASF -- that'd be
fine for most of our users (the 3d party binaries simply won't be available
off of ASF distribution channel -- its not like they are going to disappear).
I do believe, however, that our current position puts RMs into a very
unfortunate situation. So what DOES need to get resolved ASAP is
whether we extend the shield or outlaw the binaries. We have to decide
in my view.
> - Do list readers believe release managers understand this issue, and
> the fact that any binary releases are not official (i.e. are personal)?
I believe you articulated a very important issue and I agree with your
assessment.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
> On Mar 13, 2019, at 6:00 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>
> There are a lot of detailed legal and policy discussions on this thread.
> But I think we're missing the bigger ASF policy question:
>
> - Why don't we officially allow projects to release binaries?
Shane, this is a two month old thread. I have written MANY times
that this is not a legal issue and does not belong on legal-discuss.
This is a policy of the board. Please discuss it within board channels, or within
the mailing list that was specifically created by the board for reproducible builds,
or within some new forum that can attract the interest from folks who are willing
and able to solve the issue to the board's satisfaction. The ASF does distribute
official binaries when performed according to a plan approved by the board.
FWIW, I entirely agree with Ben's approach as well, though the signature
chain is unnecessary (an email containing one signature is still enough to
confirm authenticity), but if the cool tools get more people excited ... go for it.
> 2- A key purpose for incorporation was to be a legal shield for our
> committers. Presumably this should include most project's release
> managers, yes?
No, we are a legal shield for our officers and volunteers taking actions on behalf
of the ASF. That does not include commits and it does not include private builds,
but it does include actions that take place with functional oversight by the PMC
(e.g., releases that have been approved by vote of the committee). This is
valuable because those actions have much more potential for liability.
In order to be a legal shield, we must maintain adequate oversight of those actions
and they have to be clearly indicated as an act of the ASF (e.g., announced, titles,
brand, etc.). We could shield more if we bound our committers to employment
agreements/contracts, mandatory training, etc. Likewise, we can shield the
production and release of binaries, just like any other company, if we have an
approved plan for doing so that is comparable to common business practice.
The shield itself is automatic: when it exists, any individual can invoke that shield
when faced with a legal challenge, whether or not the board agrees. We can't
simply declare a shield exists on its own.
> Isn't it a glaring hole that the ASF is explicitly saying - by omission
> in our legal FAQs somewhere - that we do *not* protect any release
> manager that puts binary releases on apache.org/dist?
No. What we say is that the ASF doesn't release binaries except for a few projects
where a plan is in place to do so. What we choose to protect and what we are a
legal shield for are two different things. We can choose to defend anyone.
We cannot prevent anyone from suing anyone. In some cases, we can argue
to the judge that an individual is only acting according to our policies and with
good intent, so we could ask that they be removed from a suit in favor of the
ASF taking full responsibility for those actions (i.e., invoke the shield). Likewise,
a judge may impose that upon us even without our asking.
I can confidently state that the ASF will, regardless of opinions, step in and accept
responsibility for any act of the foundation taken in accordance with any of
our bylaws and policies. That's why we exist. I can also state that any liability
that exists because of our FORMALLY RELEASED source code will be assumed
by the ASF even if we are only being sued over a binary based entirely on
that source code.
Making official binaries of our released source code is not, and never has been,
a concern for *greater* liability than our source code releases, assuming
we properly review, vote upon, and release that source code. Well, maybe
we increase patent issues with a binary, but that's open to debate.
The liability concern has been about lack of peer review over a binary
resulting in more code being included than what we released as source.
I cannot say that we will be successful in defending some random action or
effect caused by a committer or RM, nor can I guarantee that the ASF will be
willing to step in and defend someone who bypassed our policies.
It would be irresponsible for me to do that on a public forum like this one,
even when I hold no ASF office.
> There's a serious legal question here: if a binary does have a problem
> which causes damage, it certainly seems like the release manager could
> be personally liable (at least to the point that they actually get sued
> [1]).
>
> More importantly: this potential legal risk is probably not understood
> by the majority of our release managers. Heck, we've had many of people
> here deeply familiar with the ASF who still aren't sure of exact
> agreement how all this works. How can we expect our release managers to
> really understand the potential personal risk they're taking whenever
> they ship binaries?
They are (AFAIK) adults. We do what we can. We are fully capable of defending
good actions, to the extent of our available funds and to the extent that the
board is willing to do so. We might even defend careless actions. We are unlikely
to defend actions that are deliberately malicious and made without oversight.
We will defend the ASF's assets, as a whole, regardless.
Again, even though the above comments are about theoretical LEGAL
proceedings, these are board policies we are talking about. If you, as a board
member, wish to discuss the extent of ASF liability with our actual lawyers,
you MUST do so in a private forum. This is not the place.
IANAL. I am ridiculously conservative in these issues, and we have never
been sued, though it would be silly to assume that one has led to the other.
In reality, we are blessed by good luck and everyone's good intentions.
Cheers,
....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Binary channels - why don't we support them?
Posted by Davor Bonaci <da...@apache.org>.
I believe Shane is trying to start a different discussion -- the one that
is not about Incubator mentors, what support means, how hard would it be,
etc.
Shane, I vehemently agree with your sentiment. Some answers below.
- Why don't we officially allow projects to release binaries?
>
I have observed that people make two kinds of arguments:
(1) that ASF is not comfortable supporting (certifying, distributing, ...)
work that is not reviewable by the community. The general idea being that
releasing unverifiable work removes the benefits of open source, having
many eyes on it, etc. They claim that reviewable binaries / reproducible
builds / etc. are one of the necessary conditions for releasing binaries.
(2) that avoiding to release binaries creates space for commercial entities
to provide value, which may entice them to contribute to the project. They
claim that if ASF were to release the binaries, the value of commercial
entities will be smaller (or eliminated) and that would disrupt the project
ecosystem.
I have not seen any other (valid) argument. Personally, I disagree with #1
-- reproducible builds are absolutely fantastic, but I don't believe they
are a necessary requirement. I think it is totally okay to trust the
release manager. I kinda disagree with #2 as well, but the Foundation has
some issues in this space and it feels dangerous to be messing with this
before those underlying issues are better understood and possibly addressed.
> - Does anyone reading this list think it would be important to have the
> ASF provide official binaries? (Or rather: change policies/processes
> such that PMCs could choose to do so).
>
Yes! For all the reasons you mentioned, but primarily we want to serve our
users as best as we can, removing any barriers from usage and charitable
impact.
> - Do list readers believe release managers understand this issue, and
> the fact that any binary releases are not official (i.e. are personal)?
>
Almost nobody understand this, which is crazy.
But, luckily, the fact ASF says "it is not official", it doesn't make it
true. At present time, I believe the foundation is on the hook for binary
releases as much as the release managers are. I'm probably naive, but I'm
hopeful the we wouldn't make a case against our own release manager and try
to throw them under the bus. Instead, I'm hopeful we'd be ethical to
indemnify our own release managers acting in good faith. Our current
position on this is improper.
Davor