El 06/03/2024 a las 17:37, David Sankel via Boost escribió:
On Tue, Mar 5, 2024 at 6:43 AM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
Andrey Semashev via Boost wrote:
Now the next question is: *What's missing technically so that the new website can to live?*
If you mean switching boost.org to the new website then the IP and control issue I mentioned is blocking it.
The IP issue is the logo and, indeed, removing it or replacing it with something the Boost Foundation can enforce the copyright of would be sufficient.
Hi David, I'm not sure I follow the issue. I might lack some information, I have the impression that past experiences and interactions are deeply affecting this new website process. Let me please at least express my concerns as a long-time boost contributor. AFAIK current logo is not owned by the foundation, and we have no serious problems with that. Why is an important problem now? IMHO the important points wrt the logo are the license and terms of use, we should focus on that first. Just like we focused on the license/TOU/privacy parts of the proposed website. In the Boost tradition, decisions are made by developers, not by users, Steering Committee, Foundation, or any other organization that contributes (CppAlliance, github). The last time the foundation tried to make a "Boost decision" it didn't work for this very reason. If CppAlliance or any other entity tries to interfere it simply won't work if developers don't like the idea. If CppAlliance does anything that irritates the community, website code will be forked and put in a new server if needed or the old website will be resurrected. That's why we requested a license change.
The bigger technical issue is governance/ownership of the server. Putting key pieces of infrastructure under control and charity of a single individual has worked out very poorly for us in the past. My serious concerns about the particular individual are actually besides the point. The technical obstacle here is to get some Boost Foundation servers up and running with the new site. This will be discussed at the Boost board meeting next week.
IMHO, by definition, the ownership of the server is not a technical issue, but a governance/trust issue. Boost libraries and tools are hosted in Github, and they are certainly more important than the website. BSL is what protects us from anyone "owning" anything. My proposal is to follow the tradition and appoint trusted individuals (more than one) in the developer community to have admin access to that infrastructure, just like we have trusted individuals on other key services (Github, mailing list moderation, review/release managers...). As I said in previous posts, I'm grateful to all past and present members of the Foundation for their time, work, money and effort. But with all due respect, the Boost board's mission is not to govern the boost project, including the website, but to seek community-driven leadership, and I wholeheartedly agree with that. The developer community can and should decide if the requested actions were satisfactory and pointing boost.org to the boost.io server is the appropriate/mature/recommendable solution. We have an issues list that can be tracked to judge if the new website is serving well. If not, the developer community can decide to rollback that decision. We have requested several changes including license, code hosting, etc. to minimize risks and to treat the new proposed website in the boost tradition. Until now, folks from C++ Alliance have been responsive to community requests. License, repository, TOU and Privacy policies have been effectively changed. So I'm optimistic about the process, it's working. We historically don't request any IP/copyright reassignments (e.g. we don't endorse something like FSF's copyright assignment program) because we like to honor creators and because BSL plays nice with non-free software. Honestly, we should continue along that path. The best decision for the Boost project is to reach an agreement between developers, Foundation and Cpp Alliance, taking into account the consensus-building tradition and federated nature of Boost. I hope we can solve this discussion soon and then concentrate our efforts in our next challenge. Best, Ion