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.
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.
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.
We shipped a .jar for on-prem installation. Needless to say, anyone who tried to decompile got a hilariously confusing set of Java code. :)
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).
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.
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.
I think "open-source intelligence"  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'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.
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.
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.
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.
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.
> 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.
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.
If you disagree, vote with your wallet.
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)?
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.
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:
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.
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.
And in any case: you can sell open-source software.
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.
Do you do that?
And, once again, you can sell open source software.
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.
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?
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.
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?
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.)