Mailing List Archive

Mark Collier wrote:
> Today the first draft of the Bylaws for the OpenStack Foundation were published on the wiki here: http://wiki.openstack.org/Governance/Foundation/Bylaws, per the process detailed on the wiki: http://wiki.openstack.org/Governance/Foundation/DraftingCommitteeProcess
> [...]

Nice work! A few remarks from my first pass at reading it.

General remark: A board of 24 sounds a bit huge, but I guess there is no
way around it with 8 proposed platinum members and the tier rule for
Gold and Individual members.

Article I, Section 2:
"A Technical Committee shall [...] admit new projects to incubation. A
Board of Directors shall [...] admit new projects into core OpenStack
after incubation."

I certainly see the value of having the Board and the Technical
Committee involved in selecting projects that get into Core. However,
the question of being ready to graduate from incubation to core is a
technical decision based on the maturity of the project and how well
aligned it is with the obligations of a unified release cycle. Maybe the
technical committee should propose projects (for incubation, for core)
and the board should ultimately approve those ? That way both incubation
and core graduation would have to be approved by the TC *and* the board.

Article II, Section 4:
"The size of the Gold Membership shall not exceed twenty four (24) members."

I'm not sure what's the goal behind that. Avoid dilution of the original
Gold members ? If a 25th company wants to get into the Foundation, why
would it be less relevant than the 24th ? There is no risk of board
inflation: they would elect 8 members anyway.

Article III:
"On the written request of at least three (3) representatives to the
Technical Committee, the Board shall appoint a mediator to assist in the
resolution of any dispute or deadlock in the Technical Committee."

There shouldn't be any deadlock, since the TC uses voting to decide.
There is certainly value in mediation in extreme dispute cases, but I
think the vote of the committee should decide disputes in most of the
cases. We shouldn't have a mediation every time 3 representatives of the
TC are a minority in a vote... so I'm not sure how to limit abuse of
this clause.

--
Thierry Carrez (ttx)
Release Manager, OpenStack
_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Since it was mentioned on the other list:

> Article VIII, Section 1.
> The Project shall not accept contributions of software code unless
> such contribution is made on the terms of the Apache 2.0 license

What happens if Apache Software License 2.0 is obsoleted, by court order
or upgraded by ASF?

Does it make sense to leave in the bylaws the generic principle for the
license of choice and leave to the board the honor to define the actual
license based on the best available possibility at the time?

/stef
_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Hi Stef,

On 5/11/2012 4:56 PM, Stefano Maffulli wrote:
> Since it was mentioned on the other list:
>> Article VIII, Section 1.
>> The Project shall not accept contributions of software code unless
>> such contribution is made on the terms of the Apache 2.0 license
> What happens if Apache Software License 2.0 is obsoleted, by court order
> or upgraded by ASF?
>
> Does it make sense to leave in the bylaws the generic principle for the
> license of choice and leave to the board the honor to define the actual
> license based on the best available possibility at the time?

If that happens, then the bylaws can be changed via Article X, Section
1, (i):

A motion to amend Article VIII (/Intellectual Property Policy/) shall be
adopted only if approved by each of the following: (A) a two-thirds
(2/3)vote of the Platinum Membership, (B) a two-thirds (2/3) vote of the
Gold Membership, and (C) a majority vote of the Individual Membership in
which at least twenty five percent (25%) of the Individual Membership
participates. A change in Article VIII (/Intellectual Property Policy/)
shall be effective beginning thirty (30) days following the completion
of all votes approving the motion, and shall apply only to Project
contributions made after the effective time of the change;

A deprecation of the Apache License is just the sort of thing that would
likely give rise to this super-majority.

Thanks,
Van

Hi Stefano,

Apache V2 is a license which is sufficiently lax that it will likely be compatible with it, and contributions accepted under it can be relicensed without requiring a copyright assignment or similar.

Regards,
Dave.

"Stefano Maffulli" <stefano@openstack.org> wrote:

>Since it was mentioned on the other list:
>
>> Article VIII, Section 1.
>> The Project shall not accept contributions of software code unless
>> such contribution is made on the terms of the Apache 2.0 license
>
>What happens if Apache Software License 2.0 is obsoleted, by court
>order
>or upgraded by ASF?
>
>Does it make sense to leave in the bylaws the generic principle for the
>license of choice and leave to the board the honor to define the actual
>license based on the best available possibility at the time?
>
>/stef
>_______________________________________________
>Foundation mailing list
>Foundation@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Mon, 2012-04-30 at 19:12 -0400, Mark Collier wrote:
> Today the first draft of the Bylaws for the OpenStack Foundation were
> published on the wiki here:
> http://wiki.openstack.org/Governance/Foundation/Bylaws

Really nice to see these published!

I like Thierry's comments, but I'd also add that it would be good to see
the complexity of the bylaws reduced as much as possible. IMHO, they
should only encode those things we feel as fundamental to the working of
the Foundation and everything else should be changeable by a vote of the
Foundation board. I'd hate to see us having to call a full vote of of
the Foundation membership to make relatively trivial changes.

