incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ซ่อยค่อย ลืมเขาแน่ <0989132858...@gmail.com>
Subject Re: Podlings, the Incubator, relationships and Apache
Date Sat, 22 Jun 2019 14:20:50 GMT
ในวันที่ ศ. 21 มิ.ย. 2019 23:22 Alex Harui <aharui@adobe.com.invalid>
เขียนว่า:

> 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" <david@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&amp;data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&amp;sdata=ohGIgOepkDRYbh%2Fd69YFASb%2BHe0BHOfHeWD1ArH1kn8%3D&amp;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&amp;data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&amp;sdata=qg%2FxPScn07i1mnnurxsS1d9TZW2myxfAJBWV4U3kj8U%3D&amp;reserved=0
>     [5]
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apache.org%2Ffoundation%2Ffaq.html%23why&amp;data=02%7C01%7Caharui%40adobe.com%7Cf7c5e39c364b4bf8fff008d6f5a159f7%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636966470679352679&amp;sdata=SbrEmxffhCoR5QXD3hpqXIcXMBs8I8tEoDsRrJSxqWY%3D&amp;reserved=0
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>     For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message