marten-de-vries

I think 'rearchitect' should be interpreted as 'redesign the UI', not as 'start from scratch'. Most big changes seem limited to the UI (and done as part of a Qt -> QML migration). And it looks they'll do even those piecewise:

> In order to get the release of 4.0 out as fast as possible, we will be porting over many of our less used interface elements and dialogs directly from MuseScore 3. The plan is to gradually replace these with redesigned versions (built in QML) in subsequent releases (4.1, 4.2, etc.).

That doesn't sound unreasonable to me.

That's the case because you speak English. Think about the last time you had to navigate a website in a language you didn't speak (in my case e.g. Chinese or Russian). I remember being very happy with a few (incomplete) clues in English about were to look and what to expect.

By all means, advocate for making it easy to change the language back to the original. But this stance will decrease accessibility.

In practise, end-users will probably not setup a TOR(-style) network themselves. That means you'll need to do it for them, so they still have to trust you. At that point, just not storing their IP address is probably easier.

There are still advantages to the TOR-style solution (you wouldn't have the ability to track users without resorting to backdooring), but the slowdown and extra complexity is probably not worth it in most situations.

> However, there is an unspoken claim that the gradient update doesn't carry enough information about the user data to reconstruct any of it server-side.

This was a concern for me as well, but the 'Privacy' section of the post addresses this. In short, the algorithm is adapted such that the influence of a single user on the model is limited, and noise is added. I'm not knowledgable enough on differential privacy to know if that covers all possible privacy attacks, but it looks like a good start.

Personally, I'm now more worried about adversaries trying to mess up the model. How many clients need to submit fake updates for the training process to never converge? If it's 50% that's probably fine, but I'm afraid a much smaller amount of users could derail the process already.

From the GDPR, recital 45:

> [...] where processing is necessary for the performance of a task carried out in the public interest [...] the processing should have a basis in Union or Member State law.

I don't think that purpose of archiving has a basis in law.

That said, I do remember my law professor calling the 'right to be forgotten' one of the weaker parts of the GDPR, and I'm not an expert, so it's possible I'm missing something.

And Facebook has the right to 'inform' another company about all data it collected from its users (only in exchange for a nice sum of money!)

Except in the EU, freedom of speech and privacy are both considered human rights, which need to be weighed against each other. Freedom of speech will win when someone uses the GDPR to try to censor e.g. an online news article with some personal facts. But it won't for my Facebook tongue-in-cheek example, and I doubt it will for the redacted committer example either.

That makes sense for repository users keeping a private copy.

But, I was thinking more about companies like Github. If they can hide behind that clause for every single repo they host, the GDPR as a whole becomes useless. Pretty much everything could serve as evidence one day. As far as I know, judges don't like 'hacks' like that.

Also, additionally, code hosting platforms argue they are service providers and should not be liable for copyright infringement as long as they apply notice and takedown.

There's an exception 'for the establishment, exercise or defence of legal claims.', but there's situations where that would not apply. E.g. commits fixing a single spelling mistake are probably not copyrightable.

Also, I doubt you can just keep a copy of all data you ever process, just because it might some day be useful as legal evidence.