Live data from Hacker News

Show HN: Add license key verification to your apps

github.com

11–20 of 95 posts

Re: Show HN: Add license key verification to your apps

#11
post #10
post #9

It is unethical for end-user software to be closed source, and this project is wrong for enabling this.

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.

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.

Re: Show HN: Add license key verification to your apps

#13
post #10
post #9

It is unethical for end-user software to be closed source, and this project is wrong for enabling this.

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.

> 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.

Re: Show HN: Add license key verification to your apps

#14
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.

Re: Show HN: Add license key verification to your apps

#15

Why MongoDB?

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.

Re: Show HN: Add license key verification to your apps

#16
post #9

It is unethical for end-user software to be closed source, and this project is wrong for enabling this.

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.

Re: Show HN: Add license key verification to your apps

#17
post #10

Earlier quoted context omitted.

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.

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.

Re: Show HN: Add license key verification to your apps

#19
post #9

It is unethical for end-user software to be closed source, and this project is wrong for enabling this.

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.

Re: Show HN: Add license key verification to your apps

#20
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.

Post reply on HN