GNU bug report logs -
#76503
[GCD] Migrating repositories, issues, and patches to Codeberg
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Thank you for addressing the points one by one. Few reactions below, I
have omitted those where I have nothing more to say.
Ludovic Courtès <ludo <at> gnu.org> writes:
> Tomas Volf <~@wolfsden.cz> skribis:
>
>>> (https://codeberg.org/Codeberg/org/src/branch/main/TermsOfUse.md)
>
>> I went through the Terms of Use and picked few points I considers
>> problematic and/or note worthy.
>
> As mentioned in my initial reply¹, this shouldn’t be frame as us-vs-them
> (let alone harsh language), but rather as:
>
> 1. Is it a blocker?
Probably not for the project. ^_^ Though for me personally the § 3 (4)
is a blocker. I cannot in good faith agree to check the website every
three months, because I know I will not be doing that. I have already
failed at it once and I know it would happen again.
> 2. If not, how can we work with Codeberg e.V. on that once we’ve
> switched to Codeberg.
>
>
>> § 2 (1) 4. forces us to rewrite repository history in case of
>> compromise,
>
> I definitely don’t read it that way: it’s not about “compromised” code
> as in “CVE in guix-daemon”, and it’s not about genuine bugs either.
Hm I probably was not clear enough. I simply do not know what Guix
policy here is, so I just wanted to bring this up.
If some committer is compromised, and malicious commit gets pushed
upstream, what will Guix do? Revert the commit? Or rewrite the history
and remove it completely?
If latter, this point is moot and you can stop reading.
If former, I am not sure that would comply with the ToU.
>
>> § 2 (5), especially the "its reputation" part, can easily lead to
>> loosing Codeberg account, and therefore ability to contribute to Guix,
>> over, for example, Mastodon toot complaining that Codeberg it down
>> again. After all, that could very well be considered "Action intended
>> to damage the [Codeberg's] reputation".
>
> Again that’s a bit of a stretch, but more importantly it’s framed as if
> (1) we were dealing with a hostile adversary, and (2) we were customers
> not owing respect to the volunteers making it work.
>
> Let’s be very clear: that’s not the spirit of this proposal. We’ll be
> using a service set up by other volunteers and we’ll be joining forces
> in some way—financially or otherwise. There’s going to be downtimes and
> problems, but we’re going to deal with them together.
I agree it might be a stretch, but at the same time I assume they had
*some* reason to put a fairly specific point like this into the ToU.
>
>> § 3 (4) is pretty WTF. They could at least send an email. I plan to
>> keep working from the Emacs, so I am pretty sure I will not check the
>> dashboard for announcement messages regarding ToU changes every three
>> months.
>
> I agree it’s not great, but it’s typically the kind of thing to discuss
> with them, once we’ve moved; perhaps sending email would be acceptable
> for them.
Let us hope.
>
> The remaining paragraphs are harsh if not hostile (please avoid that
> tone in the future) and hopefully covered by the rest of that reply.
Yes, I apologize for that. I just copy&pasted my original message
written in a bit heated state of mind. I should have adjusted the
language. Sorry.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.