Discussion of license implications (GPL, LGPL, MPL2, MIT, iOS, App Stores)

@dback asked me to help him understand licensing issues better. I’m not exactly sure all of what he wants to know, or where this will go, but I’ll get the ball rolling with my (opinionated) take on licenses:

  • A LGPL library that provides some capability (like sync) can be bundled with an app of any license. The LGPL has a ‘relinking requirement’ that requires that the end-user can swap out the library, such as a DLL or .so file, with another version (so they can patch security issues, or tweak it themselves.) Since apps in many app stores (including iOS and I think Mac App Store) are cryptographically signed and encumbered by DRM, it is impossible for users to replace the “DLL” and therefore LGPL libraries don’t work on app stores like this. I used to be fine with LGPL libraries, but now in the age of mobile and app stores, I think they are the plague. (However, developers may be still able to get away with publishing LGPL to app stores, even though it may be dubious and risky?)

  • A GPL library or app that provides some capability (like sync) can be bundled with or modified to work with only with apps that are also GPL. Only a small percentage of applications are GPL, because of the major restrictions it permanently places on proprietary and non-proprietary developers, so this is a great way for a library/capability author to severely limit their target audience (and the Syncthing app may now have or in the future have useful bits that could be extracted into a more general purpose library of capabilities.) The GPL is much more restrictive than the LGPL, and GPL apps are not allowed on Apple’s iOS App Stores, according to the FSF as of 2010, and Apple has pulled GPL apps from the App store, such as VLC and GNU Go (the game). You can read up on it, but this has something to do with distributors of GPL software not being allowed to impose additional restrictions on the software, and Apple does.

    • [Example 1]: For example, if a Syncthing android app either statically or dynamically links to the Syncthing app packaged as a library, and makes API calls to it, the android app must also be licensed as GPL, because it qualifies as a derived work. It wouldn’t be possible to license such an app as MIT or anything besides GPL.
    • (i.e. You can’t go from GPL to MIT. You can however, take a MIT licensed app or library and happily stick it into a GPL app without issue. MIT is a permissive license, and you are permitted to do stuff like this. So you can go from MIT to GPL.)
  • [Example 2] However, if a GPL app exposes a network API, such as the REST or web network-based interface of Syncthing, non-GPL programs can invoke those network interfaces, and it is not considered linking, and the user of the GPL program is not considered a derived work.

  • I believe the current Syncthing android app wrapper merely hosts Syncthing in a thread, but then doesn’t link to it as a library (I could be wrong, only looked at the source for about 3 minutes.) This is rare, as most of the time the GPL network service is run in its own process, so I have no precedent to point to, and some GPL proponents or fearful corporate lawyers may have a different opinion, but I think this might work out to be the same as Example 2.

  • Ports / Adaptations - my understanding is that porting a GPL codebase to another language makes the port a derived work and therefore still subject to the GPL (or whatever the original license was.)

  • MIT/New BSD/Apache 2.0 is developer bliss: freedom to do as you please with the library, and include it in any app store or software of any license, commercial/proprietary or not. [Edit: there are apparently obstacles in including Apache 2.0 code in GPLv2 software, but not GPLv3.]

  • There is still often incentive for end-developers of a MIT library (like say ind.ie) to contribute changes and bug fixes back to the MIT project even though it is not required, because it is easier to have the main development team maintain the project, rather than each end-developer maintain their own private fork, and then go through the major hassle of trying to merge new features from the main developers into their private branch. Plus, developers often naturally take joy in contributing and helping others, even when it is not a legal requirement.

  • Of course, a big operation could use it as a starting point for a proprietary fork, and save a few bucks from having to repeat the effort it would take to re-implement their own version, but I question the efficacy of trying to place tiny speedbumps in their way to stop them, and the morality of increasing the barrier to viable businesses (businesses that provide a service that benefits the public,) and the wisdom of RMS’s GPL crusade when even big evil proprietary Microsoft sees the wisdom and mutual benefit in open sourcing a ton of things lately. I used to think RMS’s cause was noble, but now I find myself arguing against it 99% of the time because it limits possibilities for developers. I am not happy with the closed nature of Apple’s walled garden, but until we have a reasonable strategy at taking them out, I am not going to kiss goodbye 50% of the mobile market in my region as part of a futile crusade, and limit my own ability to increase in financial resources in this world by refusing to capitalize on their market. I know there is a danger in compromising on crusades, and pursuing power, but there is also a wise time for a strategic retreat. Plus, we are winning the open source mindshare with once evil (and still partially evil) corporations like Microsoft, and then there is Google who is flying high with tons of permissive open source, showing the world how smart it is. (And I think permissive open source is smarter than restrictive open source.)

  • MPL-2 is a per-file copyleft. You can include it in your app of any license like LGPL, and if you modify a file, you are legally obligated to share those modifications back to the community. Unlike the more restrictive LGPL, there is no re-linking requirement, so this does not kill the possibility of getting LGPL code onto an app store, so I think this is a great and fair and non-greedy option for those who still want some sort of copyleft.

