Foundation ownership and fiscal hosting

[ebullient]

I'm working on the draft fiscal hosting policy (yes, I will share it soon). There are a few loose ends I'm trying to tie up to simplify the reviewing process, and one of those areas is establishing clarity around what the foundation needs to own.

Trademarks are the most obvious, and we've talked about those and have decent policies around those (Trademark and IP), both of which are pending final approval.

Domains are the next most obvious, though we don't have that crisply written down as a policy yet. What I intend is for the foundation to own the domain while delegating access for domain management to project members

Email: The foundation can provide email support as a foundation benefit.

• Other email-related subscription services would have to be discussed. Monthly incurred cost for a single project would have to be offset by recurring revenue in the project's restricted fund, I think or you put the foundation/other projects at risk.

• Mailing lists are a question. We have a google workspace, and I believe can do some things related to subdomain aliasing. Knowing what folks use vs. what they need going forward would be a good thing, and if anyone else is interesting in scouring Google Workspace docs to figure out what other cool things we can do there, that would be lovely.

Source Code: Is it always a GitHub (or gitlab, ...) organization (with an administrative application installed and clear sponsorship relationship established between GH Organization and the Foundation)?

• Doing it this way would imply all repositories within that organization are also owned by the Commonhaus Foundation and subject to its policies (which then delegate decision-making and some policy choices to the project)

• If it is not an entire GH organization, and is instead a single repository, how do you indicate that transfer? Do we move those single repositories into a common parent? (commonhaus-projects) with teams allocated to manage each?

I have more questions here than answers. ;)

Also, see #166 (Cloud accounts) and #167 (sponsorships)

[yrodiere]

Domains are the next most obvious, though we don't have that crisply written down as a policy yet. What I intend is for the foundation to own the domain while delegating access for domain management to project members

+1 sounds perfect.

Monthly incurred cost for a single project would have to be offset by recurring revenue in the project's restricted fund, I think or you put the foundation/other projects at risk.

I think that better be a general rule, it's not just about emails. What I don't know is if that needs to be cast in stone, or left to the appreciation (common sense, really) of the board. Politics may happen.

Mailing lists are a question. We have a google workspace, and I believe can do some things related to subdomain aliasing. Knowing what folks use vs. what they need going forward would be a good thing, and if anyone else is interesting in scouring Google Workspace docs to figure out what other cool things we can do there, that would be lovely.

Note that in that area, some projects might want to stick to existing infrastructure (e.g. Jboss for Hibernate) due to the infra move being a lot of work and the mailing lists not be used enough to justify the investment. I think we've established in the past that would be fine, but I may be wrong.

Source Code: Is it always a GitHub (or gitlab, ...) organization (with an administrative application installed and clear sponsorship relationship established between GH Organization and the Foundation)?

Seems like the most convenient solution by far IMO. And it makes sense for Hibernate at least. I'd suggest checking with current projects and going for this unless there's a valid reason not to.

Also, GitHub organizations using the name of a trademarked project as is, without any disclaimer, might be infringing on that trademark anyway, so I suspect they'd be on shaky legal grounds if they were not "owned" by Commonhaus.

Doing it this way would imply all repositories within that organization are also owned by the Commonhaus Foundation and subject to its policies (which then delegate decision-making and some policy choices to the project)

Given the relatively low degree of interventionism of Commonhaus, that seems like an acceptable trade-off. Especially since owning a repository doesn't mean owning the code, copyright being a completely separate notion.

[gavinking]

Is it always a GitHub (or gitlab, ...)

I understand that it's in some ways more convenient to hardcode "GitHub" into the bylaws/policies, but would it be too much of a pain to just say "council approved hosting provider"?

[ebullient]

In some cases, it's more expedient to just call out GitHub than it is to dance around it. I might look at pulling GitHub specifics out of the bylaws, but I'm not sure it is worth the effort right now. The bylaws are about procedures, and we're procedurally reliant on GitHub as a platform at the moment. If/when that changes, I think it's fine to look at making this stuff more generic (though in all honesty, it would be better to directly state what is required / how things will work for decision making / record keeping at that time).

There is some text in there about code and other resources not having to be GitHub based, but decision making very much is, and I don't see that it is worth the extra time to make that more obscure/less obvious so that someone has to read something else for the specifics.