15 votes

Copyleft software license is broken when it comes to web apps

Posted by pyeri
Tags: web, open source, copyleft, apps

Now, we all much admire the Richard Stallman mindset and the libre/commons ideals of GNU GPL folks, they are the ones who pioneered the open source foundations by giving us things like core utils, emacs, gcc, etc. at a time when proprietary solutions were having a field day with absolutely zero competition.

However, the GNU GPL software license has a few practical problems when it comes to development of web apps. I came across these while developing a PHP web framework recently. I had initially considered GPL v3 but I will have to go with a permissive license like MIT or Apache due to these issues:

  1. The GPL applies to your entire software as a whole including derivative works. Now what constitutes a derivative work is often highly technical but not even an attempt has been made in GPL to clarify that. That question has been left vague for some reason which is never good from a legal perspective.
  2. In my case, the two require files are in the core directory while a plain index.php lives in the root for the user to override. This index.php is included as a template or stencil which the framework's user is supposed to override with their own code. In GPL lingo, this might well cause it to be a derivative work and that will require them to "contribute" those changes back to me which doesn't make any sense at all! There needs to be an exception for included sample or example files for which the GPL shouldn't apply.
  3. There is also a problem with GPL due to the nature of web or Internet. Another app I am developing is a bit heavy on JavaScript and contains static *.js and *.css files. The mere running of the app in a web browser will cause these files to be "distributed" through the <link> and <script> tags. From GPL perspective, this becomes a technical violation as no GPL license had accompanied this distribution. And in case you minify or compress your JavaScript or stylesheets for efficiency (which is a very common practice), this violation becomes even more grave as you're technically distributing GPLed source in an obfuscated form!

The GPL badly needs to be upgraded for these scenarios. Until then, it remains a good use case for desktop or console apps which run directly on your computer and usually have a clearer boundary of what constitutes a distribution and/or derived work.

