-- Leo's gemini proxy
-- Connecting to makeworld.space:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
**TL;DR:** Use the Mozilla Public License (MPL 2.0). It's like the LGPL, but allows static linking.
--------------------------------------------------------------------------------
I'm working on a dithering library in Go. I'll be releasing it soon, in a few weeks maybe, and I'll write a post about it when that time comes. But it got me thinking about licensing, and what license I should use for the library.
The vast majority of libraries I've seen stick to permissive licenses, mainly MIT. And I understand why, it's nice and simple, and you're not gonna cause anyone any issues. But personally, I like using more copyleft-style licenses for my libraries. I'm usually okay with some big company making proprietary software that uses my library (although this hasn't happened yet, so we'll see how I actually feel if it does), but it's important to me that any changes they make are made freely available. It's only when that happens that we can all benefit, in the spirit of FOSS. If someone could just come take my library, improve on it, sell it as a product (or part of a product), and keep their improvements to themself, making sure only they benefit, I'd feel terrible, and like there wasn't much point in making the library at all.
The GNU Lesser General Public License (LGPL) is the perfect license for this, it's designed for libraries and for allowing the integration of proprietary and free software. So why I am against it for Go code?
Well just as I was deciding that the LGPL would be right for my upcoming library, I remembered something I heard once about dynamic linking, or something. I looked into it, and found out that the LGPL requires proprietary code to dynamically link to the LGPL'd library. Since I'm programming in Go, which pretty much always statically links everything, this is not an option.
Thankfully, I found these[1] two[2] Software Engineering Stack Exchange questions, and learned that there was another license that can do what I want, the Mozilla Public License (MPL 2.0). I'd heard of this license before, but never had a reason to use it. But it seems it's the perfect choice for Go libraries. It's very similar to the LGPL, but allows for static linking.
There are some projects that allow dynamic linking by using the LGPL with a special clause, like wxWidgets[3] and ZeroMQ[4]. But modifying an existing license is not a trivial thing to do, and I Am not A Lawyer. It also means you're on your own if someone doesn't follow the terms of the license. If you use a standard license then there will be existing lawyers that understand it, and maybe even organizations like the FSF, Mozilla, etc, could help you out.
ZeroMQ even says they prefer the MPL 2.0:
> It is the intention of the ZeroMQ community to move gradually towards the Mozilla Public License v2, as a replacement for the current LGPLv3 + static link exception.
>
> MPLv2 offers largely the same advantages as our custom LGPLv3 + static link exception license, with the added advantage of being a standard license, thus easier for corporate lawyers to accept.
>
> MPLv2 is the recommended license for new ZeroMQ projects, and where possible, ZeroMQ projects should collect approval from contributors to move towards MPLv2.
That's good enough for me :)
The one potential issue I did find[5] with the MPL is that it works on the file level. So it would be possible to write a new feature in a new file and not share it.
> For example, someone could take one of the main file of your project, add `import my_private_new_file`, and
> modify your main method for example by adding `my_private_new_file.newAwesomeFeature.run()`
>
> And this way he could add new features to your project while only releasing the modified main file and
> keeping the actual logic of the new feature closed source in `my_private_new_file`.
But they also say:
> Obviously, that's an edge-case and it is quite unlikely someone would want to do that
And I tend to agree. I definitely wouldn't want someone trying to do that, but it's clearly against the spirit of the license, and would be legally risky. The MPL is a well established license, used by major players, and it is preferred over the LGPL + static linking exception. All of that together is enough for me to feel okay about this potential loophole.
Onward and upward! Go forth and use the MPL 2.0 for Go libraries.
-- Response ended
-- Page fetched on Fri Apr 19 18:25:40 2024