Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Until they go out of business and you're fucked. That's when you wish you'd stuck with Postgres.


Being closed for free doesn't mean it isn't open source for those that pay.

This was a common model before FOSS took off and it is still quite common in enterprise products.

If company X goes out of business you get the latest source version you paid for.

Having said this, I don't know if Cognitec has such kind of contracts.


Going off topic here, but we have an enterprise lead for our SaaS product who is asking the same. They want some sort of warranty that they can keep hosting the product themselves, should we go bust. Going open source (or open core) is currently not an option for us.

Does anyone have any advice how to approach this? Example contracts, good experiences with escrow services maybe? Or bad experiences of course.


I worked for a company which sold hosted services in the financial sector. Escrow was a standard part of contracts. However, it wasn't taken immensely seriously; we faithfully put all of our source code into escrow once a year (or perhaps more often, but not as often as we released), but not all of the build, deployment, and infrastructure tools and config you would actually need to turn that code into a replica of the application. We didn't make any effort to "restore from backup" to verify that what was in escrow was actually any use. Customers, and their auditors, seemed happy with that.

I do feel that in a really well-run operation, your build, deploy, and operation should be so automated that that's just another set of repositories to put in escrow. One way to look at it is that escrow is just another kind of disaster recovery; if you have safe copies of everything you would need to restore your operations if you lost all your current servers, then it's easy to put those in escrow too.


It's more meaningful for a shrink wrap software. It's easy to archive and handover the code repo, packages and documentation.

It's not really effective for saving a cloud hosting. A platform like that is not easily redeployable.


Thanks. Do you know what escrow service that was?


It's difficult to do for SaaS since you're not already packaging up the product.

Datomic has perpetual free licenses so if they go bankrupt, you just keep the software you already have.

If you had an on-prem setup or a hosted white label solution, then it'd be easier to license.


> Being closed for free doesn't mean it isn't open source for those that pay.

True, but...

> This was a common model before FOSS took off and it is still quite common in enterprise products.

No, it wasn't and it's not. “Shared source” for paying customers was common before Free/Open Source Software (FOSS) took off (“Free” doesn't modify “Open Source”, they are essentially synonyms that identify the same license features but which are preferred by different ideological factions that prefer those features for different reasons.) Shared source does include access to the source, and it may include some rights to create derivatives (usually with no or restricted distribution rights), but it is not open source.


Who cares about the religious meanings? What matters is having access to the code, whatever form it might be.

Also no one ever referred to it as "Shared Source" in the 80's.

Just to dig out one such product, here is the brochure of Turbo Pascal 5.5 from 1989.

https://archive.org/stream/bitsavers_borlandtur5.5Brochure19...

" Turbo Pascal 5.5 Runtime Library Source

Modify the runtime library source code or use it as it is. You get the assembly language and Pascal source code to the System, Dos, Crt, Printer and Turbo3 units. It comes with a batch file to help with recompiling and building TURBO.TPL."

For me, for my work, that was open enough.


> Who cares about the religious meanings?

It's no religion; the terms have well-established meanings.

> What matters is having access to the code, whatever form it might be.

The legal permissions you have to make use of the code very much matter, too. And those vary considerably among non-Open Source, source available/shared source license arrangements.


Source code escrow is standard for this sort of vendor contract.


The same can happen with every system, and the fact it is OSS won't help you much on practice. E.g. sqlite is signing >10 year contracts with some of their commercial clients which guarantee at least some level of professional support. Many clients won't even touch your software, regardless it is OSS or not, unless you can provide such kind of involvement.


Or until they get bought up and shut their doors. Now where have I seen that one... :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: