Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Add license key verification to your apps (github.com)
131 points by frknsn 65 days ago | hide | past | web | favorite | 88 comments

Be very careful with licensing.

VMware early-on had licensing code that disabled a customer's app and cost them a lot of money. Licensing of enterprise features is best to have a nag screen and disable some future actions rather than drop a ban-hammer. They were forced to strip out that code and ended up with weak enforcement of licensing.

Telemetry and online verification are unacceptable to some customers of on-prem software. To them, it should work even if the vendor goes out of business.

Volume license keys should exist for large-scale deployment of on-prem software in concert with open sources surveillance (search engines and warez sites) of license keys and software to prevent abuse. Even then, it's better to reissue volume license keys to customers because DLP of an external entity is an essentially impossible task.. at least they will know there's a problem and may work to police themselves.

Stopping all piracy is undesirable because persons who cannot afford it but are in/direct decision-makers have the ability to sabotage sales and/or acquire an unfavorable impression of the brand. Piracy and leaks are indirectly helpful to overall sales and marketing. Keep it down to a dull roar, because some people and some factions of industries are more-or-less like Fight Club. If something is used commercially at-scale from a small vendor, support their survival with licensing fees... don't be Best Buy.

Nothing is worse than the licensing of Archicad.

Downloaded the trial? Great! Enjoy.

If you don’t read the license terms, then you don’t find out that anything created or edited with the trial version is encrypted to the installation. I found out about this by searching the error code I was faced with after the fact.

I lost weeks of work, couldn’t even buy a license key to unlock it as I had reinstalled the software (within the trial period).

Needless to say, Graphisoft will never see a penny out of me.

Thanks for your valuable comment!

I thought telemetry and online verification will be just an option. If some app vendor doesn't want their users to force such thing, they will not use it. However, maybe, for some specific users, it may make sense.

Np. I forgot to mention that on-prem software usually optimizes for either proprietariness or COSS. If the former, it maybe worthwhile to employ multiple obfuscation and integrity checks in order to protect IP.

A VMware acquisition product I was involved in used a lot of dynamic language code and it seemed like a great idea for rapid development, but not necessarily for maintenance, sustainment, and IP protection. (They were still acquihired for eight figures nonetheless.)

If I were to be involved in a future enterprise startup intended for FNAC and/or acquihire, I would look at Crystal, Go, Haskell, OCaml, or Rust rather than the usual dynamic language suspects.

> I would look at Crystal, Go, Haskell, OCaml, or Rust rather than the usual dynamic language suspects

Or, you know, go full obfuscation: minify your JavaScript before your ship it!

Back in the day, we used Mozilla's Rhino as a JS engine -- if you're not familiar, it was a JS engine that compiled JS to Java byte code, literally putting the Java in JavaScript (or vice versa?). IIRC every function became a Java class, which made for some serious weirdness when it came to debugging garbage collection (new anonymous function? more permgen usage!)...

We shipped a .jar for on-prem installation. Needless to say, anyone who tried to decompile got a hilariously confusing set of Java code. :)

> If I were to be involved in a future enterprise startup intended for FNAC and/or acquihire, I would look at Crystal, Go, Haskell, OCaml, or Rust rather than the usual dynamic language suspects.

Thank you for your insight again. I tried to Google FNAC but I didn't have luck. What does it mean?


In this case, "feature, not a company" (I believe).

>Licensing of enterprise features is best to have a nag screen

At one of my past startups, I was asked to implement a licensing scheme, and we went with a hybrid approach. Nothing that one of our customer's customers would see was initially affected, but our customers would see a nag with a 30 day countdown. After 30 days their customers would also see the nag, and lockdown would occur after 60 days. That gave everyone plenty of time to resolve any license issues and avoided any "whoops, we broke your stuff at a critical time" nightmares.

> open sources surveillance (search engines and warez sites)

That's the first time I've heard "open source" used to refer to a warez site.

Is this overloading of the term being seeded by someone in order to, in a roundabout way, discredit the open source movement? A few years ago there would have been an obvious suspect for such FUD, but they seem to have embraced open source these days, so that wouldn't make sense.


> That's the first time I've heard "open source" used to refer to a warez site.

