|
Boost : |
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-09-11 18:39:16
On Wed, Sep 11, 2024 at 10:08â¯AM Andrey Semashev via Boost
<boost_at_[hidden]> wrote:
> [Warning! Long post ahead!]
This is very well written and thought out, thanks!
> In the Fiscal Sponsorship Agreement (FSA) draft in Appendix 1 of the proposal, two
> Committees are mentioned. ...Maybe there's some legal reason to it
> that I'm not aware of, but it looks like a superfluous entity to me.
I believe it is a construct used for legal reasons. The Current
Committee has no decision making powers until the effective date, when
it becomes the Steering Committee.
> All decisions of the Steering Committee shall be made by
> simple majority.
This applies only to decisions which require the fiscal sponsor to
take an action. For example, to add or remove members of the SC, or to
appoint a new representative. The agreement is silent otherwise. For
example, if Boost wanted to move to GitLab, the fiscal sponsor has no
opinion on that, and the Steering Committee uses whatever process the
community agrees on for making the decision.
The language in the agreement might not make this crystal clear, and
we can explore it before signing. If you are able, I suggest you get
involved in that process. We can arrange to do it by email. The
Current Committee should have its own lawyer to answer questions and
propose changes. The Alliance can pay for that.
> the goal is to ensure that the Steering Committee represents the
> Boost project community rather than The C++ Alliance.
This is where things get a bit ambiguous. Are the folks in the
Alliance not part of the Boost community? For example, Rene is on the
Alliance board of directors (an unpaid position). Is he any less
representative of the project than Peter Dimov? The Alliance is a
non-profit, so there are no direct benefits especially to board
members. If Peter Dimov is on the Steering Committee and he joins the
board of the C++ Alliance does that make him less legitimate as a
member of the SC? If you trust an individual to make decisions
regarding the use of Boost's shared assets, what changes if they join
a non-profit board? This is worth thinking about, since as you pointed
out there is increasing Alliance involvement in the project.
> The second issue is that I find it surprising that FSA is defining the
> decision making process in the Steering Committee in the first place. It
> would seem to me that the Steering Committee should have its own bylaws
I agree, and the FSA has no opinion on how the SC governs itself. I
want to be clear here: the FSA does not define how the Boost project
makes decisions in general. The FSA only specifies how the SC changes
its composition and communicates those decisions to the fiscal
sponsor.
> Another thing that bothers me is that The C++ Alliance reserves the
> right to appoint members of the Steering Committee to bring its size up
> to three members. I realize that this is supposed to be an emergency
> plan of sorts, but it seems wrong that The C++ Alliance is making the
> pick. It would seem, the self-preservation plan should be in the
> Steering Committee's bylaws, and The C++ Alliance should not be acting
> in its place.
The Steering Committee has no bylaws, because the SC is not a legal
entity. It is a set of individuals recognized as a group only to the
extent of what is defined in the FSA. If it did have bylaws, it would
apply to its board of directors. And the rules for corporations
require a board of directors to have at least 3 people :) If Boost
can't keep 3 people on the Steering Committee, the project has bigger
problems than Alliance taking action.
> It might be my poor understanding of the legal wording, but it looks
> like this suggests that the Steering Committee is operating under
> control of The C++ Alliance's Board, which contradicts with the first
> part of the sentence.
In plain language, the agreement provides that the Steering Committee
directs the use of the shared assets, and the fiscal sponsor has a
right to veto if that usage conflicts with regulatory compliance. In
theory the fiscal sponsor could obstruct a valid request, and this is
balanced by the ability of the Steering Committee to invoke the
termination clause.
Interestingly, that is exactly where we are now with the Boost
Foundation. They have vetoed a valid decision from the project. The
difference is that there is no legal agreement between Foundation and
Boost, and no termination clause. Thankfully, the Boost Foundation has
offered the community the possibility of changing this arrangement.
> I would like to comment on the section 8 of the FSA, "Termination". I'm
> not familiar with the US laws, but do the timeouts for searching for a
> Successor allow for registering a new 501(c)(3) entity for the purpose
> of passing the assets to it? The way the section 8.d "Termination
> Without a Successor" is phrased implies that the assets could
> potentially be destroyed or otherwise made permanently unavailable to
> the Project. I'm wondering if there is a better solution, like creating
> a new non-profit for the purpose of passing it the assets. I admit I'm
> completely clueless in this domain, I'm just looking if the Termination
> terms could be improved for Boost. Especially, in the case if The C++
> Alliance is no longer able to fulfill its sponsorship.
I agree this needs to be looked at more closely.
> I would like to ask the Alliance to be transparent about their planned
> and ongoing activities wrt. Boost assets to avoid situations like this
)> in the future.
We have and will continue to be transparent as you advise. Note,
however, that the boost.org domain was never a "Boost asset" in the
legal sense. To my knowledge, it is still not a Boost asset, and the
domain is still at risk of loss. That is, if the executor of the
estate were to pass away then the ownership of the domain would be in
question. It could be donated to an unrelated organization as per
Beman's last will and testament (which is a public record), or it
could be lost to an auction. Perhaps there is already an agreement in
place that the community is unaware of and I am wrong. I hope so.
Thanks
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk