Hacker News Reader

We need more business owners like you. I’d never heard of your product (I’m not in an industry that would have one), just read your blog post on the license; I I wish you wild success and I hope more small dev shops will have the same courage and the same outcome. Cheers!

Thanks for the kind words. I've seen quite a lot of open/fair source companies this past year. But I'd love to see even more! (And I'd really love to see more bootstrapped ones!)

Could an individual of ill-repute freely download the source containing the EE and edit it to turn off checks for KEYGEN_EDITION and KEYFEN_MODE? Obviously you have license protection against them redistributing the modified version but would anything practical prevent them from running it themselves?

It'd be a violation of the license terms. Other than that, I may send Liam Neeson after them. :)

His very specific set of skills is hunting down license term violators

>...but what I do have are a very particular set of skills. Skills I have acquired over a very long career.

Almost all software company revenues come from business customers who are too big to mess with stuff like this.

This. We have a few different things at work where it would be trivial for me to modify the database to allow unlimited users or grant access we don't pay for, but it'd be mostly pointless.

Yes, and most places that do this (e.g. OpenProject) don't have licenses preventing this, so I have deployed, and shimmed out the enterprise blockers, many Foss sass tools.

> but would anything practical

But would be it practical to go for a such guy?

There are always... stupid people who use hacked software 'because the employer don't have money', but I guess someone with a skill enough to read and patch such code is fully aware how the things are working and wouldn't be doing such stupid deeds.

I can confirm this approach works. We've been a satisfied paying keygen customer for 6-7 years, long before keygen was open sourced, and the fact that it is now doesn't change our decision to continue to pay for its use. If you have something that works well and fills a certain need, customers are happy to pay for it so they don't have to give any thought to it and can focus on their own core competency.

Thanks for the kind words, and for being a long-time customer (whoever you are). :)

I need to send your team some shirts!

Thank you for a product that is well designed and thought through. Not a common thing these days.

Absolutely lovely website you have at https://keygen.sh/

Did you write that as well or outsource it?

Thanks! I designed and built the website as well.

I haven't heard of Fair Source before -- is it gaining traction? Did you use the "legacy license" (that is linked to on the website)?

It's bleeding edge -- not even "official" yet. It's meant to be an umbrella term to replace the 'open source' vs 'source available' debacle when discussing permissive 'almost-open-source' non-compete licenses like FSL, BUSL, SSPL, ELv2, etc.

More: https://twitter.com/chadwhitacre_/status/1790101820364267902

I replied below about our homegrown solution, but this is very cool! I wish it'd existed when we wrote Userify, but we'll definitely plan on it for our next app! Kudos for solving this so elegantly!

Thanks for sharing, such an interesting approach! At my startup we're currently discussing licenses, this is very inspiring. I have a follow-up question!

The reasons for OSS you list include "Bus-Factor", "Longevity", and "Continuity". I'd summarize all of those as "even if they can't do business with [company] anymore, users can continue on" - our customers also say that's very important to them.

... But what if "can continue on" means "need some of those proprietary features"? And you're not there to sell to them anymore? Or you've been acquired by private equity, started charging 10^6x, and users want out? Users aren't allowed to clone the repo, remove your proprietary code, and reimplement it with their own solution, because:

> you may not remove or obscure any functionality in the software that is protected by the license key.

Is this a thing your customers are concerned about? What do you expect them to do in such a scenario?

I've sold multi-year and perpetual EE licenses for this exact reason -- to reduce risk of eventually losing EE features if Keygen LLC goes under and is unable to renew EE licenses. So in this case, if Keygen LLC goes under, they still have a perpetual EE license that will allow them to use existing EE features. But this is something I've been thinking about lately, and something my customers have been talking about. I want to come up with a better answer other than "well, pay me for a perpetual license and we'll remove that risk."

Maybe some kind of clause for a "Change License" in case Keygen LLC goes under, e.g. we go from ELv2 to Apache 2.0 if that happens. I'm not really sure what that'd look like right now, but I'll keep thinking on this and hopefully come up with a good answer eventually.

Outside of that, nothing is really stopping somebody from forking Keygen and reimplementing the EE features 'in-spirit' under a new code path, especially if Keygen LLC has gone bust. They just can't remove or copy the existing EE features verbatim.

How do you handle conflicting feature requests from two different paying customers? Like customer A wants buttons in the right, customer B wants them on the left.

I make the choice. I don't really listen to specifics like that from customers. I'm a SaaS, not a consultancy. Instead, I try to fully understand the customer's problem and then provide a solution to it a way that will work for everybody. If it doesn't work for everybody, or is a niche feature, then I probably won't introduce the feature unless I can come up with a way to make it valuable to other customers. Often, the customer doesn't understand the best way to implement something to make it valuable/usable to other customers, or the costs involved i.r.t. to maintenance, but I do.

With an API product, you also have to be picky about new features because once something is introduced, it can't be taken back (assuming you want to maintain backwards compatibility).

Say if someone copied your codebase tomorrow, and rebranded it as a competing solution and started advertising on same places as you are, what do you do?

I'd handle it the same any other business would who had their intellectual property infringed upon.

How would you know?

How would I know if somebody forked and rebranded Keygen's API to compete with me? I feel like it'd be pretty obvious unless they redesigned the entire API schema, endpoints, etc.

Not really something I'm worried about.

If this happens in a market far away that the original product would have a hard time reaching, it does not really matter.

But if the original product grows enough to be able to reach far away markets, then it's lawyer and discovery money would grow too.

I applaud Keygen API approach, though I really hope we find a formula that makes free software become pervasive while providing financial stability to authors and maintainers.

If you don't know, then it probably doesn't affect you.

Couple of questions: 1. You link to fair.io but it seems there isn't a latest license there only a legacy version. Do you know what the current status is on what seems like a pending version update?

2. Your project repro actually links to the elastic license. Is there some relation between the two? Do you prefer the fairsource license over the elastic license>

1. You can read more about the Fair Source initiative here: https://twitter.com/chadwhitacre_/status/1790101820364267902 (also [0] and [1] for previous discussions). It's not official yet, but it's an attempt to define a new term for Open Source vs Source Available. I figured I'd start using the term early and see what happens.

2. Yes, the ELv2 will be considered a Fair Source license, because it allows contributions, redistribution, forking, etc. You can visit https://faircode.io for an idea of what Fair Source will ultimately entail (Fair Source and Fair Code will be merged eventually AFAICT).

[0]: https://github.com/getsentry/fsl.software/issues/4

[1]: https://github.com/getsentry/fsl.software/issues/2

What was your calculus on ELv2 vs SSPL? The latter feels a better fit for the continuation of copyleft--too close to the fears you mentioned around AGPL?

I looked at SSPL, but it was really between BUSL and ELv2 for me. I ultimately chose ELv2 because it allowed me to keep my community edition and enterprise edition in a monorepo, where the latter edition is protected by license keys, i.e. ELv2 has a clause to where you can't remove or circumvent the license key functionality.

Since Keygen was previously closed source, I didn't want to split the repo up into the ee/ directory structure that you commonly see in other open core and fair source projects. I deemed doing so as 'too risky' -- too much code churn for little benefit -- as those changes would have a direct effect on the SaaS.

Instead, I opted for ELv2 because it offered me the ability to say, "hey, I'm making this fair source, do what you want with it, just don't compete with me or remove the license gates for the paid features."

Here's some of my internal dialog i.r.t. the license choice: https://github.com/keygen-sh/keygen-api/pull/668

Fair Source seems to be pretty bleeding edge:

https://github.com/fairsource/fair.io/issues/14

Sounds good! Honestly, I may not take this route due to the nature of my product (a self hosted CMS with Enterprise and OSS versions). But very interesting, thanks for sharing!

How do you actually protect the CE users from setting the environment variables to activate premium features?

If you are desperate enough to shim it out you're not worth pursuing as a customer

Yes, but this will cost money and resources. Large companies can take this as a loss. Small companies will go out of business

In my case, Keygen is a very critical part of a business -- much like billing -- so making sure it's reliable, secure, and well-maintained is paramount. This fact, in and of itself, weeds out most individuals (and businesses) who want to fork and steal, because then maintenance is pushed onto them or onto an untrusted third-party, which has a non-trivial cost for any worthwhile business. Much less risky to just pay the vendor of the software instead of treading through the risky route to save a few bucks.

Keygen uses Keygen to license itself via license gates: https://github.com/keygen-sh/keygen-api/blob/e668dffbb90bd53... (the EE edition requires a license key with entitlements to access the EE features).