Say a company wants to keep development of new features of a piece of software internal, but wants to make the source code for previous versions public, up to and including existing public features, so that other people can benefit from using and modifying the software themselves, and even possibly contribute changes that can be applied to the development branch.

Is there a term for this sort of arrangement, and what is the best way of accomplishing it using existing version control tools and platforms?

  • 1
    open innovation! Apr 3, 2012 at 22:01
  • It's kind of an uncommon structure, and I've never heard a proper name for it. This sort of thing was more common when small-scale paid software was more common, and you could often get the source to the version that the developer didn't care about anymore. Apr 3, 2012 at 23:48
  • 1
  • This sounds a lot like the "Business Source" license (time-delayed open source) and some of the other options mentioned at "Awesome Paid Open Source".
    – David Cary
    Feb 7, 2019 at 21:24

6 Answers 6


I don't know the name but for implementation following setup might work:

Create two repos on github (replace with any other platform doing the same), one public, one private. Keep latest version X in private one, and v.X-1 on public one. When releasing new version, update public one from private one. This way you will be able to easily use version control, and also allow users of public repo send you their contributions via pull requests, and then be able to merge it to you private repo, submit issues, etc. This also will give you the options to allow paid users to do the same for your private code - give them either read-only or even read-write access.


It sounds like Shared Source which is a term used by Microsoft to describe the way they allow customers to get a copy of their source code for reasons like security auditing or reference. Microsoft retains full control of the codebase for new development.

The licenses associated with the offerings range from being closed-source, allowing only viewing of the code for reference, to allowing it to be modified and redistributed for both commercial and non-commercial purposes.

  • This is almost exactly what I was looking for, although I wish there was a specific term for this arrangement when the code is released under an open-source license. Since my question unfortunately had two parts and StasM had a very nice answer for the other one, I'm still debating which to accept.
    – mwhite
    Apr 5, 2012 at 2:47

I don't know of a term for this.

Perhaps it should the called the Padlocked Barn Door model. Instead of "shutting the barn door after the horse has bolted" (i.e. attempting to regain exclusivity after releasing software under a too-liberal license), you padlock the barn door and hope that the horse doesn't die of starvation in the stable. :-)

Seriously though, if the company management thinks that this is needed to make a buck from open source, you can't really argue. After all, they are responsible for managing the resource investment they are making.

However this is not a model that is good for the paying customer. (If the customer can't get source code for the premium version he / she is running, what it the point of paying the premium?) It is not likely to encourage contributions from the user community, and is going to make those contributions of less value ... because they will always be against an old version of the codebase. Indeed, you could argue that it is more likely to encourage forking.


This pattern is actually quite frequent in the industry. One example is when a product is available as a community edition and an enterprise edition. Typically, the community edition is available at no cost and can even be free/open source software and usually lacks some features marketed as being only needed by enterprise users. The enterprise edition is usually available by purchasing a commercial license and can be optionally bundled with a support package, integrated software updates, more features or more permissive usage conditions. This pattern can be seen in many forms and variations in the market. One example is the Eclipse platform vs the commercial products based on it such as IBM Lotus client. Another example is the inception of what is now known as Mozilla Firefox, which started as Netscape Browser vs Mozilla Browser. And the list can continue.

Another approach is to separate the product in two separate standalone products. This is suitable for big projects that are composed by many smaller sub-projects. One example is Fedora Linux vs Red Hat Enterprise Linux or OpenSuse vs Suse Linux Enterprise editions.


I believe the term is dual-licensing. (or multi-licensing)

The portion of the project you want people to dink around with you release under, say, the LGPL which lets it call proprietary material. The port of the project you want to keep under your thumb is a proprietary for-sale software.


If all the code is owned by you, then you can relicence as you see fit. If anyone else has contributed into the code you want to close source, then you MUST get their permission or get them to sign copyright over to you. As for a name, I don;t know of a standard, maybe dual licencing? I think MySQL is in the same position, and maybe QT?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.