When will version 5 be MIT license again?

[jansepke]

I can totally understand that you want to get some sponsoring for this project. But for some big companies its not so easy to sponsor a project on github (e.g. complex invoicing processes). Is there any timeline when this project will be MIT license again?

Thank you for your great work :+1:

[jgr3go]

One additional point to add to this, personally I think it's bad practice to switch licenses in the same major version. semver even suggests making a new package because it could be breaking.

At best, this will prevent husky from being approved at any large organization. If the license can change at will in a major version, legal teams won't bother. Personally I think the idea is a great way to get sponsoring, but the execution should seriously be reconsidered.

[voxpelli]

Also: As far as I can see, the current license isn't open source compatible according to common definitions:

Open source licenses are licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared.

Maybe the Parity-7.0.0 could be open source compatible as it is fairly similar to the more widely used AGPL which is verified to be open source compatible, but the Parity-7.0.0 isn't verified, which complicates things.

Two alternatives for attaining the same goal:

1. Dual license under AGPL and a commercial license, as eg. highlighted on the AGPL Wikipedia page as well as multiple Stack Overflow threads
2. License under BSL 1.1 / Business Source License 1.1. It prohibits any production use of the software unless the project has allowed it through an Additional Use Grant and it always resolves to a GPL-compatible Change License (like eg. MIT) within 5 years, possibly sooner if a sooner Change Date has been specified. This license has gone through a review by one of the founders of the Open Source movement, Bruce Perens, and while it in itself isn't open source compatible, it is always guaranteed to resolve to an open source compatible license within the specified time frame, thus giving people like @jansepke a clear indication on when they can start using it.

Something to note about those two approaches is that, just like the current situation, neither of those approaches are accepted by eg. Google. See Google's AGPL-ban, BSL-ban and ban of any non-listed license.

My suggestion would be: Revert back to MIT + eg. sign up for Tidelift and push companies to subscribe to it and offer security SLA:s through that.

Or: Switch to BSL 1.1 with a Change Date of eg. 2 months, thus only excluding your module from the use of the likes of Google and similar for the first 2 months of every major release.

[brettz9]

In addition to @voxpelli 's points, the contrasting of open source and commercial projects I think might be better off clarified because the Parity license doesn't appear to have any explicit commercial use restrictions (like say the RPL or BSL). It's just that it is more AGPL-like, so, as I understand it, users can't make modifications on code behind a production server or other privately-held project without sharing their modifications over a network or such ("a freely accessible distribution system widely used for similar source code"). This may have a likelihood of deterring a lot of commercial use, but it does not prohibit it.

[brettz9]

Also in regards to the following from https://typicode.github.io/husky/#/ :

If you have an Open Source project, you're free to install or upgrade husky to v5 ❤️ If you have a commercial project and are a Sponsor, you can start using v5 today at work 🎁

I would presume you also want to allow any non-commercial sponsors to use the project privately without needing to share (as Parity requires after 30 days).

Except possibly due to @voxpelli 's points about a lack of verification for OS compatibility (e.g., presumably FSF Free/Libre or OSI approved would be examples of this), but just that clarification might help), my own suggestions are not that anything has been contradictory, but just that it could perhaps benefit from clarification.

[typicode]

@jansepke thanks for the kind words :)

GitHub has made things easier for companies to sponsor. If they're already paying for repos, I suppose it would only increase the existing invoice and may not introduce a new process.

Regarding the timeline, it will depend on sponsors. If more companies want to sponsor, the switch will be sooner (staying on v4 is fine too).

[typicode]

@voxpelli once again, thanks for the detailed comment and link 🙏

I may be wrong, but based on the following article https://dev.to/zkat/a-system-for-sustainable-foss-11k9, my (limited) understanding is that the AGPL works for libraries that are part of the end-product but not for developer tools?

Didn't know about BSF before.

Honestly, I wouldn't mind if there was a clearer/simpler path regarding all this.

Tidelift is a good suggestion. I got in touch with them a couple years ago. While it works for bigger projects, it wasn't a good solution for husky at the time.

[johannesschobel]

Dear @typicode ,

i can fully understand that you would like to get some cash back for providing such an awesome library like husky. However, i think, switching license between major versions (and then later switching back, if there are enough sponsors) is a very chaotic situation for developers and / or companies.

Maybe you can work out some kind of "free plan" for husky, which is MIT and "free to use" for everyone. However, there is also a "paid plan" (some kind of "enterprise support" or whatever) that requires users to pay on a regular basis - basically the sponsoring on GitHub or other platforms.

