code license should be gpl or mpl

[jmichelz]

http://hintjens.com/blog:68

To prevent capture of an open source software project you need:

A GPL-family license (or MPLv2, which works the same) that enforces two-way remixing; Distributed copyrights, which makes it impossible to buy them all, given enough contributors.

[oresmus]

I'm not sure I agree. When we get closer to writing code (or when I am less lazy about setting down my reasons for being not sure about this) we'll need to discuss this more. (And we might decide differently for different related coding projects. Certainly some other people writing OPSN-related code will decide differently than any one license we use, and we want all that code to be able to use compatible protocols and work together, so it can share data which forms a unified graph.)

(Note that this repo itself is not intended to contain any code, only discussion, so this issue is not related to this repo's license. As an aside, about this repo's license: for this discussion (or any discussion about future technical projects), the main issue is to let people copy the text, and to let them practice the ideas proposed in the text. The Apache license (though it's written for code) seems to me to require contributors to let people practice the ideas proposed in the text (due to its implied patent license provisions, which give people a license to practice any patented inventions necessary to run the code it applies to; I count text about ideas for code as "pseudocode" and interpret that part of the license the same way as if it was real code). The GPLv3 also has a similar provision, but that license is even more clearly code-specific. I don't know if there is a license intended for text which has this property.)

[oresmus]

I agree with the "remixing" issue referenced above.

For a reference library for using a communication and data storage protocol which we hope becomes widely used, I believe we want it to be usable in proprietary software (or in software running under proprietary OSes like iOS which require centralized signing and approval of their apps), so the protocol retains a single reference implementation and needn't fragment into multiple implementations. My only concern about a GPL-family license is that it might be too burdensome for use in that context. (I don't agree with the sentiment that making our software impossible to use in such contexts would be a good thing, as a way of fighting the existence of such contexts.)

I note that many projects in this general area (protocols, libraries, or frameworks for web apps) use non-GPL-family licenses (if this point is controversial as a fact, I'll give examples).

But perhaps the LGPL (if further weakened by removing its requirement to be able to link a modified library into any application that uses that library -- I think ZeroMQ weakens it in this way, but I didn't check in detail) or the MPLv2 (if it already leaves out that requirement -- I haven't studied it) would be ok in this regard. If they succeed in requiring remix-allowing within the library itself, without preventing its use in any kind of application software, that seems ideal to me.

(I also want a code license to have the same sort of patent provisions as Apache or GPLv3, which prevents someone from using patents to restrict the use of their own contributions to the code.)

(I am guessing that we agree on the overall goals and are only arguing about the means.)

[oresmus]

I looked into the MPL (version 2) and, at least to start with, I'm fine with it, as a license for a generic coding project. (Not for this repo -- for a new repo made for a coding project.)

I was not able to find out for sure that it's compatible with iOS, but (unlike for LGPL) I didn't find any definite evidence that it's not, and for an initial demo that's not crucial anyway.

[oresmus]

(If you (JM) take it as agreed that we'll just default to MPL v2 for new coding projects, subject to further discussion as needed for specific projects, you can close this issue.)

[jmichelz]

This one might be more applicable, it stops the application service provider loophole: https://en.wikipedia.org/wiki/Affero_General_Public_License

[oresmus]

That one is (IMHO) completely out of the question for a protocol library -- for that matter, so is the plain GPL (a subset of it). They would force the library to be usable only in GPL applications.

[oresmus]

I should add that (IMHO) different licenses make sense for different kinds of code we might make. For example:

• For something that should be useable as a component in a wide variety of other software, like a persistent OPSN pool (usable in a server or desktop-app viewer), or code for working with the "universal expressions" stored in an OPSN pool -- i.e. for "library code" -- it makes sense to me to use Apache or MPL, so it can be used inside any kind of software. MPL requires "two-way remixing" and Apache doesn't. I think we've picked MPL for this kind of code, since it's ok with both of us. (But I haven't yet actually read that license, unlike the others we're discussing.)
• For something simpler and/or not directly related to OPSN, like a minimal example server that runs under Sandstorm (to use as a starting point for an OPSN server, but having no OPSN-specific code itself -- just a way to get started with a specific database and server language), if it doesn't exist already and we wrote it, it would make sense to give it the same weaker license as Sandstorm or its other example code, e.g. Apache. That would make it easiest to get help from people with a more general interest (in Sandstorm but not in OPSN). (MPL says its v2 is compatible with Apache-licensed subprojects.)
• For an entire user application, like a full-featured OPSN client (with fancy graphical navigation etc), it might well make sense to use the GPL, since there is no need to let proprietary code incorporate it (and maybe some reason not to). (But even for that use, I'm suspicious of that optional "Affero" clause, since when I read it after it came out, I was not sure it couldn't be used to force any person operating a private personal server using such code to divulge their personal customizations of that server, but I'm not in favor of forcing. So I would agree to GPLv3 for that, but not (given what I know now) to AGPL.)
• But for new code written originally for such an application, but perhaps later best to refactor into a library for more general use, it would be best if it was always in the weaker license suitable for libraries (i.e. MPL). It's always possible to put the GPL on an entire work, once it's made, even if its components are MPL or Apache or weaker, but if you write new code in GPL and then want to factor out a library, you're in trouble (since the factored-out code is still under GPL -- you can't even put it under LGPL without permission of every contributor). So when writing new code, if you might ever want it to live in a library for general use, it ought to be under MPL at the strongest (imho), not GPL. So I would almost never want a new project to start out as GPL, for that reason (since you can't tell ahead of time how you might want to factor the code).