One more nice article/quote about LGPL from an article called Your LGPL license is completely destroying iOS adoption:

But if you have an awesome new project that could be extremely useful on iOS - and you have no philosophical or ethical issues with it - please please please please add a clarification to your licensing that covers this use-case. Even the Free Software Foundation doesn’t want you to use LGPL. So, please, pick sides, but don’t leave it in limbo state. If you don’t clarify, you are just completely destroying iOS adoption.

Hey, if you want me to release the changes / updates I make to your LGPL library, I have no problem with that whatsoever. I do it all the time.

What I refuse to do entirely is to completely ignore the licensing obligations altogether and just start using the library. Sadly, there are examples of Spatialite-with-GEOS/ffmpeg/put-your-favorite-lgpl-library-here code in the Apple App Store with developers who do not care one bit that they are violating those terms.

Fortunately, nobody here seems to be talking about the LGPL. Unfortunately, I think the GPL is even worse.

So that’s my take off the top of my head. I have my biases: I am entrepreneurial and would like to start some small businesses that can fund cool (possibly open source / free / or generous freemium) utility and (partially proprietry, partially open source) cross-platform game software that people can benefit from and enjoy, rather than work for some megacorp. If every library out there was GPL, it might make my hopes for financial independence and contributions to open source impossible, forcing me to be a slave to an established megacorp, creating proprietary software as part of my day job. So I hope people don’t see non-GPL licenses as selling out or promoting injustice, because it can hurt the little guys more than the big guys. I hope we can all quit our day jobs to make cool software that furthers open source but also has some sort of open-source compatible business model so that we can do it full time instead of as hobbyists with much more limited time.

I think you missed the most important points: GPL emphasizes on users’ freedom in the software world, while permissive licenses emphasize on technology evolving and proprietary software business.

GPL really talks about the users’ freedom in the sense of software: it’s main point is that users always have full control of GPL software and their derivatives they run. It’s not legal to take a GPL software and make it proprietary and thus place restriction on users. MIT emphasizes more on the evolving of technology – they don’t care about freedom much (developers’ power to distribute proprietary software is an unfair game for people who don’t develop software, and even most developers are users at most of the time), can be used in proprietary software thus can sometimes be fund more and thus evolve faster, and their open source nature make them even easier to develop.

Proprietary forks are actually valuable. Mobile manufactures make the open source product Android proprietary on their devices, many of which make users effectively have no control over their phone software. For example, Samsung and AT&T make the AT&T version Galaxy S phones bootloader-locked (Tivoiation), which makes you unable/hard to replace their malicious modified Android system – an open source product is effectively turned into a proprietary product. If Android is even a bit more against Tivoiation, I would have a wider phone choice.

Your argument that you don’t have business without permissive license is because of your business model. (It looks like your major OS is a popular proprietary OS) There are small companies, like the one who makes Piwik, the one who makes Discourse, which make GPL software, use GPL library, and make money out from them. Larger company examples may be RedHat, Canonical.

There is also a misleading point in your quote: FSF does not encourage you to use LGPL, but they want to use GPL instead. The reason is that LGPL is for a case where there is a proprietary competent, but when there is no such competent, or such competent is eliminated, you should switch to GPL immediately to prevent further proprietary products developed on top of your free software.

No. We’re not going there. This is not relevant to syncthing usage or development and primarily serves as flame bait.

This topic is now closed. New replies are no longer allowed.

2 Likes