On 09/12/2015 10:06 PM, Mike Gerwitz wrote: > On Sat, Sep 12, 2015 at 09:38:17 -0700, Aaron Wolf wrote: >> https://www.rollapp.com/ — complete SaaSS to the extreme (see >> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html ). >> >> They aren't illegal, and they do mention "Open Source" at least (which >> isn't absolutely legally required), but they avoid even linking to the >> websites of the software they host. > > Keep in mind that the AGPL's extra requirement only applies if the > software is _modified_.[0] But this is still an important > discussion. Perhaps it even highlights an issue with the "modified" > condition.
Indeed, and very good point. That is disappointing to realize. Although in principle, unmodified software is available regardless, the fact that one *could* run a server using unmodified AGPL software and refuse to mention to visitors that the software is AGPL, that's a serious flaw. I'd really love to see copyleft-next succeed eventually. AGPL obviously isn't quite perfect. > > From glancing briefly at this site, it seems that it allows remotely > executing and rendering software for display on the client (within a web > browser). So this would be a similar concept to SSH'ing into a server > and running software either on the command line or via X11 forwarding: > no software has been distributed to the user that is interacting with > it. > > So while the concept in itself isn't anything new---it's just rendered > in a web browser rather than, say, by an X11 client---I still agree with > you on the more general issue. We can expect this type of trend to > continue, but not only because of the SaaSS push and "thin"/"dumb" > clients: it's also an easy way to circumvent the most important > provisions of the GPL. > > The user still wouldn't be able to run their changes to the software on > the original service, but that's a property of SaaSS; she could still > run it on her own hardware. (I know you know all of this; I'm just > trying to avoid unnecessary replies from others on these points.) So > just saying "SaaSS is bad, don't use it" isn't the solution: many users > will choose to use it, just as many users choose to use proprietary > operating systems; we don't forsake those users and tell them "you've > already scarified your freedom; there is nothing we can do for you". On > the contrary, we support those platforms if at all possible so that > those users can enjoy those fundamental freedoms in whatever environment > they decide is acceptable to them. All-or-nothing is not realistic and > works against our cause. I happen to agree completely on accepting the reality that we can't go for all-or-nothing. > > I'm not saying that is being done here. But to further Aaron's point, > we're at risk of moving in that direction. > >> The only legitimate reason for GPL (without the A) today is to preserve >> compatibility with existing GPL projects. All new projects, and all >> projects that can feasibly switch without forking problems need to move >> to AGPL. It has *nothing* to do with whether or not the software is >> *designed* to be run on a server, *all* software should be AGPL. > > I do see a couple issues that immediately stand out that would need to > be heavily considered: The first is license compatibility with _other_ > free software licenses, such as the Apache License v2. I think compatibility problems is the one strongest argument for permissive licensing. The downside of copyleft causing incompatibilities is a real and serious issue. I respect the argument that permissive licensing is better just for the value of compatibility. That said, Apache v2 is fully compatible one-way with AGPLv3+. All GPLv3-compatible licenses are AGPLv3 compatible as well. > The second is > how adopting the AGPL too aggressively too soon might work against our > goals by having more people avoid the software more aggressively than > they avoid the GPL today. With that said, for the latter case, we have > two major categories to consider: > > 1. Standalone software; and > 2. Share libraries. > > For standalone software, as a _user_, it would seem that the only way > you'd have reason to avoid AGPL'd software is to exploit precisely this > situation. So that works toward our goals, not against them. > > But we have license compatibility issues for AGPL'd libraries and for > standalones using other libraries with which the AGPL may not be > compatible. We have a similar issue today with GPLv2-only and GPLv3 > software, and often times over another strong philosophical reason: > Tivoization. And just as the GPLv3 adapted to a new reality, so too > should it to the issue of SaaSS. Does a step to encourage AGPL > provisions present a similar philosophical challenge to Tivoization, or > is it greater? > In the long run, this situation is probably far greater concern than the Tivoization issue. > That's not to say that the AGPL's provisions will always be appropriate, > just as the GPL's are sometimes not: the LGPL is used in certain cases > for legitimate reasons (such as glibc), and linking exceptions are used > with the GPL (such as for the GCC Runtime Library Exception). > > [0]: https://www.gnu.org/licenses/why-affero-gpl.html > -- Aaron Wolf co-founder, Snowdrift.coop music teacher, wolftune.com
signature.asc
Description: OpenPGP digital signature