Re: [libreplanet-discuss] RollApp: proof that we need to deprecate GPL for AGPL for everything

[Aaron Wolf]

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