Help choosing new gomacro license?

[cosmos72]

As Gomacro author,
I recently discovered that the current LGPL license is more restrictive than I want.
Thanks to @glycerine for pointing it out.

LGPL 3.0, section 4. Combined Works imposes the following when someone wants to distribute a commercial program that includes a (modified or unmodified) copy of LGPL code:

---

4. [you must] Do one of the following:

   0. Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.

   1. Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

---

Unluckily, dynamic linking in Go is cumbersome and extremely limited - the plugin module is more similar to dlopen() than to dynamic linking, and currently only works on Linux and Go 1.8+ (support on Mac OS X and Go 1.10 is still alpha-quality in my opinion, and other platforms don't have it at all). In my opinion, dynamic linking is not a viable solution for Go code.

LGPL allows static linking (the norm for Go) of LGPL code with commercial code, but then the commercial code must be also provided as object files that can be relinked with a newer version of LGPL code. Again, this is very cumbersome. I have no wish to impose such a restriction on commercial programs that use gomacro.

I am looking for a license that

1. allows binary-only distribution of statically linked programs that include gomacro
2. requires the distribution of such programs to include a copy of the gomacro source code they used, including any modifications they made, under their original license
3. does not require releasing the source code for the rest of such programs.

Suggestions welcome :)

[cosmos72]

I am trying to understand if Mozilla Public License 2.0 fits my requirements.

The FAQ questions 7 and 8 are encouraging.

[ghost]

Serious question - what's wrong with MIT/BSD license? That seems to be the Go community standard?

[cosmos72]

Short answer: I want a copyleft license for ideological reasons, and MIT/BSD are not.

Long answer: I know the Go community standard license is three-clause BSD, but I would not use it for an open source project made in my spare time - I want it to remain open source, which for me means that all distributed copies (modified or unmodified, partial or complete, included in a larger program or not) must be accompanied by the corresponding source code under its original license (of the open source parts only - adding binary-only parts is fine for me)

MIT/BSD do not impose such source code redistribution - it's fine to take a MIT/BSD library, modify it, incorporate it in a commercial binary-only program and distribute/sell it. There are many famous examples where this happened. Some are: Windows networking stack (taken from BSD and adapted), Apple Xcode (based on LLVM and clang), Embarcadero C++ Builder (again, based on LLVM and clang) and many others.

It is not something I am willing to permit for my open source projects - even though I understand that MIT/BSD have their legitimate use cases, that many Go projects are MIT/BSD and that Google's Go compiler and standard library are 3-clause BSD.

[dacjames]

@cosmos72 While the licensing choice is entirely your purgative, you should know that your choice makes your library more or less useless. To me, this is a shame because it looks really cool.

I find it interesting that you mention LLVM-based projects as a reason to avoid permissive licensing as LLVM remains a robust open-source project, developed in the open by a diverse community. Apple continues to contribute directly to the LLVM project and by most accounts embeds a largely vanilla LLVM in Xcode. Many point to LLVM as the great success of permissive licensing; despite predictions to the contrary, commercial users have by-and-large chosen to contribute upstream over diverging.

A utility library like gomacro doesn't do much of anything by itself; to be of much use, it must be incorporated into a larger work that defines concrete macros. In effect, you've limiting your library to non-commercial uses or the extremely rare commercial GPL project. Is that what you want? I can tell you confidently that no one is going to steal your library and try to sell it; there's exactly zero dollars to be made selling generic software libraries.

Again, this is entirely your choice, just wanted to make sure you understand the consequences for users like me. Thanks for all the work; just having a working repl of any kind for Go is fantastic!

[cosmos72]

Thanks for the comment @dacjames !

I am trying to collect feedback from both the open source and commercial perspectives, and yours definitely covers both :)

Since we are at it, do you have experience with Mozilla Public License 2.0 license, or MPL in short ?

It is stated to "try to achieve a middle ground between MIT/BSD and GPL/LGPL".
It allows incorporation in larger programs as long as the MPL code keeps its license (and its source code is also distributed, including modifications)

[jparklab]

@cosmos72 A bit off topic, but I found xreflect has GPL v3+ instead of LGPL. Is this intentional?
https://github.com/cosmos72/gomacro/tree/master/xreflect

[cosmos72]

No, it's a leftover from the switch from GPL v3+ to LGPL.
Thanks for pointing it out, I will update it to LGPL

[jparklab]

You are welcome. Thanks for updating the license quickly!

[dacjames]

@cosmos72 IANAL but from everything I've read, the MPL would meet your needs. Note the "Larger Work" clause in particular.

At my organization, use of MPL 2.0 libraries is still discouraged due to the overhead of meeting the source disclosure requirements.

[cosmos72]

Good to hear that @dacjames :)

I agree that "meeting the source disclosure requirements" is an overhead for commercial uses, but it's also what makes MPL 2.0 acceptable to me as an author - of course it's my personal position.

I guess a quick solution to fullfill such requirement could be forking the MPL library on github and publish any modification there (provided the MPL library is on github, as gomacro is).

[mxk]

From what I understand, as long as you don't modify any original source files, a link to this GitHub repo is all that's required to satisfy MPL requirements. In my experience, changes to the original code, even in commercial contexts, are often followed by pull requests if only to avoid the subsequent maintenance overhead. Placing code into separate files will be the preferred option whenever that's possible, and those are not covered by MPL. In that respect, all you're getting from MPL over BSD is a link to your repo.

MPL is also not as popular as other licenses, so the issue with commercial use is more likely to be the need to vet a new license. That's the case with my company, but I'm optimistic that they won't have a problem with it. If you want the extra assurance that changes to your code will not be kept private, then I think it's a reasonable compromise.

[cosmos72]

License changed in version 2.7 to Mozilla Public License 2.0