pon., 9 wrz 2024 o 23:37 Vinnie Falco napisał(a):

On Mon, Sep 9, 2024 at 1:46 PM Andrzej Krzemienski via Boost wrote:

...

I have a couple of questions to the C++ Alliance representatives regarding the Fiscal Sponsorship Proposal.

First, the proposal is very clear and informative. Thank you for this.

Happy to answer any questions you have, and thank you for reading.

...

I still have some questions, though. In Appendix 1: ...

With permission from the Software Freedom Conservancy we have taken the original Fiscal Sponsorship Agreement and made very small edits to it. Paragraphs 2.c and 3 which you refer to have to do with no-profit compliance. Some explanation on how these agreements are structured is worthwhile.

Donations made to a 501(c)(3) are only exempt from taxes when the usage of those assets complies with regulations. The fiscal sponsor bears ultimate responsibility for regulatory compliance for the projects that it takes on. Any practical agreement needs to allow for the fiscal sponsor to veto use of resources which it believes to be out of compliance Otherwise, the fiscal sponsor is bound to carry out the instructions of the Steering Committee. The contracts are written this way to protect the non-profit organization from losing its tax-exempt status.

The legal agreement in Appendix 1 of the Alliance proposal is intended only as a draft. It shows the spirit of what the final agreement will look like, expressed as three core elements:

* A Current Committee composed only of active Boost contributors * The Steering Committee determines the artistic, technical, and philosophical direction of the Project * The ability to terminate

If our fiscal sponsorship proposal is accepted, the process for signing the agreement will look like this:

1. The review manager will determine the Current Committee (unless there's a better idea) 2. A representative of the Current Committee will select a law firm to act as legal counsel 3. Alliance and Boost's representative, with their respective counsel, will negotiate the final agreement

I have quite a lot of faith in the agreement which the Software Freedom Conservancy put together, so there is hopefully not much need to negotiate changes. However, to do things properly, the individuals on the Current Committee must have the opportunity to ask questions and propose changes through their own legal counsel who represents them and not C++ Alliance.

...

1. When I am a maintainer of a library, what does it make me in the light of this agreement? Am I part of the Project? Or a donor to the Project? Or something else?

Great question, thanks :) With respect to the fiscal sponsorship agreement, there is no direct relationship. The FSA only establishes how Boost's shared assets are owned and controlled. Those shared assets would consist of:

* domain names * trademarks * donations

In particular, the Boost GitHub organization is not included in this list, as one cannot legally own a GitHub organization (it is the private property of GitHub). As a maintainer or author of repositories that are transferred to the Boost GitHub organization, your relationship is with the users in the Boost GitHub organization who have the Owner role. By extension of this logic, the agreement establishes no relationship concerning the triannual releases.

The fiscal sponsorship agreement only covers what is officially donated to Boost. This means nothing changes upon the execution of the agreement, until at such time something is donated to Boost, by submitting a written statement to the C++ Alliance and effecting the means to transfer the asset (a bank wire, or a domain name transfer for example).

...

2. I have a problem internalizing who decides and signs-off on the complement of the Current Committee. Don't get me wrong. I personally support the proposed complement (including the proposed amendments); I just wonder how it works logically/legally. The Current Committee cannot appoint itself. The Alliance cannot arbitrarily say "you, you, and you". Is this Boost Asset Stewardship Review a vehicle for the legitimization of the Current Committee?

Another great question, thanks! I selected the three initial members of the Current Committee based on their history with Boost and high level of activity on the mailing list. The composition of the current committee is of course negotiable. There are already calls to add Glen Fernandes and Peter Dimov. It would be best for the project if the reviewers and the review manager determine the initial set of members. I'm happy to make any changes.

With respect to the logical or legal component, the Current Committee can in fact appoint itself. The FSA is strictly an agreement between the C++ Alliance and the individuals listed. The more interesting moment is when an asset is donated to Boost. This is what defines the legitimacy of the Steering Committee. If a donor believes the Steering Committee legitimately speaks for the project then they donate the asset.

To put it a different way, this review is a referendum on Boost Foundation's governance. If the Foundation governance is rejected, something must take its place. There is nothing particularly wrong with Alliance governance, and I think the morale of the project would be better if the community selected its own leadership. After Boost's founders departed, the community never had a say in how the project should be governed. I am excited that Boost has this opportunity (graciously made possible by the Boost Foundation) for self-determination.

...

Paragraph 8.d says, "If no Successor is found, Alliance may dispose of the Project assets and liabilities in any manner consistent with applicable tax and charitable trust laws." This sounds very harsh to me. If the Project faces the necessity to find another sponsor, and this fails, is the Alliance allowed to offer the domain name for sale, get rid of the mailing list archives, or offer the logo to someone else?

I agree, and I have this in my notes. The project should have more time to find a successor. On the other hand, this is what Boost had with the Software Freedom Conservancy so maybe there are some legal nuances that we are unaware of? I think, before this is signed, we should get a legal opinion to answer this question.

...

Appendix 3 -- I do not see how it illustrates the boost.org Domain Registration Expiration

The image in Appendix 3 is what users saw when they navigated to boost.org in their browser when the domain expired. There was a discussion on reddit about this.

...

Appendix 6 -- It is very nice promotional material. Thank you for doing this.

Appreciated :)

...

But the term "the Official C++ Language Slack Workspace" draws my attention, and I have always wanted to ask this: what makes this slack workspace "official"? Neither Boost nor the C++ Alliance represents C++ or could make decisions or blessings in the name of C++. So, is it not a stretch?

It is official by fiat. No one owns the term "C++."

Thanks

Thanks Vinnie. This is a very informative reply. Let me summarize to see if I understood. Should the outcome of this review be to accept the Fiscal Sponsorship Proposal by C++ Alliance: * the contents of the agreement between the Current Committee and the C++ Alliance are yet to be constructed. Appendix 1 of the proposal is only there to give an idea of how the actual agreement might look like * the Current Committee will self-appoint itself, but the "accept" outcome of this review will be a confirmation that the Boost Developer Community actually approves this * the Boost Foundation will be able to pass the ownership of the Boost assets to the C++ Alliance, and the "accept" outcome of this review will be a confirmation that the Boost Developer Community actually approves this Is this a fair summary? Glen, as the review manager, is this also your understanding? Regards, &rzej;

wt., 10 wrz 2024 o 14:54 Vinnie Falco napisał(a):

...

* the contents of the agreement between the Current Committee and the C++ Alliance are yet to be constructed. Appendix 1 of the proposal is only

On Mon, Sep 9, 2024 at 11:38 PM Andrzej Krzemienski wrote: there to give an idea of how the actual agreement might look like

The agreement in Appendix 1 is almost identical to the agreement signed between the Software Freedom Conservancy and Beman plus other project representatives. "Yet to be constructed" implies it must be written from scratch, which is not accurate. There is a good chance that the text in Appendix 1 will work without modification. And if there are modifications they would be minor. Remember, Beman negotiated with Software Freedom Conservancy a fair bit to arrive at the document shown.

Acknowledged. The unfortunate formulation on my part. Regards, &rzej;

The other items sound right.

Thanks