In that vein, I'd really like to see this simplified:

Article VIII, Section 1. Apache License and CLA. The Project shall not
accept contributions of software code unless such contribution is made
on the terms of the Apache 2.0 license, and the contributor has
executed the applicable Contributor License Agreement attached as
Appendix 4. The Board may adopt additional contributor license
agreements as may be appropriate to secure a license on the same terms
as stated in the Contributor License Agreements attached on Appendix 4
from entities other than those covered by those Contributor License
Agreements, or by contributors in non -United States jurisdictions.

To something like:

Article VIII, Section 1. Apache License. The Project shall only accept
contributions of software code where such contribution is made under
the terms of the Apache License 2.0. The Board may adopt whatever
contribution process it deems necessary to ensure the correct
licensing of contributions.

i.e. please let's not make it so difficult to move from the CLA process
to something like the kernel's Signed-off-by process as discussed
previously:

https://lists.launchpad.net/openstack/msg06639.html

> This is the one area that some form of "contributor agreement" makes
> sense to me - requiring the contributor to explicitly make their
> licensing intent clear.
>
> Simply adding Signed-off-by: to a commit message would be my
> preferred way of doing it, but do you think that helps clarify the
> intent or even whether such clarification is useful?

I like the Linux kernel approach (Signed-off-by requirement with a
brief but explicit explanation of what that actually means [the
"Developer Certificate of Origin"] in the patch-submission
documentation in the kernel source tree[1]). I'm known for voicing
skepticism about contributor agreements but I've recommended use of
"signed-off-by" to a number of projects.


I do think a change like this needs debate and proper consideration, but
I trust the board will be perfectly capable of doing this with the help
of the Legal Committee.

To me, it's a perfect example of what we should omit from the bylaws.
Yes, by all means require the Apache License, but why require a CLA?
Especially since changing the clause invokes this:

(i) A motion to amend Article VIII (Intellectual Property Policy)
shall be adopted only if approved by each of the following: (A) a
two-thirds (2/3)vote of the Platinum Membership, (B) a two-thirds
(2/3) vote of the Gold Membership, and (C) a majority vote of the
Individual Membership in which at least twenty five percent (25%) of
the Individual Membership participates.

Cheers,
Mark.

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Mon, May 21, 2012 at 04:43:50PM +0100, Mark McLoughlin wrote:
> In that vein, I'd really like to see this simplified:
>
> Article VIII, Section 1. Apache License and CLA. The Project shall not
> accept contributions of software code unless such contribution is made
> on the terms of the Apache 2.0 license, and the contributor has
> executed the applicable Contributor License Agreement attached as
> Appendix 4. The Board may adopt additional contributor license
> agreements as may be appropriate to secure a license on the same terms
> as stated in the Contributor License Agreements attached on Appendix 4
> from entities other than those covered by those Contributor License
> Agreements, or by contributors in non -United States jurisdictions.
>
> To something like:
>
> Article VIII, Section 1. Apache License. The Project shall only accept
> contributions of software code where such contribution is made under
> the terms of the Apache License 2.0. The Board may adopt whatever
> contribution process it deems necessary to ensure the correct
> licensing of contributions.
>
> i.e. please let's not make it so difficult to move from the CLA process
> to something like the kernel's Signed-off-by process as discussed
> previously:
[...]
> To me, it's a perfect example of what we should omit from the bylaws.
> Yes, by all means require the Apache License, but why require a CLA?
> Especially since changing the clause invokes this:
>
> (i) A motion to amend Article VIII (Intellectual Property Policy)
> shall be adopted only if approved by each of the following: (A) a
> two-thirds (2/3)vote of the Platinum Membership, (B) a two-thirds
> (2/3) vote of the Gold Membership, and (C) a majority vote of the
> Individual Membership in which at least twenty five percent (25%) of
> the Individual Membership participates.

I agree entirely (in fact, I think that was me you quoted in what I
snipped :). Note: I am serving on the drafting committee for the
OpenStack Foundation governance documents as Red Hat's representative,
and have made essentially the same suggestion to that committee.

A partial per-class supermajority requirement to change an outbound
project license makes some sense, or at least is fairly harmless (as
it mirrors the conservatism around outbound licensing that typically
exists naturally for projects).

But a partial per-class supermajority requirement to change something
like a *CLA*, baked into the *bylaws*? This is a very unwise
policy. Speaking from the benefit of several years of experience as
Red Hat's open source lawyer, it is frequently the case that
modifications and adjustments to contributor agreements and
contribution policies are necessary and desirable. The choice of a
particular CLA does not rise to the level of what's so fundamental as
to be sensible to specify in the Foundation's bylaws with amendments
intentionally made difficult.



Richard Fontana
Open Source Licensing & Patent Counsel
Red Hat, Inc.



_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation