Show HN: Add license key verification to your apps
github.com
github.com
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.
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.
Weird.
I'm pretty sure the term has been in use since the 1940s
(For years, I knew it as "White Intelligence")
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.
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".
---
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.
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.
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).
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. :)
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.
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.
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.
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 :-)
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!).
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.
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.
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.
Enterprises cannot risk legal problems. And home customers will buy licenses if price is fair.
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...
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).
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.
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.
This is one of the benefits of SaaS (for sellers).
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).
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.
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.
https://github.com/furkansenharputlu/f-license/blob/master/s...