It all makes sense to me. I think there are two key points that are driving
all of this discussion:
"5. Disclaimers generally don't remove liability"
IANAL so I don't know if that's true or not. For sure there are lots of
disclaimers in the world. I do not know the history of the current DISCLAIMER
(and labeling of releases with -incubating). What was the DISCLAIMERs original
purpose? Should it be modified to cover less-than-perfect podling releases,
especially around CatX inclusions? Who gets to make that call?
" It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good."
I think several "prominent" ASF members are saying this same thing, but nobody
really wants to make it official. The responsibility seems to have been passed
around between IPMC, Board, and VP Legal. How can the ASF get closure on this
topic?
My 2 cents,
-Alex
On 6/20/19, 10:04 AM, "David Nalley" <da...@gnsa.us> wrote:
There's been a lot of discussion in various threads about bureaucracy,
whether podlings are part of the ASF, etc. As a result of that I've
spent a good deal of time reading resolutions and older discussions
and organizing those thoughts from a legal and community perspective.
I've also read a number of conversations from the more august members
of our body about this subject. Altogether it has somewhat changed
some of my opinions and assumptions. I've also sensed that there is a
community/business/legal disconnect in our conversations. We're using
the same words to mean very different things in each of those
contexts. That said I am but one member of the IPMC, but maybe this
will be helpful to someone else - I've tried to avoid my assumptions
in this.
The IPMC's first 'job'[1] is "accepting new products into the
Foundation" The second 'job' of the IPMC is to "provide guidance and
support to ensure that the Incubator's sub-projects[2] develop
products according to the Foundation's philosophy and guidelines". The
final 'job' is evaluating the products and determining whether they
should be abandoned, continue to receive guidance and support, or be
promoted to "full project status".
So there are several realizations I gained from this from the
Incubator perspective.
1. Acceptance into the Incubator is acceptance of the product into the
Foundation.
2. That product is then a sub-project of the Incubator.
3. The IPMC has the "primary responsibility for the management of
those subprojects".
From the Foundation's perspective there are a number of things that
come to mind:
1. We aren't a github/sourceforge/google code type platform where
random people can upload/post what they want.
2. We do not have DMCA Safe Harbor protection - e.g. we are
responsible for everything that we publish or distribute. With the
exception of wikis and bug trackers anyone who can put something up on
an Apache property has some form of legal relationship with the
Foundation. This could be as simple as an ICLAs where you've
contractually said you won't contribute anything you don't have rights
to.
3. Most of the project's who have come to us aren't entities in and of
themselves. E.g. the 'project' doesn't truly exist from a legal entity
perspective - and even those who do are at best an unincorporated
association of individuals. From a legal perspective - projects can't
make or distribute a release - they don't exist - only the ASF and the
individual(s) doing the work. Given that one of the explicit reasons
the Foundation was created was to[5]: "provide a means for individual
volunteers to be sheltered from legal suits"; we want them to create
and distribute releases as the Foundation.
4. Whether we like it or not - the Foundation is judged on the output
from our projects and subprojects. We have a reputation of having
clean IP, permissively licensed open source code, with clear
provenance. Many people explicitly copy our standards, guidelines, and
policies because they are the gold standard for good open source
governance.
5. Disclaimers generally don't remove liability, and even if they did,
our disclaimer talks about the maturity of our projects. - And it
certainly doesn't remove the public's expectations from us - frankly -
losing the publics trust is as scary as the potential legal liability.
6. The Board has delegated the responsibility of managing and ensuring
adherence to policies and guidelines to the IPMC. I don't see this
responsibility as boolean. It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good.
From a podling's perspective:
1. Once you join the incubator you're a part of the ASF (Yay!?)
2. Your project is now a subproject of the IPMC.
3. There are rules, and you're entering a world of pain[4] In fact,
you're likely to find that the ASF has more rules and structure that
apply to projects than virtually any other home your project could
choose. This is good and bad.
4. The incubator has a long, storied history of producing successful
projects that flourish.
[1]
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache.org%2Ffoundation%2Frecords%2Fminutes%2F2002%2Fboard_minutes_2002_10_16.txt&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=ohGIgOepkDRYbh%2Fd69YFASb%2BHe0BHOfHeWD1ArH1kn8%3D&reserved=0
[2] What we call Podlings, the initial resolution refers to as
subprojects of the Incubator
[3] It's worth noting that there were two resolutions proposed to
create the Incubator - small differences, but interesting to read the
differences.
[4]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F3vB9U2hx6Qg&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=qg%2FxPScn07i1mnnurxsS1d9TZW2myxfAJBWV4U3kj8U%3D&reserved=0
[5]
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Ffaq.html%23why&data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&sdata=SbrEmxffhCoR5QXD3hpqXIcXMBs8I8tEoDsRrJSxqWY%3D&reserved=0
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