9 comments

  1. skybrian
    Link
    Yes, you should be putting copyright notices at the top of each source file, even though many people don't. Otherwise it's ambiguous whether the software is covered by the license. People who care...

    Yes, you should be putting copyright notices at the top of each source file, even though many people don't. Otherwise it's ambiguous whether the software is covered by the license. People who care about this will set up a lint check to make sure it gets added to any new files.

    Also, many minifiers do include any copyright notices they find at the top of the combined file, and at least the big companies with lawyers will have that turned on. (I thought it was a little weird when I first saw it, but it's the right thing to do legally, and not just for the GPL.)

    Hobbyists are often casual about this sort of thing because for software that's rarely used, often nobody notices and the lawyers never get involved.

    16 votes
  2. [7]
    vord
    (edited )
    Link
    You are mistaken. They have no obligation to push their changes back upstream. They only have to keep that code open if they decide to redistribute your software. The AGPL does have some language...

    In GPL lingo, this might well cause it to be a derivative work and that will require them to "contribute" those changes back to me which doesn't make any sense at all! There needs to be an exception for included sample or example files for which the GPL shouldn't apply.

    You are mistaken. They have no obligation to push their changes back upstream. They only have to keep that code open if they decide to redistribute your software. The AGPL does have some language to that effect, but here's the thing: Because it's a license, it ultimately boils down to how you enforce it. I doubt even Stallman himself would be up in arms about the use case you discuss.

    From GPL perspective, this becomes a technical violation as no GPL license had accompanied this distribution. And in case you minify or compress your JavaScript or stylesheets for efficiency (which is a very common practice), this violation becomes even more grave as you're technically distributing GPLed source in an obfuscated form!

    Add a "external sources" link at the bottom of your page, list all unmodified GPL software there or link to the relevant repo which does have the license. The thing about the GPL enforcement is that it tends to be very forgiving provided you abide by one simple rule:

    Give the source code to your users if they ask for it.

    15 votes
    1. [5]
      kovboydan
      Link Parent
      Maybe I’m misreading OP, but this feels like the kind of situation for which AGPL was created?

      Maybe I’m misreading OP, but this feels like the kind of situation for which AGPL was created?

      3 votes
      1. [4]
        unkz
        Link Parent
        I think that's the exact opposite of what OP wants. OP doesn't want users to have to give him source code to their variations. The AGPL would explicitly force them to, since users of his project...

        I think that's the exact opposite of what OP wants. OP doesn't want users to have to give him source code to their variations. The AGPL would explicitly force them to, since users of his project would be using his software over a network.

        I'm not convinced that the GPL would necessarily apply to the sample code just by virtue of being in the same package though -- it should be a trivial matter to just not release the sample code specifically under the GPL, and put it under some other license.

        2 votes
        1. [3]
          kovboydan
          Link Parent
          @vord is spot on that they don't need to push changes back upstream; they only have to distribute source if they decide to redistribute the software. From AGPL 3.0: And if that doesn't quite get...

          @vord is spot on that they don't need to push changes back upstream; they only have to distribute source if they decide to redistribute the software.

          From AGPL 3.0:

          To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy.

          To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

          And if that doesn't quite get you there on AGPL v3, take a look at this randomly selected sample config file from Nextcloud config.sample.php:

          <?php

/**
 * SPDX-FileCopyrightText: 2016-2024 Nextcloud GmbH and Nextcloud contributors
 * SPDX-FileCopyrightText: 2016 ownCloud, Inc.
 * SPDX-License-Identifier: AGPL-3.0-only
 */
 
/**
 * This configuration file is only provided to document the different
 * configuration options and their usage.
 *
 * DO NOT COMPLETELY BASE YOUR CONFIGURATION FILE ON THIS SAMPLE. THIS MAY BREAK
 * YOUR INSTANCE. Instead, manually copy configuration switches that you
 * consider important for your instance to your working ``config.php``, and
 * apply configuration options that are pertinent for your instance.
 *
 * This file is used to generate the configuration documentation.
 * Please consider following requirements of the current parser:
 *  * all comments need to start with `/**` and end with ` *\/` - each on their
 *    own line
 *  * add a `@see CONFIG_INDEX` to copy a previously described config option
 *    also to this line
 *  * everything between the ` *\/` and the next `/**` will be treated as the
 *    config option
 *  * use RST syntax
 */

$CONFIG = [


/**
 * Default Parameters
 *
 * These parameters are configured by the Nextcloud installer, and are required
 * for your Nextcloud server to operate.
 */

          No one selfhosting Nextcloud is pushing their config files upstreams or making them available to users. Same with Bitwarden.

          4 votes
          1. [2]
            unkz
            Link Parent
            You're misunderstanding the purpose of the AGPL clauses you cite, which are specific to the concept of "conveying" and part of the original GPL. Those are separate from the network clause, which...

            You're misunderstanding the purpose of the AGPL clauses you cite, which are specific to the concept of "conveying" and part of the original GPL. Those are separate from the network clause, which is purposefully unbound from the concept of "conveying":

            1. Remote Network Interaction; Use with the GNU General Public License.

            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, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

            In fact, under the AGPL "Mere interaction with a user through a computer network" does require modified source to be made available to users.

            1. kovboydan
              Link Parent
              Neither GPL nor AGPL v3 care about what you do with the cookie recipe or cookies in private for your own use. If we try apply the remote network interaction clause to private use it looks...

              Neither GPL nor AGPL v3 care about what you do with the cookie recipe or cookies in private for your own use.

              If we try apply the remote network interaction clause to private use it looks something like this:

              1. Download AGPL software, like Nextcloud.
              2. Use and maybe modify, probably access remotely through a computer network.
              3. Make sure a copy of the source/modified source available to yourself.

              And that's without digging into "1. Source Code" - which is for some reason separate from "0. Definitions" - and sorting out whether a config or similar file is covered.

              And the Preamble:

              The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version.

              3 votes
  3. unkz
    Link
    I don't think you're going to get much traction from the FSF on web matters. RMS believes that web browsers should automatically detect and block any non-GPL javascript from even being loaded....

    I don't think you're going to get much traction from the FSF on web matters. RMS believes that web browsers should automatically detect and block any non-GPL javascript from even being loaded. They even have a browser plugin to do that for you.

    FSF is pretty clear on the matter of minified JS or CSS. They are well aware of minification, and consider those to be binary distributions. Source code is defined by RMS himself as the "preferred form for programmers to modify" -- minified code is not the preferred form for editing it, so it's not source code.

    13 votes