incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Podlings, the Incubator, relationships and Apache
Date Fri, 21 Jun 2019 16:22:36 GMT
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

" 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,

´╗┐On 6/20/19, 10:04 AM, "David Nalley" <> 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
    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
    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
    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.
    [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
    To unsubscribe, e-mail:
    For additional commands, e-mail:

View raw message