5 ms·

Please stop with this FUD. AGPL is written by lawyers and well understood by other lawyers. I worked with IP/software license lawyers and AGPL works just fine.

marcan_42 6y ago
The AGPL is written by basically ~one lawyer as far as I know, has never been properly tested, has absolutely not been evaluated by people who should care (like the Gentoo team; as a metadistribution they are in a unique position regarding licensing different from other distros). Almost everything I read about it falls into two camps: * Most people in free software: The FSF wrote it, therefore it's fine, because the FSF are trustworthy when it comes to freedom%. All server open source projects should use it, it'll magically protect us from the SaaS loophole, and there is nothing to worry about if you're not an evil corporation. * Most every big corp: the AGPL is a ginormous can of worms and we aren't touching it with a 1 mile pole. Nope. Stay away. Guess what? Reality is in between those two extremes. The problems with the AGPL are widely underreported in the free software world, and almost nobody has taken a close look at its wording and what it really means. "Leave it to the lawyers" but then nobody ever actually goes and asks a lawyer for a clean take on it. We should do better. The FSF has done a terrible job of educating people on exactly what the AGPL requires and how it interacts with typical free software project development and deployment workflows. If you haven't asked a lawyer about this then maybe you should think twice before slapping it on your project. Relicensing after the fact is a very costly ordeal. % The FSF, through their "Respects your Freedom" hardware rubber-stamping program and its absolutely broken requirements, which actively encourages reduction in user freedom, makes it much harder to detect hidden proprietary backdoors, and hurts projects that are actually aiming for maximum openness, have amply proved that they are not infallible and are not to be trusted without careful review of their policies and projects. I can go into a whole different tangent about this, but my point is, don't treat the FSF as the good guys by default. Look at what it is they're doing exactly and all of its consequences.
- wegs 6y ago
  Harvard did due diligence before agreeing to release Open edX under the AGPL. That was a $30 million investment on their part. I guess when you say "has absolutely not been evaluated by people who should care," it's because you think anyone short of Yale isn't a real lawyer. Those jokers and clowns from Harvard....
- cure 6y ago
  > % The FSF, through their "Respects your Freedom" hardware rubber-stamping program and its absolutely broken requirements, which actively encourages reduction in user freedom, makes it much harder to detect hidden proprietary backdoors, and hurts projects that are actually aiming for maximum openness, have amply proved that they are not infallible and are not to be trusted without careful review of their policies and projects. I can go into a whole different tangent about this, but my point is, don't treat the FSF as the good guys by default. Look at what it is they're doing exactly and all of its consequences. It sounds like you are angry with the FSF, not sure why. As for your claims: RYF rubber stamping? RYF reduces user freedom? RYF makes it harder to detect hidden proprietary backdoors? None of these statements make a lot of sense. You're going to need to provide a whole lot more information to back them up.
  - marcan_42 6y ago
    Here is a Twitter thread I wrote on the subject: https://twitter.com/marcan42/status/1040626210999431168?s=19 https://twitter.com/marcan42/status/1040626210999431168?s=19 TL;DR the FSF's RYF program is designed to allow inaccessible, un-auditable, immutable blobs - because they know that if they didn't, nothing would ever get certified (everything has at least some microcode or ROM of some sort, e.g. the USB sound cards they've meaninglessly certified as RYF). By doing this, they encourage companies to make their blobs inaccessible, immutable, and un-auditable in order to get that rubber stamp. And so, we go from having firmware in /lib/firmware or something where it makes engineering sense, to dumping it in some write-protected flash read by a controverted set-up with a side CPU, where the user will never be able to audit or replace it, because that is what they will certify. In their view, proprietary blobs are OK as long as the user can't see them or touch them - but if they can, that's a big no-no. This isn't a hypothetical scenario, as Purism has already gone down this road for the Librem 5, to the detriment of their users' freedom, as well as wasted engineering time and final device cost (that extra flash chip). Put this way: a device that requires proprietary firmware loaded by an open driver from /lib/firmware is, by any reasonable metric, strictly more free than a device with the same firmware burned into ROM, but the FSF will only certify the latter. Even though you could audit the firmware, guarantee firmware authenticity, or even replace it with a free replacement when it becomes available (or reverse engineer it yourself) in the former case, but not at all the latter. Meanwhile I have a friend who designed a completely open hardware laptop (think about the significance of that) and the FSF refused to certify it because the main CPU (one of the few with open documentation at all at the time) happened to have a GPU accelerator in it (even though it was not required, you can use it just fine with only framebuffer output) and at the time there were no free drivers, so even if the thing shipped with all open code, they thought users might be "tempted" to install the blob drivers. There was some talk then of getting the manufacturer to permanently disable the GPU in those chips to get certified. So the FSF will certify hardware as long as you remove any features which might be usable with proprietary software. How does this increase user freedom again? It's all completely bonkers. I'm somewhat frustrated at the FSF, because it seems that so much of what they do these days is extremist to the point of hurting the free software cause (e.g. some of their campaigns are just embarrassing in how childish they sound). I understand that they don't like proprietary software, but treating it like it's a massive evil upon the world is now way past its expiry date as an advocacy approach; this just makes the whole community look bad. Look at the FSFe if you want a more moderate organization which advocates for these causes without falling into sily behavior like that.

