As a fellow dev who is in a similar situation but scared of jumping there, thanks for writing a non-standard license. I think the licenses like MIT, while great for many, many projects, some times they are not the best for other projects that are either "larger/complex" (in a very abstract sense, think a DB) or more product-like.
I also think this should become more common and developers should get used to read the licenses of the code they use, at least until few of these "don't copy all my work and just resell it" licenses catch on and some become standard.
If you think there’s a new kind of license that should exist, that’s one thing. Maybe other people agree, and you can start (or better, join) a movement around getting that license recognition and usage.
But if you’re not talking about adding a new license to “the canon”, and are instead advocating that developers should write their own licenses, that’s not a good idea. It’s not that developers would need to “actually read the license”. The problem is that every time someone makes a new license they’re effectively putting untested legal code “into production”. Legal departments know what MIT, BSD and the GPL are (not just that they’ve heard of them, I mean they know them deeply). There’s decades of precedent and analysis around them. Newer licenses like ISC have to be carefully worded to make use of that precedent and are then scrutinized before being approved.
I’d also note that if the license you want doesn’t exist, it also might be because it’s legally impossible, unenforceable or just unappealing to users. “Don’t copy all my work and just resell it” sounds like CC Non-Commercial, which isn’t often used for open source libraries because the intent of open source libraries is for people to copy them (down to their hard drive) and resell them (integrated into a larger product).
Yes I'd love for a new license to exist and join that, but with 2-3 alterations; a bit like how with copyright you have the CC and multiple alternatives.
So for all, as the author in this case, limit the ability to just host the project itself and charge for it. People would still be able to modify the software and use that themselves, and share the modified code/fixes, or contribute upstream. I'd argue that this still follows the ideals of open source/free software, just avoiding abuse in 2022.
Then for some other projects, just no forks. With this variant, you can only modify it for yourself and cannot publish modified/derivative projects. This is IMHO no longer in the spirit of free software, but users can still read the code, modify it themselves and fix bugs, which is waaay better than current proprietary code.
Alt: I believe some people might want to add am ethical clause and a big/small/indie developer clauses.
Ooooh boy. Alright let’s go through these (IANAL, but I’ve studied some IP law, others can chime in if I fuck something up):
- For the first one, you’re going to need to define “modification”. If someone adds a single new function to the script, is that a modification? Can they now host the modified script? If not, what do you consider to be “modification”? If so, what if the new function is a no-op that was added to take advantage of the license? (Bear in mind that in cases like these, proving the infringing person’s intent is very difficult if not impossible)
- Regarding “no forks”: Mayyyybe this would work for some smart home projects? I wouldn’t touch anything with a license like this, too often my side projects become a thing I post on my website or use in a hobby thing that then gets intertwined with a work thing. You may say “fine, then stay away”, but if you want people to use your stuff, then it matters if people are scared of the license
- Regarding “ethics”: This just makes the code radioactive. JSLint is famously never used, even though it was written by the author of “JavaScript: The Good Parts” himself, because its license includes a “do no evil” clause. Does Doug Crockford think US Defense Contractors are evil? Will his opinion on them change in the future?
- big/small/indie developer clauses: Depending on what’s going on and how it’s defined, this could maybe work (someone who is a lawyer would need to say for sure). I know Unity, Unreal and GitKraken do a pretty good job with licensing terms that allow indies to check them about but then pay when their job makes money. But (with the exception of Unreal) they’re licensing you a product, you can’t see its source.
I honestly think if you’re a developer who doesn’t want their work exploited by corporations, do what the Janus team at meetEcho does: AGPL for everyone so no one can build on it without contributing back changes, and if you’re a corporation who wants to use it without the AGPL, prepare to cough up for a commercial license.
I avoided saying just "host" because it's confusing.
- You would not be able to host (SaaS style) the modified code either way; you would be able to host (store in your server) the modified code either way. Basically, if you use the project hosting the files and modifying them is fine. In this case, you would be able to modify Hibiki to your liking and _use_ it in your website. If you want to resell the project, that's a no-go either way. In this case, you would not be able to modify (or not!) Hibiki, possibly call it Yamazaki, and make an online editor for others to use.
> - Regarding “no forks”: Mayyyybe this would work for some smart home projects? I wouldn’t touch anything with a license like this, too often my side projects become a thing I post on my website or use in a hobby thing that then gets intertwined with a work thing. You may say “fine, then stay away”, but if you want people to use your stuff, then it matters if people are scared of the license
And yet people buy and use proprietary software everyday with licenses waaaaay more restrictive than this. Remember I'm not trying to say the "no forks" variant is open source at all, just saying that it should be better for the end user than proprietary since you can still fix your own bugs and make customizations.
- Sure the "ethics" and "indie" ones I haven't thought so much of since I'm not personally interested on.
> I honestly think if you’re a developer who doesn’t want their work exploited by corporations, do what the Janus team at meetEcho does: AGPL for everyone so no one can build on it without contributing back changes, and if you’re a corporation who wants to use it without the AGPL, prepare to cough up for a commercial license.
I really don't like this solution; I've used it in a couple of projects of mine, but it feels the worse of two worlds; individuals won't touch that AGPL, and for corporations it wouldn't matter if it's all just proprietary.
Why? If I am working on something with no intent on making a proprietary service out of it, I might as well make my own code GPL. And if I do have the interest in making a business out of it, then I'd inquire about the commercial license.
> Yes I'd love for a new license to exist and join that, but with 2-3 alterations;
I once worked on a codebase that was "authored" by non-software-engineer founders based on the same principle: an actual SWE wrote the core, but to extend functionality (think adding a route and its handler), they'd copy the example and change a few lines. The result was as horrible and broken as one might expect - I wonder if lawyers will shudder at the brokenness when they look at such franken-licenses. Sure, it works on the happy-path, but the failure modes can be nasty.
I'm having trouble pinpointing an exact introduction date, but judging by the text of pre-MPL dhcpd and BIND licenses (https://gitlab.isc.org/isc-projects/dhcp/-/commit/5d0ff7ea7c... and https://gitlab.isc.org/isc-projects/bind9/-/commit/0c27b3fe7... respectively), I'd guess that the ISC license has been around since at least 1995. This predates the MPL 1.0 (let alone 2.0) by 3 years, every GPL-compatible version of the BSD license (i.e. every version that's not the problematic 4-clause BSD license) by 4 years, the Apache License 1.1 (let alone 2.0) by 5 years (Apache License 1.0 released the same year, but it was basically a modified 4-clause BSD anyway), and the GPLv3 and AGPL by 12 years.
Needless to say, calling the ISC license "newer" than more popular licenses is pretty misleading. Lawyers have had nearly three decades to scrutinize it (and scrutinize it they have - hence the move from "and" to "and/or" back in 2007).
I also think this should become more common and developers should get used to read the licenses of the code they use, at least until few of these "don't copy all my work and just resell it" licenses catch on and some become standard.