Ask HN: Open-source commitment for commercial software? | Hacker News Reader

Ask HN: Open-source commitment for commercial software?

91 pointsdavidbanham45 comments

Hi HN,

I write a bunch of open source software. I also make and sell closed source products. I'm a small shop and sometimes my clients worry about platform risk should I just decide it's no longer worth bothering to support the product I'm trying to sell them.

What I'd like to be able to do is put a clause in my standard EULA that says "If I ever stop offering this software on the market, I promise I'll give you the source under a BSD licence."

Is anyone aware of prior art in this space? I'd love to learn from history before trying it myself.

View on HN

There are a few others doing it, but I think it's a terrible idea. There's a lesson to be learned from the insurance industry on this one. You'd essentially be providing an insurance policy to your customers (i.e. the payout is source code to your application) when they have no insurable interest (i.e. the success of your business.) What this means is that they can benefit from your failure while having no actual interest in seeing you succeed. Perversely, if one of them wants the source code, then they do have an interest in seeing you fail. They may not try to kill your business directly, but it can actually be against their interest to supply you with more business which would keep it worth your while / viable.

Instead, I'd suggest thinking about their concerns and come up with a mutually beneficial way to address them. If they're worried about you walking away from it, offer them a long term support arrangement with some legal teeth where there's enough $$$ involved to guarantee your continued engagement. Bus factor... meh, you're a one-person shop... if they want to mitigate that risk, have them pony up some money and you'll be happy to staff up. etc. etc.

This is an interesting point that had not occurred to me. However one could argue that customers "benefit[ing] from your failure" is not the case.

Typically a customer buys software because they lack (or are not willing to provide) the internal capacity to buy and evolve the software themselves. If the software producer fails, this will slow-down or kill software evolution, bug fixes, production of documentation etc, thus hurting the customer. As but one data point, consider Windows XP, which is still in widespread usage as of October 2018.

Avoiding this scenario is the customer's interest in the producer's continued success.

For small businesses, sure. But don't underestimate how perverse big businesses can be. If you have the expertise they want (even better: expertise in code form), and some off-shore body shop has the cheap labor they want... hey, let's kill off the vendor, get the source code and ship it over to XYZ coders to cut our support costs.

General Motors and General Magic is an example of a large company that didn't fight too hard to keep a smaller company afloat once they put up their IP: https://www.nytimes.com/2002/09/19/business/technology-brief... (iirc, the other vendor was EDS which General Motors had an interesting relationship with at the time)

Counterpoint: Many companies really want to, but cannot use, some great opensource projects just because they lack serious* commercial backing.

So I agree with the sibling on this one.

We did a deal like this with a giant IT company with a 3 letter acronym for a name.

We had a "break glass" option. If the client wanted to take over the code, they had to pay us a prearranged amount. The actual amount in our case was about 2 x the lifetime revenue to us of the deal from memory.

This seemed to work well, they had insurance, but we knew that if they ever broke the glass we'd be laughing to the bank.

At one stage things got tetchy and we hoped they would break the glass - but they never did.

Something along these lines makes much more sense: the other party got the insurance they want, your company got a non-trivial payment in the event that they walk away against the customer's wishes. Both parties have incentive to make things work. That's very different than 'if we ever stop offering this product, we'll just open source it'

I think it works well for megacorp clients too. A future option for a few million dollars is way easier for them to get over the line than some strange, and intangible open source scenario, when they don't want the code ever open sourced anyway.

I was a founder at a company that faced this problem: small company, in Australia; big company clients, mostly on other side of the planet.

We added a source-code escrow clause to our contracts, and (the much bigger and more difficult part of the commitment) a bunch of steps to our release process.

Escrow is not just the source code: we had to include full instructions for building the software, lists of dependencies and their versions, etc, etc. With modern CI and declarative DevOps, this would be a lot simpler.

We originally just arranged this with our local Intellectual Property lawyer, who (to my surprise) was pretty well set up for this. For instance, one time we accidentally failed to include some files, and they noticed and called us to get the drop resent.

We were later forced to move to using Iron Mountain by a large client who wasn't happy within anyone else.