marcan_42 6y ago

The AGPL is written by basically ~one lawyer as far as I know, has never been properly tested, has absolutely not been evaluated by people who should care (like the Gentoo team; as a metadistribution they are in a unique position regarding licensing different from other distros). Almost everything I read about it falls into two camps: * Most people in free software: The FSF wrote it, therefore it's fine, because the FSF are trustworthy when it comes to freedom%. All server open source projects should use it, it'll magically protect us from the SaaS loophole, and there is nothing to worry about if you're not an evil corporation. * Most every big corp: the AGPL is a ginormous can of worms and we aren't touching it with a 1 mile pole. Nope. Stay away. Guess what? Reality is in between those two extremes. The problems with the AGPL are widely underreported in the free software world, and almost nobody has taken a close look at its wording and what it really means. "Leave it to the lawyers" but then nobody ever actually goes and asks a lawyer for a clean take on it. We should do better. The FSF has done a terrible job of educating people on exactly what the AGPL requires and how it interacts with typical free software project development and deployment workflows. If you haven't asked a lawyer about this then maybe you should think twice before slapping it on your project. Relicensing after the fact is a very costly ordeal. % The FSF, through their "Respects your Freedom" hardware rubber-stamping program and its absolutely broken requirements, which actively encourages reduction in user freedom, makes it much harder to detect hidden proprietary backdoors, and hurts projects that are actually aiming for maximum openness, have amply proved that they are not infallible and are not to be trusted without careful review of their policies and projects. I can go into a whole different tangent about this, but my point is, don't treat the FSF as the good guys by default. Look at what it is they're doing exactly and all of its consequences.

wegs 6y ago
Harvard did due diligence before agreeing to release Open edX under the AGPL. That was a $30 million investment on their part. I guess when you say "has absolutely not been evaluated by people who should care," it's because you think anyone short of Yale isn't a real lawyer. Those jokers and clowns from Harvard....
cure 6y ago
> % The FSF, through their "Respects your Freedom" hardware rubber-stamping program and its absolutely broken requirements, which actively encourages reduction in user freedom, makes it much harder to detect hidden proprietary backdoors, and hurts projects that are actually aiming for maximum openness, have amply proved that they are not infallible and are not to be trusted without careful review of their policies and projects. I can go into a whole different tangent about this, but my point is, don't treat the FSF as the good guys by default. Look at what it is they're doing exactly and all of its consequences. It sounds like you are angry with the FSF, not sure why. As for your claims: RYF rubber stamping? RYF reduces user freedom? RYF makes it harder to detect hidden proprietary backdoors? None of these statements make a lot of sense. You're going to need to provide a whole lot more information to back them up.
- marcan_42 6y ago
  Here is a Twitter thread I wrote on the subject: https://twitter.com/marcan42/status/1040626210999431168?s=19 https://twitter.com/marcan42/status/1040626210999431168?s=19 TL;DR the FSF's RYF program is designed to allow inaccessible, un-auditable, immutable blobs - because they know that if they didn't, nothing would ever get certified (everything has at least some microcode or ROM of some sort, e.g. the USB sound cards they've meaninglessly certified as RYF). By doing this, they encourage companies to make their blobs inaccessible, immutable, and un-auditable in order to get that rubber stamp. And so, we go from having firmware in /lib/firmware or something where it makes engineering sense, to dumping it in some write-protected flash read by a controverted set-up with a side CPU, where the user will never be able to audit or replace it, because that is what they will certify. In their view, proprietary blobs are OK as long as the user can't see them or touch them - but if they can, that's a big no-no. This isn't a hypothetical scenario, as Purism has already gone down this road for the Librem 5, to the detriment of their users' freedom, as well as wasted engineering time and final device cost (that extra flash chip). Put this way: a device that requires proprietary firmware loaded by an open driver from /lib/firmware is, by any reasonable metric, strictly more free than a device with the same firmware burned into ROM, but the FSF will only certify the latter. Even though you could audit the firmware, guarantee firmware authenticity, or even replace it with a free replacement when it becomes available (or reverse engineer it yourself) in the former case, but not at all the latter. Meanwhile I have a friend who designed a completely open hardware laptop (think about the significance of that) and the FSF refused to certify it because the main CPU (one of the few with open documentation at all at the time) happened to have a GPU accelerator in it (even though it was not required, you can use it just fine with only framebuffer output) and at the time there were no free drivers, so even if the thing shipped with all open code, they thought users might be "tempted" to install the blob drivers. There was some talk then of getting the manufacturer to permanently disable the GPU in those chips to get certified. So the FSF will certify hardware as long as you remove any features which might be usable with proprietary software. How does this increase user freedom again? It's all completely bonkers. I'm somewhat frustrated at the FSF, because it seems that so much of what they do these days is extremist to the point of hurting the free software cause (e.g. some of their campaigns are just embarrassing in how childish they sound). I understand that they don't like proprietary software, but treating it like it's a massive evil upon the world is now way past its expiry date as an advocacy approach; this just makes the whole community look bad. Look at the FSFe if you want a more moderate organization which advocates for these causes without falling into sily behavior like that.