I think "open-source intelligence" [0] is probably a little more commonly used but both terms basically refer to the same thing -- the acquiring and/or gathering of data or information from public, or "open", sources.

Originally, it was mostly a government/intelligence thing:

> Open-source intelligence (OSINT) is data collected from publicly available sources to be used in an intelligence context. In the intelligence community, the term "open" refers to overt, publicly available sources (as opposed to covert or clandestine sources).

More recently, it has been used to refer to the act of gathering information by searching the Internet.

> Is this overloading of the term being seeded by someone in order to, in a roundabout way, discredit the open source movement?

To be clear, this usage of "open-source" predates open-source software and "the open source movement" by a few decades, at least. Additionally, as the Wikipedia article explicitly points out (in the first paragraph), "it is not related to open-source software".


[0]: https://en.wikipedia.org/wiki/OSINT

Open Source surveillance means "looking for/at stuff that is openly published" - e.g. looking on warez sites for keys being shared..

I'm pretty sure the term has been in use since the 1940s

Ah, I guess so. Thanks. Perhaps my tinfoil hat got in the way of seeing the context.

It is called some other terms depending on country, so it can be non-trivial to grok when you first encounter it.

(For years, I knew it as "White Intelligence")

"Open source" is a term long-used in intelligence/police circles that refers to the means of obtaining information, e.g. a newspaper article is an open source.

As most intelligence-related terms do, it has inevitably spread out to the wider audience of wannabes and obsessives about military things. Realistically, you don't use it in normal conversation, particularly in places like HN, precisely to avoid confusion... unless one wants to signal that he's using it in the "intelligence" term, i.e. that one is a sad wannabe.

Upvoting this comment (and its informative responses) because I was equally as confused by the wording in that phrase.

No to be harsh, but this is largely useless.

The biggest issues with in-app licensing is

(1) Binding licensing to the machine (or the user!)

(2) Making sure that your licensing check can't be NOP'ed by a l33r haxxor within 5 minutes of the release.

Tangential to that is (3) which is an ability to tolerate minor changed to the machine and OS reinstalls without invalidating the license.

(1) and (3) aren't hard to solve, just need to decide which machine/OS properties a license should be to "latched on". Popular choices are MACs, HDD serials (from the ATA IDENTIFY block), SMBIOS IDs, MachineGuid on Windows, etc. Better yet, it's not a bad idea to bind to a _set_ of machine properties and then tolerate a change of _some_.

(2) is a domain of its own. Basically that's an anti-reverse-engineering task. It's not terribly hard to roll out something on your own, but you do need to know what typical hacks look like. From exe patching to process training / API hooking, there is a substantial learning curve, but it's a quite interesting one.

That is the biggest part of any "license key verification" is not the actual "license key verification", but rather all the nuances that make sure it actually works as designed and doesn't affect users' experience in normal-use cases.

I really believe this is why SaaS is such a dominating business model now. Software licensing failed because it is technically impossible, and no amount of clever tricks will save you from determined groups / individuals. If it runs on your machine, you will be able to get it to run again without the licensing requirements. We saw large companies get pwned time and time again.

On the other hand, there is no way you can see what a SaaS backend is doing and replicate that locally. Sure, you can rip off the frontend, but that's just a thin client over the API anyways. The API is the proprietary product, and much easier to secure.

Even if a blackhat breaks into your SaaS repository and leaks your source code (which is generally a freak event, especially among businesses that take cybersec seriously) - what are your customers supposed to do with that? I wouldn't expect your average AirTable customer to be able to understand how to launch and maintain an AirTable instance.

It's just a better idea to serve your product over the Web. If you sell native applications, you can't expect to make as much money as SaaS equivalents.

This is not true for business applications and many customer ones.

Enterprises cannot risk legal problems. And home customers will buy licenses if price is fair.

Not sure whether I would agree that (1) and (3) aren’t hard. I recommend checking out LimeLM with the blogs and the (very informative!) forum.

Weirdly enough I would rank “make sure that the Antivirus software solutions do not go randomly crazy on your software protection” rather high (despite certificates and whitelisting). So I would wholeheartedly agree with your summary statement :-)

True, but note that in many cases the goal is not absolute security but rather making it as inconvenient as possible for someone to circumvent the licensing.

In some cases the licensing security is even weak by design, e.g. Windows 95 or the early AutoCAD. This is desirable when the size of the userbase itself is of value (which is actually true for a lot of software!).

Cases like W95 and Photoshop are exceptional edge cases that worked for them as a part of a very aggressive marketing push with a very long-term market domination goal. It doesn't apply to ISV products that need to feed their devs right now.

If you add licensing enforcement into your program, making it trivially breakable is just... dumb. At the very least it will pollute the heck out of native search results with all the hacked versions, because THAT will in fact be the more relevant search for a lot of people. Secondly, people won't bother actually buying a license if a hacked version works. It's a very persistent urban legend that allowing easy hacks is good for adoption, but it's a legend indeed. Making products less easily hackable results in massive increase in sales.

It depends a lot on where your revenue comes from. If it comes from large businesses, realistically they aren’t likely to pirate since it’s a legal risk to them and a hassle compared to just buying the thing. In that case, some token DRM could be enough.

> If it comes from large businesses, realistically they aren’t likely to pirate since it’s a legal risk to them

In that case, wouldn't a "free for personal use" license be sufficient? I know some software Oracle's VirtualBox, for example, implement something like this and it must work for them because they come down hard on supposed violators.

Yes, that could work, though I think if you make it too easy for people to use it for free, then many will do so just as the path of least resistance, at least until you make an issue of it. Just putting some kind of minor barrier in the way is enough to make paying the easier option, and it doesn't require any monitoring or enforcement.

Is remote verification fully open over http with no user credential verification or rate limiting? If I were to implement remote verification in an app, I would want to have the user logged in to an account prior to adding a license key. You could accomplish this by putting the KMS behind a proxy but this seems like a likely attack surface if using this the way it’s outlined in the docs.

Personally I found LimeLM offering a pretty amazing and sophisticated product at very decent prices. Personally, I would never want to suffer the pain of keeping licensing servers running etc. :-)

In my experience, software licensing will just “get rid of the casual piracy” - but I could never see not having a licensing solution in software work for business...

Beyond protecting software I found it similarly necessary to take down illegal software copies. There are automated tools for that luckily.

Yeah, your software will be cracked sooner or later. But it is not all black and white and there are now really great sophisticated solutions out there that minimize the frustration for paying customers whilst also protecting your IP...

> I could never see not having a licensing solution in software work for business

The most business-y of business-y tech businesses, Oracle, doesn't use license keys. Everyone can download pretty much any of their products. When they acquired the company I worked for, the first thing they did was to release master licenses to everyone for free. Saved us peons in the support trenches the aggro of dealing with a terrible license-server we embedded, the name of which I've mercifully forgotten.

How do they do it? Their audience are legitimate businesses who would rather stay on the right side of the law than save a few pennies here and there. And Oracle won't answer the phone unless you have a paid support contract.

Obviously this model won't work for everyone, but IMHO businesses who sell to businesses can live happily without license keys (and the stress/costs they generate on their support operations).

Oracle does not rely on companies' good intention, or their need for ongoing support.

They use contracts and audits to make sure they get what they're owed. If you can force companies to pay after they start using something, then making it as easy as possible for them to expand usage is going to maximise your revenue.

Google 'Oracle License Audit' or 'Oracle LMS' to learn more.

Man, I worked for them, I know the score :)

And that's precisely what I said: they just use the law ("contracts"). Legitimate businesses don't want problems with the law. It's more effective, for Oracle, to carefully draft (and subsequently enforce) legal documents, than to add some rigamarole that will only make life harder for legitimate clients and their own support ops.

Right, but the cost of enforcement doesn't scale linearly with licence cost. If your median customer spends millions with you per year, you can afford to spend money on enforcement. If your median customer spends $10k/year, I don't see how you can compel them to submit to an audit, or how you can get positive ROI from enforcement activities.

This is one of the benefits of SaaS (for sellers).

You’d be surprised how far a couple of graceful but stern legal-looking template letters can go.

Of course SaaS is a solution, but that doesn’t really apply to the type of software that requires license keys (i.e. standalone and likely behind the firewall).

> ...that minimize the frustration for paying customers whilst also protecting your IP...

Media publishers generally do the reverse.