When we later discontinued that product (due to pivoting to a more specific market niche) one customer took advantage of their escrow rights to continue to build and maintain the software in house for many years.

From memory, we didn't try to enumerate the circumstances under which the escrow would be triggered too much: just saying something like "becomes unsupported". If it's really necessary, lawyers can sort out whether that's the case or not.

Doesn't cover 'hit by a bus' scenario.

Worse, like escrow, there's no guarantee (or likelihood) that it will be in a state maintainable by the client (or by anyone).

Here's my idea: clubsource, opensource within the exclusive club of customers. They all get source, and are allowed to modify and freely share source with each other - but only with each other. It's not open source. If they did want to share it (e.g. with a trade-partner or subsiduary etc), they need a new license from you. i.e open source, within a club.

The benefit is that they have access to source, now; they can assess it; they can build expertise in maintaining it; they can customize it. And most important for you, they can band together in these endeavours, to either share the load, or for those clients most capable to maintain it (probably for consideration; consultants could also take on this role, by being licensed).

The big benefit for you (apart from overcoming this objection), is it can keep improving and producing sales without you (though people will resent this, unless you make it sufficiently-cheap at that point).

The downside for you is you can't screw them for updates or features or maintenance like an Oracle. And someone could easily copy it directly, or "reverse-engineer" it, and you couldn't really trace it.

This reminds me of the situation with regards to the unreal engine source code. It’s “open”, you can browse and contribute, but only after you agree to the terms which include agreeing to pay them when the time comes that you make money with it. The club in this case is everyone who agreed to their contractual terms.

I give the following promise [1] for my file manager:

If no commit is made to fman in more than 6 months, then it will be open sourced under a BSD license.

Commits are displayed live on the home page, so people can actually hold me to that promise.

1: https://fman.io/blog/transparency/#open-source-promise

It's a bit artificial though, as a metric, you could just do a trivial commit twice a year to keep your "promise".

Great looking file manager will give it a bash next time I'm on my mac :-)

Sure, but at the end of the day, nobody will take me to court over it. And I could game it however it is phrased. The only reason why fman's development would seize is if it weren't making enough money. (Otherwise, I'd be incentivized to keep working on it, or hire someone to do so.) In that case, I'd have the choice between a) continuing to make very little money, and fman dying or b) open sourcing it to ensure its legacy. I know which one I'd choose.

It's not just for Mac! Works just as well on Windows and Linux too.

I think this is a useful promise for customers.

But what happens when you disappear from the web, after you bought a tropical island ;). How are people going to get the source code? Do you use some escrow mechanism?

As I mention on the page I linked to above, my family (=brother) knows how to release the source code in case I disappear.

It sounds like they are asking for software escrow. Iron Mountain and others offer these services. If required, you should pass the cost on to the client.

I think prior art exists. As a specific example of a business that has solved this problem:

https://www.opendesign.com

ODA offers several licenses of their CAD related data processing tools. The most expensive licence gives direct access to source and the right to compile the source, but strictly controls how that source may be used.

You may want to take a peek at their licenses. The source code is available at the most expensive 'Founding' tier:

https://www.opendesign.com/join

The other alternative is software escrow but I would fathom you could just offer a premium license for full source code access and capture all that additional revenue yourself.

I am doing this with searchcode server https://github.com/boyter/searchcode-server which I wrote about here https://boyter.org/2016/08/gpl-time-bomb-interesting-approac... in short 3 years after a release is published the source at that time is licensed as GPL3. I did it like this to cover the hit by a bus, bored and such scenarios.

I did get some attention here https://news.ycombinator.com/item?id=12459492 from the post at the time and have actioned on a lot of the feedback.

See section 4.4 https://drone.io/enterprise/license/

edit: section 4.4 provides a business discontinuation clause that specifies the source code will be released under an open source license if the business is discontinued. The clause was written by an attorney (not something I added myself).

What caseyf said - this should be covered by software escrow, making an OSS commitment public is dangerous as it can put your IP at risk.

Though software escrow comes with added costs so it’s really down to the individual contract.

> making an OSS commitment public is dangerous as it can put your IP at risk

How so?

You’re staking your IP on the financial health of your company. If you have a promise to push OSS then you also provide motive for sabotage.

