Since it was already confusing, I'll work on clarifying that point specifically in the future. https://github.com/dashborg/hibiki/blob/main/LICENSE , tried to make it clear that any generic hosting was fine, and also 100% free if it is used for internal tools.

Anyway, looks below like you're considering a regular 3-clause MIT, so good going on that. :)

1: Hell, even for long-standing OSI licenses the real-life legal implications may be different than what the OSI community assumed. But at least there you'd be in a billion dollar yacht with many others, as opposed to stranded on a desert island with your modified MIT.

Early versions of Creative Commons (CC) license had a bug in which the license would terminate on breach of terms. The terms were easy to mess up, like requiring attribution and linking to source. There is now a new form of copyright troll that is basically fishing for CC violations.

Please do consider just good ol' MIT or (A)GPL. It'll actually allow people to make use of this really cool code that you've written.

As for the SaaS concern: nothing will stop someone motivated enough from writing a compatible drop-in library that does the exact same thing with the exact same syntax. And honestly there's nothing that you can do about it.

While one of the standard licenses may not cover the exact terms you would like, I would still recommend to consider using one because it makes adoption so much easier.

https://www.elastic.co/blog/elastic-license-v2

At least you will have a chance of not scaring off anyone with a legal department.

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.

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).

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.

- 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.

- 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.

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 think “don't roll your own licence (unless you have relevant legal expertise)” should be a regular mantra much like “don't roll your own crypto (unless you have significant cryptography expertise)”.

With the joint caveat of “unless it is for a personal project or plaything, for learning/practising/gaining that expertise, that you don't expect others to use” of course.

No matter how careful and well-intentioned your efforts are in either case, the chance of unintended consequences causing faf (for you in this case, needing to explain and/or reword in order to reclarify and smooth edge case interactions with other common licences).

Check out the polyform licenses

https://polyformproject.org/licenses/

(Just a question. I may add more comments to this, whether you reply or not. As I think about it :))

(1) I can't incorporate Hibiki into anything (A)GPL licensed, which many of my projects are.

(2) Ideologically I can't get behind something non-free, even though I completely understand why you wrote the license the way that you did. Realistically all it's going to do is hinder adoption (see parent comment of mine).

(3) You can say I'm not going to get into trouble, but your license says otherwise, and I really can't use something unless I'm 100% sure I'll be in the okay, ya'know?

I am happy to pay for a FOSS license, but obviously that will then allow other people to use the code without paying for it, because of the nature of FOSS.

Just make the license free to use except for a saas. And you'll accomplish what you want without being misleading.

The intent was that if you're at a company and write Hibiki code, you're all good, no problem. If you're at a company and you're offering a service which lets your customers write Hibiki code that you then host, then that's no good.