Make the customer pain in the ass (like require expensive hardware and software that needs to pay every year) only to play your blueray disk.

While pirates don't need to suffer and just play it as they want everywhere because they obviously won't copy those shit.

Why MongoDB?

So app vendors can leave the database wide open on the Internet, for anyone to pull their customer list or generate their own keys.

I wanted to use a no sql database at the beginning. However, I prepared an interface first and implemented as MongoDB. We can implement the interface with PostgreSQL for example. I really appreciate PRs :) Here is the interface we can implement for other databases.


I thought this also. SQLite as a default would have been nice.

Because that's the database the dev picked to use?

Because it's webscale, duh

Why !MongoDB?

Because MongoDB is a document store and you really only need a key/value store for this.

Also because MongoDB started life preferring speed vs durability, which is a bad look for a database. They may have fixed that now, but I cannot forgive them for that.

"The best tool is the one I know".

Except when it's not. :)

I don't compare HTML vs. C here, obviously I am talking about databases. All personal feelings aside, there is no technical reason to NOT use MongoDB as a key value store if one has experience with it, because after release comes maintenance and learning a new tool while fixing production problems doesn't make sense to me.

I remember reading on here at one time that under some scenarios your data doesn't come out the way you put it in, or something to that effect.

I much rather have a license key tied to a preferred account then to a platform like Google/Apple. That's also allows for cross-platform licensing which is rare among apps.

This is really cool - you should write a how-to blog on it when you have time. I think it could really help drive more adoption.

Should I write it in GitHub wiki page? Or, is there any other place that you can suggest? Thanks a lot for the feedback!

Should I remove remote verification entirely? Or, how can I adjust to make it more proper to use?

I can prob patch this over in the time it takes to finish a mug of coffee


I think that's a very simplistic view of ethics. Most things are not that black and white. Proprietary licensing is the most successful funding model we've found so far for software. And that funding doesn't just make some people rich (though it certainly does that); it also pays for lots of developers to do things that often don't get done in less well-funded projects. Yes, some vendors abuse the power that proprietary licensing gives them, but not all do. So I think this specific issue is a lot less clear-cut than you and other free-software advocates make it out to be.

I reject any argument which justifies behavior because it makes someone money that they otherwise might not. Captalism does not justify a lack of ethics.

I think you might have misunderstood my argument. My main argument is that the money from selling proprietary licenses also pays lots of developers to work on important things, which they wouldn't (often couldn't) do if they weren't getting paid for it. So the users of the software are better off because the developers were able to do important work and get paid for it. And that was only possible because the vendor could be highly confident of getting enough return on its investment to justify paying those developers. And the vendor could only get such a return on its investment because it's selling proprietary licenses, as opposed to selling an auxiliary service (which often leads to misaligned incentives for end-user software) or begging for donations.

Don't forget that (and this has been mentioned four times now in this thread) you can sell open source software. No need to beg for donations. Charge for the software and for the source code.

But then as soon as a paying customer exercises freedom 2 and helps their neighbors by redistributing the software on the Internet, the vendor is most likely screwed. Particularly if they developed a great piece of end-user software that doesn't need support, training, hosting, or any other service to go with it.

Has this ever been shown to happen in practice? The vendor is the only one who can provide a guarantee that the distribution is genuine (i.e. not tampered with), provide timely updates, security notices, etc.

Your premise is wrong: there is nothing unethical about closed-source software. In 99% of the cases users want great software, great customer support and don't care about the source. If they really do, they can often sign an NDA and buy it. And that's fair. Free market doesn't need a pseudo-ethical middle-man.

I think you might have replied to the wrong comment, because this response makes no sense. ddevault said:

> I reject any argument which justifies behavior because it makes someone money that they otherwise might not. Captalism does not justify a lack of ethics.

ddevault's point is that the mere fact that doing P makes someone money is irrelevant to whether it's ethically okay to do P. ddevault does not say whether closed source software is unethical or not (in this comment), and so your "premise" does not exist here.

Furthermore, you go on to make exactly the mistake ddevault is complaining about: "there is nothing unethical about closed-source software." Why? Because "[the customers are willing to pay for it]". The fact that there are people willing to pay for something is irrelevant; the fact that there's a market for hitmen doesn't make that acceptable either.

