Ask HN: Should I open source my licensing server?

I used to work with a guy who worked at a prominently successful FOSS style company that used self hosted licensing as one of their bigger sales models (think like Elastic or Mongo) and he mentioned something I found really interesting. He said that you really should not care about licensing that much beyond just basic controls. Why? The people that would cheat your licensing are very often not who you want as customers anyway. The real moneymakers would never risk being caught out violating license terms. So really licensing software, at least for enterprise software, is kind of a dead end from that perspective as a moneymaker.

Interestingly enough the same thing happens with a lot of gamers. In the low end of the software market, often your pirate users were never going to buy your game in the first place, it was just opportunistically available to them.

Many pirates still buy games anyway, too.

That's also how I think of it, too. But still you need to do a good job of your basic controls. In our case, I want them to be as cryptographically strong as possible. Can you share the company?

My thinking on pirates is: marketers who work for free. Hahaha! :)

This is likely the best advice for the HN crowd. However there is clearly some sort of tipping point where draconian licensing models make a difference. These BIGCORP don't hire legions of lawyers because it loses them money.

I'd second that. If someone is circumventing your licensing checks then they're not a customer, but on the plus side they're effectively the same as a free plan user (with zero support) and maybe in their next job they'll recommend using your tool and getting a real license, or maybe they'll get tired of hacking each update and just buy a license.

I can see the idea that the OP is suggesting but decades of keygens and hacking have taught us that if someone really wants to use your software without paying, then they will.

I've seen people craft elaborate ways around my own software licensing check when the actual "hack" is jaw droppingly simple (and is all on github), the point is that the people you need to concern yourself with are the people who will pay for a license.

Decades of keygen have taught us that cracking licensing is an irresistible puzzle to some personalities

What you should do is track your installs but don't enforce. Then you can enforce later if you need to...but you can nag more effectively because you can show the value you bring (since they have like 50 installs).

That said, most licensing checks are simplistic and can be bypassed easily. I mean, this code:

if (licensed) then activate=true

is relatively easy to find and patch around by a motivated individual.

A better way would be to use a key from your key server to encrypt/decrypt their configuration, like with TOTP. But you still would have to make sure they didn't just bypass your encrypt/decrypt code.

Keygen.sh developed a good API based licensing service in the cloud which they later open sourced and worked out well for them (the main dev blogged about it and explained the reasoning.

I think with security products like this, open sourcing can be a good idea as it allows users to inspect the code and feel more confident that it is indeed secure. Plus you get feedback (and maybe even help) you wouldn’t otherwise get. And you can charge for services, etc even if open source (if you want).

Yes, but I doubt I could convince you if you haven't already been convinced by all the people smarter than me

https://www.gnu.org/philosophy/free-software-even-more-impor...

https://opensource.google/documentation/reference/why

> Open sourcing might lay bare some flaws which could be fixed. Or it might lay bare some flaws which could be exploited.

If there are flaws(, and there are!) it might be preferable to have the chance to learn about them from grumpy security open source contributors than after the exploit

How would you ensure that grumpy security open source contributors see them and not hackers?

You post it on HN first where all the grumpy security open source contributors congregate.

If you show the source you'll be showing it to both. If you don't, hackers will still go poking around anyway. They'll find the exploits the old fashioned way.

The grumpy OSS contributors become the hackers after dark, so just make sure you post the source code in the morning and you’ll be fine.

Open source it if you want to open source it.

Don't open source it because you want/need/expect other people to work on it because statistically, that is not going to happen.

Open sourcing your project will create more work for you, not less. Good luck.

Sometimes people work on it, but even with my popular projects, it’s rare. Most of our code is written by contractors.

Initially (2021?) one project had a bunch of OSS contributors who wanted to take part, but I felt scared to let go the reins and possibly needlessly suspicious of their praise and enthusiasm.. so I basically turned them all away, didn’t care for them, and they never came back. Felt sad.

Hahaha! :)

But I agree in the case of this licensing server in seems it might be rare to get people working on it. But if you do a show HN, you might get people picking apart security flaws, which is useful. From perspectives we haven’t thought about.

Probably gonna test it more, consider open sourcing later after a few proven deployments of this self hosted version.

Thanks for your practical comment. BTW- i like your writing and poetry at your blog, it’s cool. You have a style I’d feel happy read in fiction I think. Kind of elided, modern Ginsburg-ish, idk, but it’s good :)

Thank you.

> Initially (2021?) one project had a bunch of OSS contributors who wanted to take part, but I felt scared to let go the reins and possibly needlessly suspicious of their praise and enthusiasm.

I don't suppose one of them was Jia Tan? ;-)

I agree with this. I have a personal project that, even after years of working on it, still has as many features on the 'to do' list as have been completed. I would love to get help implementing them or testing the completed ones.

People will tell me that simply open sourcing it will make help magically appear. Not to say that cannot happen (sometimes it does), but the odds are against it.

I agree with this sentiment.

Looking at my own stuff people likely never appeared and contributed some code simply because my stuff is open source - and my stuff is much simpler, see for yourself: https://github.com/ericoporto?tab=repositories&q=&type=sourc...

There was an open source licensing server that also managed software updates for clients over the network. I forget the name. It was cool. Lots of people contributed. I think it got so popular it ended up tailoring to enterprise. They did the hosting. It took time but it worked out well for that team.

Strengths:

Zero-trust approach: This is a strong foundation for security, eliminating the need to completely trust any component in the system. Leveraging PKI and blockchain: These technologies offer robust cryptographic guarantees and tamper-proof records. Focus on cryptographic guarantees: This prioritizes strong security over obfuscation, which can be bypassed with enough effort. Immutable secure logs: This provides an auditable trail of license activity, aiding in troubleshooting and potential legal situations. PKI chain of trust: Utilizing a hierarchy of root authorities strengthens the overall trust model. Considerations:

Open-sourcing: This can be a double-edged sword. While it might expose vulnerabilities, it also allows for community review and improvement. Consider a private beta with trusted security researchers before full open-source release. Offline scenarios: While not perfect, exploring options like pre-downloading licenses or implementing secure, limited offline functionality could further improve usability. Threat model: Clearly define the types of attacks you're trying to mitigate (e.g., unauthorized license use, license server compromise). Overall, your approach seems promising! Here are some additional thoughts:

Performance: Consider the impact on application performance, especially with blockchain interaction. Scalability: How will the system handle a large number of clients and licenses? Integration: How easily can it be integrated with existing licensing systems? Open-sourcing for crowd-think is a valuable exercise. Here are some ways to mitigate potential risks:

Security audit: Before open-sourcing, consider a professional security audit to identify and address any critical vulnerabilities. Phased release: Start with a limited open-source release, allowing trusted partners or researchers to review before a full public release. Strong license: Choose a license that allows for contributions while protecting your intellectual property. By carefully considering these points, you can build a robust and secure zero-trust licensing system that benefits your company and potentially the wider software community.

are there subcomponents you could open source to test the waters? that would allow you to build the discipline and community before going for the whole thing

Yes

If you already have the PKI, why would there be a need for blockchain?

Apply to YC. Take on the major license companies like Thales, Flexlm, Wibu, etc.

You’ll need a lot of money and stay in it for the long run to take on companies like that. It’s possible though.

FlexLM is a name from the past! I remember cracking their protection with back in 99 or so, I remember it with the Highland name.

It would be an interesting idea.

This might be an area of opportunity where you could open source it however require a license for enterprise/business use.

We use CodeMeter. It is possible your product may be competitive to other SW license server products.

https://www.wibu.com/us/products/codemeter.html