@vanl, one of the issues you brought up to me separately had to do with whether the “data portability” rules of CAL were permissible under the rubric of “software freedom”. A few thoughts there:
“Are data portability rules allowed under software freedom?” has next to no meaning whatsoever.
If “software freedom” can’t grok data portability, software freedom is seriously blinkered, has a serious relevance problem coming, and should be made to admit as much.
Von Neumann. Not all data about people is collected, stored, and processed by them first. Providing copies of programs run for people is already providing data.
We have some idea what “data portability” means. If that’s a more broadly accepted description for the service-operator rules you tried to write in CAL, CAL should say “data portability” to better explain itself. But “software freedom” is the sound the spoon makes when you get past the fact that OSD says nothing particularly helpful or unhelpful, and scrape the bottom of the OSI policy barrel. You might as well ask, “Will OSI approve data portability rules in a software license?”. More a question of process, prerogative, and discretion than anything else.
I don’t think you’ll have to spend much time finding a statement on FSF.org that is pro data portability, or even criticizes GDPR’s implementation as too narrow. I can’t recite it by heart, but some of the Service as a Software Substitute rhetoric is likely on point. Not that it matters so much.
I’ve blogged recently on the fact that if you define “open” or “free” too narrowly, you merely reinforce the kinds of leverage your definition misses, by denying everyone else the leverage it does. Permitting access to source code without access to data just privileges those with data. CAL starts to address that. If you have a choice between solving the data abuse problem or solving the OSI approval problem, solve the data abuse problem. The former reflects the sate of the industry. The latter reflects the state of a couple nonprofits.