It sounds extremely paranoid, I know, but escrow is a much safer option because when you pass that on to the client it forces them to really commit as opposed to not caring if you go bust.

To put it another way: you get a commitment from them in terms of having to pay the fees for escrow, which is more than they would have to do if you made a public promise. That’s a longer term commitment, so you can wrap that into a longer term deal, which in turn can help you stay sustainable for longer.

> It sounds extremely paranoid

Yeah, and a bit like FUD, too.

I'm still unclear how a public release would be any better for said saboteur, compared to code escrow where they could potentially be the sole beneficiary of it. If someone is willing to go to those lengths to get access to your code, do you expect an escrow fee is going to stop them?

Well that's a common risk that clients have to accept, and it's often what pushes them towards larger software consultancies.

The argument is that you may not be there next year and they'd be stuck in a hole with software out of date.

You could offer to commit 4 hrs per week on retainer in the maintenance mode of the software, later down the track. That gives you a retainer and gives them predictable cost. If the required changes are bigger than the allocated time per week (or they want it sooner) you'd have an hourly rate attached with it.

I always try to build relationships that last and not quick in/out software.

Off Topic but your profile has some kind of key and a visual representation (similar to SSH but not quite) What is that?

The Art appears to just be ascii of their uname, but I’m not 100%.

Damnit! You gave away the answer!

I wish you edited that with '42'.

You piqued my curiosity, and I was pleasantly surprised!

I won't post the email address, because I suspect it's encoded like that to prevent spam. But here's two hints:

- the visual representation simply requires you to step back from your monitor and squint

- the "key" is an email address

Hope the hints help! Have fun! There's two classic pieces of Internet technology involved.

Heh. Thanks for playing. I forgot the brainfuck puzzle.

I do wonder how many people know about rot-13 these days. I remember having to use it to get the punchlines for dirty jokes on Usenet :)

Huh. Nice one, 'keyle. My favourite "encryption" scheme :D.

HN to me is about celebrating hackery with things like this :-)

I tried a ROT-24589 algorithm on it, I think I'm really close.

Good thinking. ROT-24596 should get you there!

Add a Clause in your contract that covers 2 scenarios:

1. If YOU go out of business or cannot support the customer for any reason, they get access to the source code with a non-exclusive license.

2. If THEY want to leave (as some others are pointing out in the thread, then they have to buyout the IP for a price. You can either negotiate the price upfront (make it worthwhile for you and high enough that it is not worth for them to do the buyout easily) or leave it open depending on how far along you went with that customer.

That sounds like a lawyer question. IANAL, but I can see it being kind of complicated to try and come up with some clever licensing for customers you're not sure you'd like to support. What I've seen some companies so is make the core product AGPL and then offer a separate commercial license. Take a look at the source code for JFrog's Artifactory; I'm pretty sure they are duel licensed (but I'm on my phone & can't confirm at the moment).

You could roll your own source code escrow with a "canary" where if you don't check in periodically...your client gets the key to decrypt a source tarball (with whatever licensing you want to put in it).

I can't vouch for it, but I found a tool that does this: https://bitcannery.net/overview

As others have mentioned, this is not uncommon at all, it's called software escrow.

For clients that need/want/demand this you can pass the cost onto them.

On your side, you do the work once in your build/CI to upload/FTP source and artifacts to the escrow agent and you're done.

Here is a precedent that has been going on for ~20 years now: https://www.kde.org/community/whatiskde/kdefreeqtfoundation....

This is the true example of this happening.

TrollTech -> Nokia -> Microsoft -> Digia -> Qt Company

Qt is still Free and Open Source under LGPL.

We and i mean i , because i do a lot of solo projects solved it this way. I drop on a regular base my latest sources at a notary, with a list of clients / software. When i might go bankrupt or die, they have access to the sources.

This is largely forgotten now, but notch promised to open source Minecraft if it ever stopped selling.

Obviously it still sells today. He doesn't own it anymore and it's not a proper license like what you're asking. But it's a precedent.

I’ve heard of code being put into escrow for similar reasons. Basically a guarantee because one man shops or even startups might be asking an enterprise to take a risk on them.

Reply on news.ycombinator.com