While that's true, you're not going to convince anyone with that statement who didn't already agree with you; it's not a productive comment, and it's not one that invites discussion or "what to do about it".

By contrast, several top comments here are pointing out how it's counterproductive to do this kind of license enforcement, and that it introduces fragility. Someone pointing that out, and then throwing in an "or you could use Open Source, where you don't have to worry about this at all, and this kind of enforcement makes that an increasingly compelling alternative", is going to get a lot more traction than just a blanket statement that will not change any minds.

Who says this has to be implemented in a closed source application? And it’s hardly licensing that enables closed source applications... it’s compilers that do that. :)

There’s plenty of reason for end user software to be closed source. The biggest one is so that it can exist. Plenty of software would not be written if someone was not paid to do it. And plenty of those would not be paid if the source was available.

If you disagree, vote with your wallet.

Minor nit, open source != free as in beer. In FSF philosophy it's not wrong to charge money. It is wrong not to include the source with the customer's purchase.

I love open source software and use it everyday, so this question is coming from genuine curiosity. I'm a bit conflicted about how I feel above the "ethical" argument for OSS.

Why is closed source software unethical? Is it unethical for McDonald's to sell me a Big Mac, even though they won't provide the recipe for the secret sauce (yes I know it's Thousand Island dressing)?

A closer real-world analogy is "is it unethical for john deere to sell a tractor that you're not able to service due to artificial restrictions".

But the McDonalds one sorta holds up too. Let's examine the 4 freedoms:

1. Freedom to eat the food you purchased using any utensils (freedom 0)

2. Freedom to modify the food (i.e. add ketchup or hot sauce) and study it (investigate the ingredients in it, i.e. ask how much sodium is in it, or if the oil it was cooked in was meat oil).

3. Freedom to share an unmodified piece of the food with others (give a friend some fries)

4. Freedom to share the food, even if you've modified it or attempted to copy it (give your friend fries with ketchup on it, freedom to share your home-made fries modeled after McDs with a friend).

It's arguable if "provide the recipe" needs to be included in those freedoms. Maybe. Either way, I'd argue that yes, it's unethical for macdonalds to sell you food without at the very least giving you the above freedoms, and also telling you all important ingredients in it (allergens and nutritional info, etc)

The reason people aren't complaining about freedom wrt food is because the freedoms are already mostly there. Software licensing commonly requires things like "you can't use this software without an active internet connection to verify you purchased it", or "you can't install it on two computers". I've yet to find a food that has a limitation of "you can only eat this food if you're on the phone with us so we can verify you're not putting ketchup on it".

If food was restricted in the same ways software is, I would call it unethical, yes. Selling mystery food with no ingredient list, that I'm not allowed to attempt to make my own variant of, that I can't add any additional ingredients to, and that I can't eat at my leisure.. yeah, that would be either unethical or a form of performance art.

It's a great question, and I wish I had more time to delve into it. It really comes down to how a person defines their ethics.

FSF philosophy (which I love but am not 100% in sync with) is detailed here: https://www.gnu.org/philosophy/philosophy.html

Discussion around why proprietary software is unethical: https://www.gnu.org/proprietary/proprietary.html

A lot of it ties into theories around power dynamics as well. When you deny someone the freedom to see what is running on their machine, you put the developer/company in an unfair position of power over the user. We have seen that abused time and again for spying purposes and data collection, for example.

Anyway, interesting stuff. I'll try to come back when I get some time.

> If you disagree, vote with your wallet.

That only works if you have the option to. The vast majority of the time you don't.

Edit: Perhaps I'm being misunderstood? I mean that there very often no equivalent, or even near equivalent option, for you to choose between. As an example, I cannot pay extra for a "smart" consumer electronic, including car infotainment systems, with no proprietary bits and with access to the source.

Even "smart" phones which can have their bootloader's unlocked, which isn't a huge portion, don't provide access to the proprietary bits needed to compile your own AOSP system. However, I'm calling out phones separately as there are a few, nascent nearly fully open source options.

No one is entitled to a business model. If you can't exist without being ethically sound, then you can't exist - period. Capitalism is not a replacement for ethics.

And in any case: you can sell open-source software.

Nobody is entitled to my labor either.

Correct. But we are entitled to the source code for programs which run on our computers, or is paid for by our taxes.

> Correct. But we are entitled to the source code for programs which run on our computers, ...

No you're not. If you want the source code for the programs to run on your computer either write them yourself, choose FOSS ones, or pay someone to write one that supplies the source.

Nobody is mandating you buy a particular piece of software or run it on your computer. You're choosing to do it. If you decide you're not going to run closed source software that's your personal choice.

> ... or is paid for by our taxes.

That's moving goal posts.

Haha, I know that Sourcehut is open-source and you derive revenue from the fact that people prefer to use it as a SaaS product, but it is amusing that the SaaS-ness of it means that your statement only applies to the front-end portion.

The SourceHut backend is also open source. A related idea is "if you're handling my data, I'm entitled to view the code which is doing so".

Right, right, I know. It's just the style of what you said was amusing, not your actual practice, which is consistent.

Why are we entitled to it?

And in any case: you can sell open-source software.

Do you do that?


That's interesting, I could only see services on your web site. What software do you sell?

No one is entitled to free software and should not expect others to slave off and give away fruits of their hard work for free. This entitled communist mentality is unethical.

It's my computer, not yours. If you want to run software on it, I get to see the source code, that's the deal. We could agree that I can't use your software under these terms, but this would exploit those who don't understand the value of the source code. This is how spyware is born. If it runs on my machine, it's open source, or it's bunk.

And, once again, you can sell open source software.

If it's sandboxed and accesses only the resources (network, disk etc.) you explicitly allow it to, you don't need to know how the processing is done. Spyware is not born out of legally obtained closed-source software. It's born out of corporations selling centralized SaaS, infringing on users' privacy and locking them in by design. The very same corporations championing OSS big time, because it benefits their spyware business. With thousands of naive contributors slaving off for posterity and hope that they will get noticed and hired. How ethical is that?

Granted, if you sign an NDA and pay extra, you may have the source. If this is the model you suggest, I think it's fair.

Software that can't access my resources is usually not going to be very useful. If it does get access, I have to trust it with my data, so it needs to be trustworthy. Sandboxing doesn't solve the problem.

If two people, in full understanding of the value of source code, both decide for one to provide a proprietary closed-source software and the other to run it in exchange for money - is it still unethical?

I don't understand your question.

Maybe I'm misunderstanding your point then. I got from your posts roughly: It is unethical for end-user software to be closed source, everyone is fundamentally entitled to the source code for programs they run on their computer. Further, if an end-user decides not to run the closed-source software, it is still unethical because many people don't understand the value of source code and they are still being exploited when they purchase/run the software.

My question: Is it still unethical if the exchange and use of proprietary software is made only between people who fully understand the value of source code and decide to anyway?

It's a potentially unethical situation at the very least.

If the person running that software asks for the source code, it would be unethical to withhold it from them. However, from the arrangement you made, it would also be unethical for the person to exercise that entitlement which they previously agreed to give up. Two unethical actions don't make a right, so you're just setting yourself up for an unethical situation all around. Better to just make it clear the source code's available on request from the beginning.

If I choose to make software and publish binaries on a website without the source, how is that action unethical?

Does it become unethical if somebody downloads and runs it? Or only if I suggest it might be worth downloading and running? Or if I ask for money in exchange for it?

One problem with this maxim is that all nefarious code would also be open-sourced. Would you really want every subversive tool also openly available? One could argue that the inner workings of a car engine or music box are "closed source," yet there is no imperative on releasing detailed schematics with every unit.

> One problem with this maxim is that all nefarious code would also be open-sourced. Would you really want every subversive tool also openly available?

Yes, of course. Every last one of them. That will make such tools more usable by people who actually need them, and more understandable by those defending against them.

> One could argue that the inner workings of a car engine or music box are "closed source," yet there is no imperative on releasing detailed schematics with every unit.

If everyone could carry around a machinists shop and universal manufacturing facility they way they can carry around a laptop, there'd be a lot more demand for such schematics. (And there is already such demand among groups of hobbyists and enthusiasts in those areas.)

The only way to enforce such a scheme is fascism -- immediately negating all freedoms won thereby

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact