Conversation

Notices

1. Embed this notice
   翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Saturday, 10-Jun-2023 18:18:33 JST 翠星石
   It took me way too long to realize, but I've now realized the current aims of the proprietary 計画 (note keikaku means plan).
   
   The plan is to enforce "remote attestation" combined with "cloud computing" in the name of "security".
   
   
   The whole idea of "cloud computing" is that the suckers mind is clouded to such an extent that they don't realise that they're renting monthly someone else's computer for a huge markup: https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html
   
   That server typically happens to run mostly free software (but always some proprietary software as well), but for the sucker, such setup somehow manages to combine the security of proprietary software with the privacy of proprietary software.
   
   SaaSS provides zero privacy or security against the hosts, as the hosts can just look at what the software is doing.
   
   Sadly, the same level of security and privacy exists against sufficiently skilled internal and external attackers (theoretically the server would be well maintained and kept up to date (spoiler; this usually doesn't happen), thus keeping out attackers, but that much valuable information concentrated in one place is going to attract very skilled crackers, so, even if the server is actually very secure, those crackers are going to pull off an incredible attack to get what they want).
   
   
   As the proprietary masters have finally realized that it's futile to put a complete stop to hardware and software attacks that force computing hardware and software to partially serve the user instead of them - so they've decided to try to turn "computers" into glorified thin clients, where most of the information is stored on a remote server, with the client cryptographically authenticating with the most proprietary of "attestation" hardware before any information is sent as needed.
   
   Such functionality is extremely useful for proprietary aims, for example: video streaming, anti-cheat, lock-in word processing, restricted communication and everything else needed to give profit and prevent wrongthink.
   
   For video streaming, remote attestation will be useful to prevent unauthorized copying after the fact, by linking a specific device to a specific person and watermarking any video stream served.
   
   While some people are going to figure out how to break the digital handcuffs to get the video stream for sharing, a watermark will ideally allow for the sharer to be identified, the per-device key revoked to prevent further sharing (or access to any remote server) and the sharer to be arrested (the arrest part may not even be needed in the distant, but potential future where not being able to use specific electronic devices will be functionally worse than being imprisoned).
   
   
   Such will also stop those pesky free software programmers from reverse engineering proprietary file formats and writing a replacement free program that can view and edit such files - as the actual files will only every be sent if there's a cryptographic proof that all the software running on the computer is proprietary
   
   I could keep going, but that's enough examples - but I'm sure you can think of plenty of examples yourself.
   
   
   
   I've just realized that such functionality has already been implemented on almost all newer tracking devices and will eventually reach 100% once connecting to the mobile tower requires "remote attestation"...wait, that's all of them considering the IMEI "feature", although the restrictive features haven't yet been perfected (thankfully not having a tracking device is still possible, or at least one that's slightly less bad, but there's a cycle where the older mobile protocols are shut down (like GSM) and only being used by newer, progressively more proprietary devices is possible).
   
   
   "Apple" has managed to pull it off with all their tracking devices and their "mac" devices with the "T2" "security" chip.
   
   "Google" has done the same with their tracking devices and chromebooks.
   
   "Microsoft" have tried it early with "Palladium" and had to back off for 10-20 years, before trying again with "Pluton" and "Windows 11".
   
   The main obstacle to the proprietary implementation seems to be legacy support and the amount of hardware that lacks good enough sabotage processors, but the proprietary software developers are slowly toiling away at it.
   
   
   Eventually, all necessary hardware will make its way into the hands of 100% of normies, who will gleefully accept any "security" improvements, just as long as whatever things they want to do is convenient and you'll soon be unable to connect to the internet with an unapproved device, for "security"!
   
   
   Get ready for proprietary software tyranny to be unavoidably implemented in a way that makes the worst parts of 1984 and brave new world look pleasant.
   
   I will try to resist, but there's one of me and billions of normies that would love the tyranny.
   • Embed this notice
     Tylor :emacs: :gnu: :linux: (tylor@planet.moe)'s status on Saturday, 10-Jun-2023 22:41:15 JST Tylor :emacs: :gnu: :linux:

     in reply to

     @Suiseiseki I love your devotion to free software and I also think it's very respectable. However, I want to comment one more thing on your post. The structure of SaaSS itself is kinda bad decision, but even for free software activists (even like you) use SaaSS sometimes. For example, Mastodon web client is basically SaaSS. But we still can use Mastodon without compromising our creed, because of AGPL.

     I hope that you add paragraph about AGPL as a complement for stronger statement.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Saturday, 10-Jun-2023 22:41:15 JST 翠星石

     in reply to

     • Tylor :emacs: :gnu: :linux:
     @tylor I don't even use mastodon :3.
     
     freesoftwareextremist.com is Pleroma and I use the bloatFE frontend.
     
     Although Pleroma might technically count as SaaSS, even though it's licensed under the AGPLv3, the fediverse is designed to prevent and avoid lock-in.
     
     I'm not happy with any instance, I can just go use another instance or host my own.
     
     
     The AGPLv3 is an excellent license that does a good job at preventing the enemies of freedom turning free software into SaaSS, as any modified source code being hosted on a server to do other people's computing, needs to be provided to the users.
     
     "Google" and the like don't touch AGPLv3 licensed software, as using it would ruin their plans - as if they used AGPLv3 licensed software, although they could make whatever modification they wanted to the software and implement any kind of cryptography mechanism they want, they'd have to release the source code of their modified version.
     
     Users could then take this modified version, remove the misfeatures and host it on their own server, which "Google" does not what to happen - they want the products to use their servers only, so the product can be profited off.
     
     
     It took me until now to realise this, but rms and others had incredible foresite as to what was likely to happen and wrote the GPLv3 and AGPLv3 to prevent free software from being used in such attack against the users.
     
     They did it without restring any kind of modification to the software as well, as any kind of digital handcuffs can be implemented with the software, but the user must be provided with the key for the handcuffs, thus making the handcuffs pointless, as someone will just remove the misfeature and release a fixed version, or provide instructions on its removal.
     
     "Remote attestation" implemented with {A}GPLv3'd software is also permitted, it's just that the user must be in control of any keys stored on the device and the "security" processor software cannot stop operating merely because the user modified the software:
     "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
     
     "Microsoft" of course was quick to complain about this, but they haven't used any GPLv3'd code to implement Pluton either, although that would make things easier for them.
     
     
     I guess I'll end with the note that if you are releasing software, no matter how trivial, it is critical to license either under the GPLv3-or-later or the AGPLv3-or-later, with the latter strongly recommended if the software has a remote chance of being used to do other users computing (really, the AGPLv3 should be compatible with every license the GPLv3 is, aside from one or two that would otherwise be incompatible, but state compatibility with "the GPL" only, but even then, it shouldn't be too hard to figure out which part can be the GPLv3'd part and which part can be the AGPLv3'd part).
   • Embed this notice
     Ailes Grises (ailesgrises@fosstodon.org)'s status on Sunday, 11-Jun-2023 18:34:56 JST Ailes Grises

     in reply to

     • Tylor :emacs: :gnu: :linux:

     @tylor @Suiseiseki

     I doubt rms would describe it as foresight. Rather, he saw what was happening at the time and already recognized it as evil, and since then those same injustices have compounded to become what they are today.

     My wish is that the injustices may eventually reach a critical mass where the general public can no longer tolerate them, but we obviously can't count on that in our advocacy.

     翠星石 likes this.
   • Embed this notice
     Tylor :emacs: :gnu: :linux: (tylor@planet.moe)'s status on Sunday, 11-Jun-2023 18:34:57 JST Tylor :emacs: :gnu: :linux:

     in reply to

     @Suiseiseki
     >rms and others had incredible foresight as to what was likely to happen
     
     truly it is! and that's why rms is the greatest hero against those evil big-techs. I think GPL is the only way to use copyright morally and it's one of the greatest hacking in the whole history.

   • Embed this notice
     Ailes Grises (ailesgrises@fosstodon.org)'s status on Sunday, 11-Jun-2023 18:37:44 JST Ailes Grises

     in reply to

     • Tylor :emacs: :gnu: :linux:

     @Suiseiseki @tylor

     > it is critical to license either under the GPLv3-or-later or the AGPLv3-or-later, with the latter strongly recommended if the software has a remote chance of being used to do other users computing

     That being the case, is there any reason why a developer shouldn't just favor AGPL over the ordinary GPL in all scenarios just in case the program may get used in such a way?

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 11-Jun-2023 18:37:44 JST 翠星石

     in reply to

     • Ailes Grises
     @AilesGrises The only reasons why I can think of why not is if you intend to stay compatible with licenses that wouldn't be compatible with the GPLv3 if it wasn't for a clause that stated compatibility with any version of the GPL (but not the AGPL) and also how many people don't understand what the AGPLv3 actually requires.
   • Embed this notice
     Tylor :emacs: :gnu: :linux: (tylor@planet.moe)'s status on Sunday, 11-Jun-2023 18:53:07 JST Tylor :emacs: :gnu: :linux:

     in reply to

     • Ailes Grises

     @AilesGrises in other words, the server admin of AGPLed software should be bothered to provide their server code to his users. AGPLed software usually does sophisticated computation on the server where the users are doing more than just file transfer, so users actually need to know how their data will be processed on the server by reviewing the server source code. And AGPL helps this by obligating server admin to provide the source code to users. (2/2)

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 11-Jun-2023 18:53:07 JST 翠星石

     in reply to

     • Tylor :emacs: :gnu: :linux:
     • Ailes Grises
     @tylor @AilesGrises The thing is, the AGPLv3 only kicks in when:
     (a) *You* have modified the software.
     (b) The software is being interacted with by remote users.
     
     "13. Remote Network Interaction; Use with the GNU General Public License.
     
     Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."
     
     If you haven't modified the server software, you don't need to provide the source code, as after all, the user can just download that from the developer.
     
     
     I guess a HTTP server usually performs user interaction, as the user browses to the site and can also click links on the site to go to other pages.
     
     AGPLv3'd p2p software installed on a users computer probably isn't subject to the AGPLv3's additional terms, as long as such doesn't offer remote interaction to other users.
     
     One example would be a torrent client, in which the user merely adds a magnet link and the software uninteractively communicates with the other peers.
     
     Meanwhile, if you were to take that torrent client software and turn it into SaaSS, as offer the users a remote interface to interactively upload a magnet link and download completed files, the AGPLv3's terms will kick in.
   • Embed this notice
     Tylor :emacs: :gnu: :linux: (tylor@planet.moe)'s status on Sunday, 11-Jun-2023 18:53:08 JST Tylor :emacs: :gnu: :linux:

     in reply to

     • Ailes Grises

     @AilesGrises @Suiseiseki

     It's probably because AGPL is a bit too restrictive for traditional server software. even if you don't provide your HTTP server(e.g. Lighttpd) code to users who visit your static HTML website, it doesn't harm user's freedom. But if the code of your HTTP server is AGPLed, you have to provide the code of your server to users who use it even when it doesn't help improve user's freedom fundamentally. (1/2)