GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE
  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Conversation

Notices

  1. Embed this notice
    Berkubernetus (fuzzychef@m6n.io)'s status on Sunday, 29-Dec-2024 07:55:06 JST Berkubernetus 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.

    In conversation about 8 months ago from m6n.io permalink
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Dec-2024 07:55:01 JST Strypey 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

      In conversation about 8 months ago permalink
    • Embed this notice
      Christopher Neugebauer (chrisjrn@social.coop)'s status on Sunday, 29-Dec-2024 07:55:02 JST Christopher Neugebauer 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

      In conversation about 8 months ago permalink
    • Embed this notice
      mcc (mcc@mastodon.social)'s status on Sunday, 29-Dec-2024 07:55:03 JST mcc 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

      In conversation about 8 months ago permalink
    • Embed this notice
      Christopher Neugebauer (chrisjrn@social.coop)'s status on Sunday, 29-Dec-2024 07:55:04 JST Christopher Neugebauer 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

      In conversation about 8 months ago permalink
    • Embed this notice
      Joe Brockmeier (@jzb) (jzb@mastodon.social)'s status on Sunday, 29-Dec-2024 07:55:05 JST Joe Brockmeier (@jzb) 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.

      In conversation about 8 months ago permalink
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Dec-2024 09:01:13 JST Strypey Strypey
      • 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.

      In conversation about 8 months ago permalink
    • 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) 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
      In conversation about 8 months ago permalink
      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 Yuchen Pei
      in reply to
      • Alexandre Oliva (moving to @lxo@snac.lx.oliva.nom.br)
      • Strypey
      @lxo
      Can you give an example?
      @strypey
      In conversation about 8 months ago permalink
    • 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) 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
      In conversation about 8 months ago permalink
      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.
      In conversation about 8 months ago permalink
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Sunday, 29-Dec-2024 17:50:47 JST Strypey 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?

      In conversation about 8 months ago permalink
      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) 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
      In conversation about 8 months ago permalink
    • 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) 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.
      In conversation about 8 months ago permalink
    • 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) 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
      In conversation about 8 months ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        ::[FSFLA]:: 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 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).

      In conversation about 8 months ago permalink

      Attachments

      1. Domain not in remote thumbnail source whitelist: identi.ca
        Welcome - Identi.ca
      2. No result found on File_thumbnail lookup.
        pump.io
      3. No result found on File_thumbnail lookup.
        Varför kampen mot öppnare och mer transparenta sociala medier är viktigt - Quitter
        from Qvitter
        Det har säkerligen inte undgått någon att alla dessa sociala medier som finns ute i samhället bara blir fler och fler. Twitter, Facebook och Instagram är bara några av alla de alternativ som finns...
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 10:00:08 JST Strypey 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.

      In conversation about 8 months ago permalink
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 10:03:56 JST Strypey 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.

      In conversation about 8 months ago permalink
    • 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) 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 :-)
      In conversation about 8 months ago permalink
      MortSinyx likes this.
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 13:05:01 JST Strypey 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.

      In conversation about 8 months ago permalink
    • Embed this notice
      Strypey (strypey@mastodon.nzoss.nz)'s status on Monday, 30-Dec-2024 13:09:55 JST Strypey 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.

      In conversation about 8 months ago permalink
    • 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.
      In conversation about 8 months ago permalink
    • 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) 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.
      In conversation about 8 months ago permalink
    • Embed this notice
      Yuchen Pei (quasi@peister.org)'s status on Monday, 30-Dec-2024 15:30:43 JST Yuchen Pei 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
      In conversation about 8 months ago permalink

      Attachments


    • 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) 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
      In conversation about 8 months ago permalink

      Attachments

      1. No result found on File_thumbnail lookup.
        ::[FSFLA]:: Blonging for Freedom
      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 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.
      In conversation about 8 months ago permalink

      Attachments


Feeds

  • Activity Streams
  • RSS 2.0
  • Atom
  • Help
  • About
  • FAQ
  • TOS
  • Privacy
  • Source
  • Version
  • Contact

GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.