
Ask HN: Open-source commitment for commercial software? - davidbanham
Hi HN,<p>I write a bunch of open source software. I also make and sell closed source products. I&#x27;m a small shop and sometimes my clients worry about platform risk should I just decide it&#x27;s no longer worth bothering to support the product I&#x27;m trying to sell them.<p>What I&#x27;d like to be able to do is put a clause in my standard EULA that says &quot;If I ever stop offering this software on the market, I promise I&#x27;ll give you the source under a BSD licence.&quot;<p>Is anyone aware of prior art in this space? I&#x27;d love to learn from history before trying it myself.
======
blihp
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.

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

~~~
blihp
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'

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

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

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

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

------
mherrmann
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](https://fman.io/blog/transparency/#open-source-promise)

~~~
danieldk
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?

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

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

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

[https://www.opendesign.com](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](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.

------
boyter
I am doing this with searchcode server [https://github.com/boyter/searchcode-
server](https://github.com/boyter/searchcode-server) which I wrote about here
[https://boyter.org/2016/08/gpl-time-bomb-interesting-
approac...](https://boyter.org/2016/08/gpl-time-bomb-interesting-approach-
foss-licensing/) 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](https://news.ycombinator.com/item?id=12459492)
from the post at the time and have actioned on a lot of the feedback.

------
bradrydzewski
See section 4.4
[https://drone.io/enterprise/license/](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).

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

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

How so?

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

~~~
abeyer
> 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?

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

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

~~~
richharms
-

~~~
keyle
I wish you edited that with '42'.

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

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

------
tyingq
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](https://bitcannery.net/overview)

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

------
majewsky
Here is a precedent that has been going on for ~20 years now:
[https://www.kde.org/community/whatiskde/kdefreeqtfoundation....](https://www.kde.org/community/whatiskde/kdefreeqtfoundation.php)

~~~
emilsedgh
This is the true example of this happening.

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

Qt is still Free and Open Source under LGPL.

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

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

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

