4

Consider an existing project that is dual-licensed GPL + either MIT or BSD.

Since it's dual-licensed, when I fork, can I pick one license in the fork? Or do my forked files need to continue to be dual-licensed?

It sure would be simpler to track only one license.

|improve this question
  • You can even pick a license that is compatible with one of the two. I.e. you could fork a BSD / LGPL work and distribute it under just the GPL terms. – MSalters Jan 2 '13 at 16:32
3

If, and only if, the project is truly dual licensed then you may pick your preferred license and fork from there. But you must make sure that all aspects of the code that you need are licensed in your preferred license. You are allowed to carve apart a project to 'cherry pick' just the aspects you need or are compatible with your preferred license.

Think of the dual-licensing as trim lines on an automobile. Presuming you can only afford one vehicle, you pick one trim line and you drive that off the lot. (Aka, you forked the project.) The vehicle still runs; everything is fine; you have a single license now.

It's probable that trim line A has some features that you really want, but you can only 'afford' trim line B. That's when you rely upon the auto parts after-market and other mechanics to install the features you wanted from A but couldn't 'afford'. And if you're a truly handy DIY'er, you can make those modifications yourself. Those new features that you built / paid for are now part of trim line B or however you choose to release / license them (this is where the auto analogy falls apart).

Some quick caveats -
1) I use the term 'afford' to make the automobile analogy work. It's a metaphor, that's all.
2) The license you pick may affect how you can release new features. Using GPL, for example, would force the new features to be GPL'd.

|improve this answer
4

Note, I am not a lawyer.

When a project is dual-licensed it means that you can choose to license the work from the author under either one of the licenses. You are only bound by the one you pick—that is the whole point of dual licensing (though I don't understand the point of dual-licensing under the GPL and a permissive license). The original code may still be distributed under both licenses by the author, but there is no requirement for you to do such a thing.

|improve this answer
  • If you're saying what I think you're saying, you're wrong. You can use code licensed under a permissive license with code licensed under any other license. If you include, say, MIT licensed code in your project you do not have to distribute your own code under the MIT license. This is the fundamental difference between copyleft licenses and non-copyleft (but still free/open source) licenses. Dual-licensing your project under, say, the GPL and the MIT license effectively nullifies the GPL and makes the MIT license the real (and only) license the project is available under. – cgt Jan 2 '13 at 9:46
  • Continued: Usually, dual-licensing is done when you want to allow people to choose between different sets of restrictions, each with their own pros and cons (e.g., the GPL and a commercial license allowing proprietary usage), or if your preferred license is incompatible with a major free/open source license, as was the case with the 1.x versions of the Mozilla Public License, which was incompatible with the GPLs (Firefox and other Mozilla software was triple licensed before MPL 2.0—MPL 1.x, GPL, and LGPL). – cgt Jan 2 '13 at 9:50
  • Note: The comments I wrote here were written in reply to another comment, which appears to have been removed. – cgt Jan 2 '13 at 23:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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