DEV Community

Cover image for Automatic Termination of Closed Source Licenses
Thorsten Hirsch
Thorsten Hirsch

Posted on

Automatic Termination of Closed Source Licenses

Let's slip into the role of your customer...

The Problem

So you've finally found an app for your business in the app store. It's being developed by an aspiring developer who somehow happens to know exactly what you need. Sure, the app has some rough edges, but after you give him some feedback it gets better and better. You decide to buy the pro version with an annual fee, and you integrate all your workflows in the app. Everything's great!

Some years later your business relies completely on this app, but suddenly you receive a letter from the developer:

Dear customers,

as you might have noticed, there have been no updates for the app in a while. The reason is that I've lost interest, so I've decided to abandon it.

So long, and thank you for the fish!
Your aspiring developer.

Oh shit! You immediately contact him in order to convince him to continue supporting your beloved app. You even throw cash at him, but to no avail. He says he just landed a job at Google, something with AI, and has no interest anymore to solve your worldly problems.

You keep using the (now unsupported) app, but after upgrading your Mac to Catalina it doesn't work anymore. You're afraid you have to close your business.

Open Source to the Rescue!

Enough role-play. Maybe some of us can relate to the developer in this example and say that this customer was crazy to build his business on an app from a single developer. Or maybe some of us think that the developer acts irresponsible and selfish.

We don't have to pick sides, we just have to accept that situations like these happen and useful or even important software gets abandoned. These situations can easily be resolved if the app was open source - the customer can just pay some other developer to migrate the app on Catalina. But not every developer wants to publish his apps under an open source license. Monetarization might indeed be a problem if you cannot rely on making money with support and services alone. But whatever the reasons might be - the developer is the author, and copyright law grants him to choose whatever license he wants. Then the software lives with its license happily ever after. End of the story.

...or maybe not?

Big Business (Contract Law)

The company I work for has licensed a lot of closed source software. Our lawyers address the risk of losing software support with a paragraph like the following one, which is put in all software vendor contracts:

In case of bankruptcy the vendor must provide the source code of the licensed applications in complete and compilable form.

That seems to be a reasonable solution. However I'm not sure if my employer can really exercise this claim. The software might be composed of different parts, for which the vendor might not have the rights to give others the source code.

Anyhow - here we see a customer's effort to get control over the software's source code when the vendor cannot support it anymore.

Comparison to Copyright in Music

Musicians are paid royalties for the songs they've written or performed. This is a perpetual revenue stream that can (and should) last the whole life of an artist in order to prevent him from poverty. In many countries royalties even continue after the author's death - 50 year, 70 years, maybe even 95 years after his death and are being paid to his descendants. But then the exclusive rights of the author ends and the song enters public domain, which is pretty similar to open source.

So music might be timeless, but copyright enforces "open source" after quite some time. The time of course is very, very long, but music is timeless. Software is not.

Enforcing Open Source by Law

I think it's time for a law that enforces the end of a closed source license - a law that automatically enforces its release under an open source license for circumstances that factually end support, e.g. when a software developer loses interest, when a software vendor goes bankrupt, or when a (single) developer dies.

What do you think of such a law?

P.S.: In my article the term "open source" is used synonymously for free software.

Top comments (8)

Collapse
 
mike_hasarms profile image
Mike Healy

No, it's not morally fair to forcibly take someone's property if they're not using it.

Having the discussion with the developer and negotiating for that is reasonable, but not enacting a law to seize it.

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

Actually the moral standpoint is exactly the one on which the idea of enforcing open source on abandoned projects is based on. It's private property ownership that speaks against it.

Collapse
 
captainkuromaru_64 profile image
Captain Kuromaru

Even though I agree it's moral to open up your codebase after you go bust, it's really just taking someone's ownership away. That's like if we took music rights from a musician because they haven't played the music in 10 years and it's not on digital stores.

Collapse
 
dmfay profile image
Dian Fay

I get what you're going for but more important than my opinion of the principle is the fact that any such law would be impossible to implement and enforce. It's not merely unreasonable to expect a vendor going out of business or otherwise divesting from a project to go to the extra length of preparing, releasing, and hosting the source code in perpetuity -- who's going to do all that in the third case you mention? Do we write it into our wills? Am I going to have to pay a penalty on my income taxes if I declare my occupation and can't provide form 1095-D showing proof of dead-programmer insurance which will pay for someone to come to my house and recover my hard drives in the event of my demise?

The problem -- and it is a problem -- is fundamental to the existence of proprietary software itself. It's the whole point, really: your access to my program is contingent on my ability and willingness to grant you access. If I'm unable or unwilling, tough luck. The only way to resolve this outright is to do away with the profit incentive, which is going to take a lot more than just one law.

Collapse
 
captainkuromaru_64 profile image
Captain Kuromaru

The issue with hosting could be solved by archive.org for example. I think I saw some projects being saved there in someone's archivist efforts.

Archive.org could set up a git server to move the code base there and they are pretty big to at least have a chance to outlive others.

The part where you get that code when the owner dies, that's tricky though.

Collapse
 
thorstenhirsch profile image
Thorsten Hirsch

Some years ago I would have agreed - the problem seems hard to solve. But nowadays closed source apps are just private repos hosted on github.com and gitlab.com. Releasing them as open source is as easy as switching the repo type to public and replacing the LICENSE file.

Proving that a (private) repo is abandoned might indeed be a bit more difficult, but a good indicator is when the owner doesn't pay github/gitlab anymore.

Collapse
 
dmfay profile image
Dian Fay

That's not actually the case. Many proprietary codebases are maintained on-premises, with products like GitHub Enterprise, BitBucket Server, or GitLab EE, to say nothing of the many smaller self-hosted solutions. And this is more true the larger the organization, which in turn correlates with the popularity of the proprietary software in question. So the codebases you'd most want to ensure open up at some point are, in fact, the least likely to be covered by a law specifically targeting SCM service providers, who would themselves have to be dragged kicking and screaming into compliance anyway. It's a nonstarter.

Thread Thread
 
thorstenhirsch profile image
Thorsten Hirsch

True, the popularity of closed source might indeed correlate with the size of the company. But the bigger the company, the less likely is that a project gets abandoned - at least without a migration path to another product.

The projects I see the most critical are tiny, e.g. a specialized app for few customers. Big software companies see no profitable case here, so single developers step in and build a product, maybe as a side project. These are the projects that get abandoned.