8

My company is looking to develop and release an open source software project along with a proprietary enhanced version, similar to pre-4.0 VirtualBox.

What is the best way to maintain the two code bases such that changes to the open source version can easily be incorporated into the commercial version with minimal risk of accidentally pushing proprietary code to the open source product?

Oded
  • 53,326
  • 19
  • 166
  • 181
rkjnsn
  • 181
  • 1

3 Answers3

9

I would create 2 projects.

  1. OSS Project which can run standalone.
  2. Proprietary code which depends on the OSS project code.

You can have the dependency be a build time or run time dependency. If you want each package to be standalone, then you can have proprietary package pull in the OSS files it needs during build/package creation. If your fine with a run time dependency, you can just package up the proprietary code alone, and have it depend on the OSS package at run time.

Benefits:

  • Frees you from duplicating code.
  • Get bug fixes in both for the cost of getting it in one.
  • Clear delineation between OSS and Proprietary.
dietbuddha
  • 8,677
  • 24
  • 36
  • 1
    +2: If possible, make the proprietary functions plugins. People's experience with the OSS version will whet their appetite and they can directly buy/install the new functions while running the app. You can even set it up so that each proprietary plugin has an X day trial period. This not only solves your codebase management problem, it makes for *easy* marketing. – Peter Rowell Sep 19 '11 at 22:48
1

Source Control & Branching

The root would be the code common to the both distributions. You would also (presumably) create two branches from your root:

Open Source

Closed Source

Open Source would probably mirror your root in this scenario. On a regular basis, you would merge Open Source and Closed Source by hand (Closed Source would likely not get as many updates).

This way, you can keep the enhancements in your Closed Source branch, and pull in new changes from the Open Source version.

Craige
  • 3,791
  • 21
  • 30
  • Is there a way to do this using separate repositories? We are hoping to have the repository containing the open source code publicly visible. – rkjnsn Sep 20 '11 at 20:42
0

Depends on the open source license which isn't stated in the question. GPL gives the most problems in this regard and any static link or runtime link is suspect.

Read the FAQ for best results; don't trust other answers. Using plugins is not truly legit. Many commercial products violate the GPL in different ways & basically look the other way.

http://www.gnu.org/licenses/gpl-faq.html

If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in? It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them.

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

Jonathan Cline IEEE
  • 906
  • 6
  • 8
  • If you hold the copyright to the GPL software, then you can distribute closed-source plugins yourself - the original copyright holder is the one who sets the license rules and is certainly not bound by the license. On the other hand, it does mean that 1) you can't accept GPL contributions without requiring a copyright assignment to you, and 2) that others cannot distribute the plugins with the GPL software. – han Sep 20 '11 at 05:48
  • Why would you trust the FAQ over other sources? It's coming from perhaps the very most biased source conceivable. And if I place my work under the GPL, it doesn't matter if the FSF says the GPL says you can do X. If the law and the license say you can't, **I** can still sue you and I will still win. – David Schwartz Sep 20 '11 at 09:20
  • "Why would you trust the FAQ over other sources?" Because the FAQ is based on real world prior cases, not on arm chair hypothesis from stack exchange blog writers whose technical reputations are only visible mostly by points awarded by popularity rather than by correctness. – Jonathan Cline IEEE Sep 20 '11 at 16:41
  • We have not picked a license for the open source version yet. We do have the copyright on all of the code, so releasing it under two separate licenses shouldn't be an issue. – rkjnsn Sep 20 '11 at 20:50
  • If you have not picked a license then you are much better off using a BSD-based license rather than a viral one (viral = meaning GPL-based). Many products successfully use netbsd embedded in a server product with proprietary code (the value added parts) directly integrated into the tree. Although as another author indicates, you can release using a dual license.. that may just be confusing to sales & mkting though. Perhaps a successful example for reference is Apple Darwin ("Apple Public Source License", now Apache license): http://en.wikipedia.org/wiki/Darwin_(operating_system)#License – Jonathan Cline IEEE Sep 20 '11 at 22:24