[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreplanet-discuss] RollApp: proof that we need to deprecate GPL f
Re: [libreplanet-discuss] RollApp: proof that we need to deprecate GPL for AGPL for everything
Sat, 12 Sep 2015 23:09:43 -0700
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
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_. But this is still an important
> discussion. Perhaps it even highlights an issue with the "modified"
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
> 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
> 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
> 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).
> : https://www.gnu.org/licenses/why-affero-gpl.html
music teacher, wolftune.com
Description: OpenPGP digital signature
Re: [libreplanet-discuss] RollApp: proof that we need to deprecate GPL for AGPL for everything, Mike Gerwitz, 2015/09/13
Re: [libreplanet-discuss] RollApp: proof that we need to deprecate GPL for AGPL for everything, John Sullivan, 2015/09/14
- Re: [libreplanet-discuss] RollApp: proof that we need to deprecate GPL for AGPL for everything,
Aaron Wolf <=