11 votes

GPL or Apache license for an upcoming PySide2 project?

Posted by pyeri (edited )
Tags: open source, licensing

Afternoon Folks,

For my upcoming side project (for which PySide has been aptly chosen!), a desktop productivity app with features like milestone tracking, brainstorming, some motivational stuff, etc., I'm somewhat confused about the licensing part.

I was decided on Apache 2.0 license so far as I like their focus on merit based process, plus they actually seem to create a ton of software as an organization, it's not just a license. I like the GPL philosophy too but I'm more of a utilitarian than philosopher and the GPL folks seem to be ever more preachy about Stallmanian ethics than about the technicality of coding programs and developing apps (where I'm more interested as a utilitarian/engineer).

But it seems I may have to bite this thing and go with GPL here considering that though PySide2 itself is LGPL, it turns out that some underlying core Qt components are indeed still GPL licensed, these are addons such as QtCharts which I'm definitely going to need for displaying charts in my GUI. Unless there is a way to use matplotlib effectively with PySide2 which I don't know about?

Being a utilitarian engineer, I'm a pragmatist too and in that sense, won't really mind whatever license is used in the end, as the end goal here is to create something useful for the human's desktop, not to get intertwined in open source licensing debates.

I have a slightly longer term vision with this project and all I want is that going forward, I shouldn't be restricted from using some useful component or tool or library just due to licensing issues. From that perspective, are permissive or copyleft licenses a better candidate to license your open source projects? And which one would you suggest?

7 comments

  1. [7]
    GLaDYS
    Link
    I released software under both of these licenses and would indeed chose between these based on the target ecosystem and potential for code-reuse. Apache-2.0 I released my latest project under...

    I released software under both of these licenses and would indeed chose between these based on the target ecosystem and potential for code-reuse.

    Apache-2.0

    I released my latest project under Apache 2.0 because I wanted to allow anyone to take pieces of it and reuse them as they see fit with little restrictions. This project does not really have potential commercial value, so I'm not worried about a company forking it and selling it, but I hope other projects can benefit from the experiments we're running.

    Apache 2.0 is the least permissive of the permissive licenses, so it can use MIT and BSD dependencies, and I chose Apache 2.0 because clause 5 gives me peace of mind as a weekend-maintainer:

    Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions.

    GPL-3.0-only

    I have zero trust in the FSF anymore, but I'm happy to claim death of the author and use that license, because it's pretty good! To shield yourself from future GPLv4 drama, make sure you specify GPL-3.0-only instead of the default GPL-3.0-or-later license.

    That's the license I'd use for any "end-user" software, that would not really benefit from being split into reusable pieces. Because GPLv3 has been written to be compatible with Apache 2.0, it can use almost any lib, read the license compatibility wikipedia article for more info.

    Mixed-license project

    Because GPLv3 software can depend on Apache 2.0 libraries, you could decide to release the "backend" of your app as Apache, and the frontend as GPLv3. The final binary will be in GPLv3, but you can open others to reuse its backend, if that's what you wish. You don't even need to have separate repositories, just make sure that the files have the right SPDX headers (and ideally put these in separate folders). If someone reaches out, you can do the work of releasing that part separately, but don't need to incur the cost upfront.

    Relicensing

    As long as you are the only contributor, you are free to change the license at any time, as long as it's compatible with the dependencies that you're using. Once you accepted contributions, it's more complex:

    • At any point, you are free to relicense Apache 2.0 code into GPLv3
    • You cannot go the other way around without consent from all contributors though
    • Contributor License Agreements were a seductive way to keep flexibility, but they have been weaponized by companies like mongo, elastic and hashicorp to go proprietary, so you should not sign any CLA, or ask contributors to sign one
    16 votes
    1. [4]
      vord
      Link Parent
      I'd advise AGPL, especially for anything that is to be hosted, as it's an even stronger version providing protections against say Amazon or Microsoft going "yoink" and undermining any chance you...

      I'd advise AGPL, especially for anything that is to be hosted, as it's an even stronger version providing protections against say Amazon or Microsoft going "yoink" and undermining any chance you have of monetizing hosting yourself.

      4 votes
      1. [2]
        GLaDYS
        (edited )
        Link Parent
        OPs' project is a desktop app, so the AGPL would not add anything relevant. Also, while the AGPL got some corporate lawyers spooked, it's not the anti-Amazon bullet that some people claim it is,...

        OPs' project is a desktop app, so the AGPL would not add anything relevant.

        Also, while the AGPL got some corporate lawyers spooked, it's not the anti-Amazon bullet that some people claim it is, or Mongo would have kept it instead of writing the SAPL. While AWS would need to Open-Source all modifications to the software itself, the AGPL would not virally apply to all the control plane and management services around it. This is what the non-Open-Source SSPL tries to address, but in terms that are so vague that it's uncertain whether it applies to the motherboard BIOS.

        5 votes
        1. PuddleOfKittens
          Link Parent
          Desktop apps can be accessed through a thin client on someone else's computer. The underlying business logic may also be relevant in a business context. IMO the question is "why not AGPL?"

          OPs' project is a desktop app, so the AGPL would not add anything relevant.

          Desktop apps can be accessed through a thin client on someone else's computer. The underlying business logic may also be relevant in a business context. IMO the question is "why not AGPL?"

          4 votes
      2. brandt
        Link Parent
        Disclaimer: IANAL. If we have any IP lawyers here, I'd welcome their corrections. The AGPL doesn't necessarily prevent that. I think that's a common misconception because, in practice, SaaS...

        Disclaimer: IANAL. If we have any IP lawyers here, I'd welcome their corrections.

        The AGPL doesn't necessarily prevent that. I think that's a common misconception because, in practice, SaaS companies tend to avoid AGPL-licensed software like the plague. AGPL's surprisingly limited history in the courts make those companies' lawyers take an extremely cautious position on the ambiguities of (1) what constitutes "remote network interaction" and (2) to what extent do its copy-left terms apply to the other software behind their services?

        To this layman, the plain meaning is a lot less cataclysmic than that. But I digress.

        To guard against what you've described (another company offering your software as their service), you'd need something like the SSPL, which is itself based on the AGPL.

        In fact, the only substantial difference between the Terms and Conditions of the GPLv3, AGPLv3, and SSPL is in each one's Section 13:

        GPLv3

        source

        13. Use with the GNU Affero General Public License.
        ...

        Just clarifies how the GPLv3 and AGPLv3 interact.

        AGPLv3

        source

        13. 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.

        Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

        Server Side Public License (SSPL)

        source

        13. Offering the Program as a Service.

        If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

        “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

        4 votes
    2. [2]
      vczf
      Link Parent
      This isn't specific to Apache 2.0, right? Doesn't it apply to MIT and the other permissive licenses?

      This isn't specific to Apache 2.0, right? Doesn't it apply to MIT and the other permissive licenses?

      At any point, you are free to relicense Apache 2.0 code into GPLv3

      3 votes
      1. GLaDYS
        Link Parent
        Probably not indeed, you'd need to check library compatibity on a case-by-case basis.

        Probably not indeed, you'd need to check library compatibity on a case-by-case basis.

        5 votes