Conversation

Notices

1. Embed this notice
   Berkubernetus (fuzzychef@m6n.io)'s status on Sunday, 29-Dec-2024 07:55:06 JST Berkubernetus

   • mcc
   • Christopher Neugebauer

   @chrisjrn @mcc Eben Moglin's views, mostly (not that that makes things better).

   It would be fascinating for someone to do an analysis of GPLv3 today and whether Moglin successfully future-proofed it.

   • Embed this notice
     Jason Self (jxself@mastodon.social)'s status on Sunday, 29-Dec-2024 07:54:58 JST Jason Self

     in reply to

     • Strypey
     • mcc
     • Christopher Neugebauer
     • Joe Brockmeier (@jzb)
     • Richard Fontana

     @strypey @chrisjrn @mcc @jzb @fuzzychef @richardfontana Yes, the earlier drafts of GPLv3 were intended to have the Affero clause. In GPLv3 Discussion Draft #3 it was pulled out into a separate license. The FSF has their rationale in https://gplv3.fsf.org/gpl3-dd3-rationale.pdf/

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Dec-2024 07:55:01 JST Strypey

     in reply to

     • mcc
     • Christopher Neugebauer
     • Jason Self
     • Joe Brockmeier (@jzb)
     • Richard Fontana

     @chrisjrn
     > AGPL ... arguably remained a fork because RMS didn't think SaaSes were important

     I think it was @jxself I saw saying that a lot of FSF partisans thought the Affero clause ought to be folded into GPL itself. Can't remember what he said the reasoning was for not doing that, but the separate GNU Affero license was a compromise.

     @mcc @jzb @fuzzychef @richardfontana

   • Embed this notice
     Christopher Neugebauer (chrisjrn@social.coop)'s status on Sunday, 29-Dec-2024 07:55:02 JST Christopher Neugebauer

     in reply to

     • mcc
     • Joe Brockmeier (@jzb)
     • Richard Fontana

     @mcc
     The AGPL wasn't RMS's work, that was primarily down to Bradley Kuhn; and it arguably remained a fork because RMS didn't think SaaSes were important

     @jzb @fuzzychef @richardfontana

   • Embed this notice
     mcc (mcc@mastodon.social)'s status on Sunday, 29-Dec-2024 07:55:03 JST mcc

     in reply to

     • Christopher Neugebauer
     • Joe Brockmeier (@jzb)
     • Richard Fontana

     @chrisjrn @jzb @fuzzychef @richardfontana Wait isn't agpl all about saas. Or does AGPL fail because it only works if the code is on the service side

   • Embed this notice
     Christopher Neugebauer (chrisjrn@social.coop)'s status on Sunday, 29-Dec-2024 07:55:04 JST Christopher Neugebauer

     in reply to

     • mcc
     • Joe Brockmeier (@jzb)
     • Richard Fontana

     @jzb
     It completely missed the rise of SaaS, and spent too long focusing on the scourge of appliances (which, as it turns out are irrelevant if they're connecting to SaaSes)

     @fuzzychef @mcc @richardfontana

   • Embed this notice
     Joe Brockmeier (@jzb) (jzb@mastodon.social)'s status on Sunday, 29-Dec-2024 07:55:05 JST Joe Brockmeier (@jzb)

     in reply to

     • mcc
     • Christopher Neugebauer
     • Richard Fontana

     @fuzzychef @chrisjrn @mcc Narrator: He did not.

     I guess the question is "against what?" but in my not-lawyerly opinion, no. The "2001-2006 views" is a good summary, I think. I'd be curious what @richardfontana would say, though.

   • Embed this notice
     Jason Self (jxself@mastodon.social)'s status on Sunday, 29-Dec-2024 09:01:11 JST Jason Self

     in reply to

     • Strypey

     @strypey The only other versions I know of are available in PostScript and LaTeX: https://gplv3.fsf.org/gpl3-dd3-guide/
     Go to section 4.2 starting on page 29 of the PDF.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Dec-2024 09:01:13 JST Strypey

     in reply to

     • Jason Self

     @jxself is there an HTML version of that PDF? Ideally with anchor links for each section. The PDF is really hard to navigate on a mobile.

   • Embed this notice
     Jason Self (jxself@mastodon.social)'s status on Sunday, 29-Dec-2024 09:06:42 JST Jason Self

     in reply to

     • Strypey
     • mcc
     • Christopher Neugebauer
     • Joe Brockmeier (@jzb)

     @strypey @chrisjrn @mcc @jzb @fuzzychef And, in terms of an importance, regarding the even earlier GPLv3 Discussion Draft #2:

     "We have also rejected suggestions, made by some discussion committee members, that the Affero clause requirement be removed, though we have revised it in response to certain comments. We are unwavering in our view that the Affero requirement is a legitimate one..."

     Source: https://gplv3.fsf.org/additional-terms-dd2.pdf/

   • Embed this notice
     Jason Self (jxself@mastodon.social)'s status on Sunday, 29-Dec-2024 09:09:14 JST Jason Self

     in reply to

     • Strypey
     • mcc
     • Christopher Neugebauer
     • Joe Brockmeier (@jzb)

     @strypey @chrisjrn @mcc @jzb @fuzzychef For context while reading the rationale from Discussion Draft #3: If you check out Discussion Draft #2 the Affero clause would have been done as an optional "switch" for someone to enable via Section 7, and the could have opened up the possibility to do a lot more than what the original Affero clause did.

   • Embed this notice
     Jason Self (jxself@mastodon.social)'s status on Sunday, 29-Dec-2024 09:13:08 JST Jason Self

     in reply to

     • Strypey
     • mcc
     • Christopher Neugebauer
     • Joe Brockmeier (@jzb)

     @strypey @chrisjrn @mcc @jzb @fuzzychef The compromise still achieves the goal, if you think of a separate AGPL being like the optional "switch" in GPLv3, that someone can "activate"/"apply" on their code while still being compatible with GPLv3 and pulling in the GPL code to also be subject to the Affero clause as part of the finalized text of Section 13 of both licenses.

   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Sunday, 29-Dec-2024 10:21:19 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • Strypey
     I, for one, don't think AGPL should be folded into the GPL. when the job the program does is the operator's computing, rather than a remote client's computing, the user is the operator, and the AGPL would fail to respect the user's freedom
     Eric Ireland likes this.
   • Embed this notice
     Yuchen Pei (quasi@peister.org)'s status on Sunday, 29-Dec-2024 12:11:39 JST Yuchen Pei

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
     • Strypey
     @lxo
     Can you give an example?
     @strypey
   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Sunday, 29-Dec-2024 14:53:30 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • Yuchen Pei
     sure. consider code in a web shop that does the shop's own finances. there's no freedom reason for customers to be entitled to get a copy of that code, but if there's AGPL code in there, the user (the web shop) loses its freedom to distribute (or not) that code. same goes for, say, a PDF generator that the shop uses to format documents it must provide to customers. if that's AGPL, the web shop's freedom is again violated.
     
     contrast with the web shop's server doing customer's own computing, say managing shopping lists. the user that the computing pertains to is the customer, and so the imperative is for the customer to have the four freedoms, and this web service should thus be provided in a way that respects the customer's freedom. for the web shop, not being the user of that service, the freedoms are not an imperative: it's not entitled to control someone else's computing, even if it performs it itself
     Yuchen Pei likes this.
   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Sunday, 29-Dec-2024 15:03:32 JST 翠星石

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
     • Strypey
     @lxo @strypey >when the job the program does is the operator's computing, rather than a remote client's computing, the user is the operator, and the AGPL would fail to respect the user's freedom
     The AGPLv3 is written not to have that flaw - when the user is the operator, no source code has to be provided to anyone, as the only user already has it after all;
     >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.
     
     SaaSS hosts are not even required to supply any source code to the users provided they don't modify the software (even then, the user should be able to find it just fine via the software name inserted into the footer etc).
     
     The AGPLv3 is specifically designed to apply to the case where a SaaSS host takes the software and adds malware and spyware to it, as then that SaaSS host is then legally required to provide evidence of their criminal activities to the users and also allow them to remove it and release a fixed version.
     
     google and other malicious parties hate the AGPLv3 for that reason alone - but doesn't that just make you want to license under AGPLv3-or-later harder?
     
     
     If the GPLv4 ever needs to be written, the remote network interaction requirement should be included, although it should also be more explicitly stated that it does not apply to purely personal usage of the software.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Dec-2024 17:50:47 JST Strypey

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     @lxo
     > the user is the operator, and the AGPL would fail to respect the user's freedom

     This is a great summary of an argument that needs a blog length explanation to make sense to me. Know of any you could link to?

     Eric Ireland repeated this.
   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Monday, 30-Dec-2024 02:11:57 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • Strypey
     'fraid I don't know of any, and I haven't yet written the one I plan to
   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Monday, 30-Dec-2024 02:19:32 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • 翠星石
     unfortunately, no, the AGPL does not avoid the problem I meant. it looks like I was unclear in my depiction: the local operator is the user, but that wasn't supposed to mean that there wouldn't be remote customers interacting with it. the AGPL doesn't distinguish whose computing the program does and, as such, it can be (and is) misused to impose unjust subjugation on operators, when the computing the component does is the operators'. it also forces inefficient integrations to keep components in separate programs.
     
     but that doesn't mean AGPL is bad. it's a great tool to defend remote users' freedoms, but like most tools, it can be put to harmful uses.
   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Monday, 30-Dec-2024 08:59:34 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • Strypey
     here's a first rough cut. feedback is welcome https://www.fsfla.org/blogs/lxo/draft/avoiding-agpl-abuse
     Eric Ireland and Luciano Silva like this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 09:34:23 JST Strypey

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     @lxo
     Thanks, I'll have a read.

     BTW it's great to see there's still GNU social servers active in the fediverse.
     After identi.ca moved to pump.io, cutting off the rest of the network,
     my second home in the verse was a Gs servers (Quitter.se).

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 10:00:08 JST Strypey

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     (1/2)

     @lxo
     > here's a first rough cut. feedback is welcome

     Your fundamental claim seems to be that for software I only use for my own computing, an obligation to provide source code to others is unreasonable. I have two thoughts on this.

     One is that providing a link to public-facing source code is not onerous in in 2024. But the second, more important point is that if it's truly your own computing, no one else will know about it. So they would have no reason to seek source code.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 10:03:56 JST Strypey

     in reply to

     (2/2)

     In your example of the web shop, the customer making a purchase is doing their own computing. Since all web shops require JS, they're even doing some of it on their own computer. So they are definitely entitled to source code and an Affero clause in a GPL applied to the web shop software would be totally appropriate.

     I think you need a better example to make your case.

   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Monday, 30-Dec-2024 10:53:29 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • Strypey
     thanks for the feedback
     
     unfortunately, the "no one else will know about it" is not true in cases I'm familiar with. consider a component that leaves an identifying mark in documents it generates, and the document ends up provided to remote users, say a proof of purchase, a statement of warranty... it's the shop's computing to generate them, even if they're meant to be delivered to users
     
     I should have mentioned the "no JS" assumption. web shops have indeed become toxic, and may lead to misunderstandings about the scenario I meant to describe. it's unfortunate because it covers so many of the incidental circumstances, but that may be hard for even present readers to grasp because most web experiences are awfully invasive, and those are way outside my own personal experience. I still remember and long for buying books online on a shop that existed before JavaScript came to exist, and sending them payment information by GPG-encrypted email :-)
     MortSinyx likes this.
   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 13:05:01 JST Strypey

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     @lxo
     > it's the shop's computing to generate them, even if they're meant to be delivered to users

     This is also a weak example for the point you want to make. In this case - as in the case of a web shop with no remote scripts - you're not delivering any computing via SaaSS. You're delivering a *document* generated by the software to the remote user.

     IANAL but I don't think Affero copyleft would be triggered by sending such outputs, even if the document-generating software was under AGPL.

   • Embed this notice
     Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 13:09:55 JST Strypey

     in reply to

     (2/2)

     IANAL but I don't think Affero copyleft would be triggered by sending such outputs, even if the document-generating software was under AGPL.

     Say LibreOffice was licensed AGPL, which ideally it would be, as its components are often used with web services now, like NextCloud servers. Say I saved an .ODF text document in LibreOffice and emailed you a copy. AFAIK that wouldn't oblige me to supply you with source code for LibreOffice.

   • Embed this notice
     翠星石 (suiseiseki@freesoftwareextremist.com)'s status on Monday, 30-Dec-2024 14:21:50 JST 翠星石

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
     • Strypey
     @lxo @strypey >Consider, for example, a web shop server program: it controls a web site that shows products and prices for customers to select and add to shopping carts, and it manages information about payments, shipping, returns and refunds. All of this can be reasonably considered the shop's own computing, not that of its remote customers
     Such web shop is not only the shop's own computing, it is also the users computing, since they carry out the computation of ordering.
     
     If the web shop doesn't modify the store (like almost all of them), the customers don't need to be provided anything.
     
     If the web shop adds malware and spyware, then they need to provide the modified source.
     
     If the web shop doesn't like the deal that modified versions are to be shared with the customers, they're free to use other web shop software.
     
     
     That is the AGPLv3 working as intended, rather than a flaw.
   • Embed this notice
     Taylan (Now 18% More Deranged) (taylan@fedi.feministwiki.org)'s status on Monday, 30-Dec-2024 15:17:39 JST Taylan (Now 18% More Deranged)

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
     • 翠星石
     • Strypey
     @Suiseiseki @lxo @strypey
     
     Well, the computation of ordering (creating and transmitting orders) would just be front-end aka client-side code, wouldn't it? Typically HTML, CSS, and JS sent to the customer's browser.
     
     This code that runs in the customer's browser will then send data to the server, and the server will do some computation that doesn't concern the customer (receiving and processing orders).
     
     Let's assume the same server application both contains the front-end code that will be sent to the customer's browser, and the back-end code that will process the orders received from the front-end code. I don't think this entire application needs to be AGPL. The only important thing is that the front-end code sent to the customer's browser is under a free license. The customer would then be free to reverse-engineer the ordering protocol (by reading the front-end source code) and build their own client application, if they wish to do so.
     
     I think the only reason to release such an application under the AGPL would be to prevent corporations from exploiting the work of free software developers by massively profiting from a privately improved version of the application without giving anything at all back to the community that created the original version. Indeed, I think that's the main reason the AGPL exists. It's not about preventing companies from running their proprietary code on devices you own, because the plain GPL already does that.
   • Embed this notice
     Yuchen Pei (quasi@peister.org)'s status on Monday, 30-Dec-2024 15:30:43 JST Yuchen Pei

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
     • Strypey
     @lxo
     Does your blog have an RSS feed? I could only find https://www.fsfla.org/ikiwiki/recentchanges.rss which contains more than blogpost publication
     @strypey
   • Embed this notice
     Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br) (lxo@gnusocial.jp)'s status on Monday, 30-Dec-2024 16:57:07 JST Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)

     in reply to

     • Yuchen Pei
     https://www.fsfla.org/blogs/lxo/ has RSS and Atom feeds. IIRC there are different feeds for different languages. drafts like this aren't expected to appear in feeds.
     
     I'm going to move my personal blog to a personal web site one of these days, after I pick up a domain name I like ;-) but I've been stuck at this for over half a year, so... who knows when that's going to be... I also plan to run my own Fediverse instance on it, but I'll leave forwarding directions in place
     Yuchen Pei and Luciano Silva like this.
   • Embed this notice
     Yuchen Pei (quasi@peister.org)'s status on Wednesday, 01-Jan-2025 07:12:39 JST Yuchen Pei

     in reply to

     • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
     @lxo
     Thanks. For some reason my tt-rss server cannot handle the feed xml at https://www.fsfla.org/ikiwiki/blogs/lxo/index.en.rss. There was no error and the list of articles is empty.