Of course this would require you to put additional effort into creating such a "enterprise plan", but will give developers and companies safety regarding licensing this awesome library. I mean, at the moment it is not guaranteed, that you will switch license again - for example in 1 year, making husky a fully paid product.

Also you state, "if more companies want to sponsor, ...", however, it not clear what amount of money you are aiming at. 100 USD / month? 1.000? or even 1.000.000? This makes it highly unsecure for devs to switch to v5.

Again, i can fully understand you for trying to make money with this library. And i wish you the very best with this idea and so on. But you should also try to understand devs that rely on this library, which may are unsure about the current situation / state of this library.

All the best, Johannes

[typicode]

@jgr3go thanks for the feedback! I think I agree with you.

If there's a less permissive license change, it should be a major version (going from MIT to Parity, GPL, ... should be major). That's why v5 is also a major version.

[KengoTODA]

I'm a FOSS engineer and here to support @typicode 's decision.

We have long history and many trials to grab the income: donationware, freemium, beerware, Open Collective, etc. However, we still have no solid way. You may know the news around openssl.

Platforms such as Open Collective and GitHub Sponsors relaxed the problem, but in my opinion we still have two more blockers:

• Personal developers understand necessity but have less budget
• Enterprise products have more budget but not motivated to pay

I think that the husky way is one of good approaches to tackle these blockers. It is also nice to hear that GitHub Sponsors is also going to motivate enterprise products to support source-available software projects.

Last, v4 is still open source, this is really nice for who loves openness of open source has one more option: fork. I do not recommend it but if money really matters we can fork and keep it maintained.

That's all of what I want to tell. Have a happy hacking day, everyone! 😀

[jansepke]

GitHub has made things easier for companies to sponsor. If they're already paying for repos, I suppose it would only increase the existing invoice and may not introduce a new process.

We are currently not a Github customer so it would still be complicated. But I can understand your decision. In our case we will take a look at pre-commit as it is easier to integrate into multi-language projects.

[ssbarnea]

I found this on a pure open-source project using MIT license, where Snyk reported an Unknown License warning, for good reasons. Reading the threat i realise that husky license is indeed no longer an OSI compatible license, so the warning was genuine.

I am now trying to identify what got husky in the dependency chain as I do not remember adding it myself, and evaluating how easy is to remove it.

The life of an open-source developer is already stressing enough even without having to deal with dependencies becoming non-open-source and I prefer to move away and never to look back, especially after we has several notable corporations decided to go against open-source.

While https://snyk.io/vuln/npm:husky?utm_medium=Partner&utm_source=RedHat&utm_campaign=Code-Ready-Analytics-2020&utm_content=vuln/npm:husky still lists it as MIT, their analyzer reports a warning of Unknown license, but that is another issue I reported to them, based on this thread I conclude that anything above v5 is not longer MIT, as "with exceptions does not count as MIT".

[thefrana]

I don't think switching licenses is a good idea and I think it is a really bad precedent for other OSS projects. Imagine having this in every major JS package. If you want to do something like this, you could create private repo and grant access only to those people who paid (some other projects did it), but I installed husky with npm install husky it was already at version 5. This is making it so easy to push v5 of Husky to the production of commercial project.

Like others said, we cannot no more using Husky in our company because of its licensing. We are forced to be at version 4 and eventually switch to other package, because nobody would risk of using inappropriate license as it's changing unpredictable.

In sum up I want to thank the contributors for their awesome work, but I strongly disagree with this radical step in changing the license.

[voxpelli]

Too bad this issue was closed (@jansepke: When many others have chimed in on an issue, just don't close it when you feel that you're done with it), but here's another case of the fallout from this: https://twitter.com/PostCSS/status/1371884268234940418?s=20

PostCSS decided to drop Husky 😞 Just shows the risk of picking an exotic license like this.

[ai]

The main reason for dropping Husky for PostCSS was https://github.com/typicode/husky/issues/868

prepare solution came when an alternative (simple-git-hooks) was already created (with a smaller npm package).

[agraves]

Couple people I know at large companies got burned by the license change internally (upgraded to 5 without realizing they weren't compliant). Seems like a breach of trust to me and I'm migrating away.

For the record, projects like FontAwesome do this the right way, with separate packages for "pro" and "free."

[voxpelli]

Looks like version 6.0.0 is MIT