I have a repository (GPLv3) full of configuration files that I recently noticed uses some FDL code (FDLv1.3). I have the following questions:

To resolve this issue and keep the code:

  • Could I re-license the repo as MIT or BSD?
  • Is there a variant of the FDL I could convince the authors of that code to use that would be compatible? How about licensing documentation and inline code with different licenses?

To resolve this issue by removing the FDL code:

  • Is a Git commit acceptable? Do I need to remove the code from the git history as well?
  • What if my code is "inspired", but not a direct copy of the FDL code?
  • What if the FDL code has since changed, but you can see if by looking through the documentation's history. Can I leave it in, in that case?
  • 1
    What do you mean by FDL code? In this context FDL normally means "free documentation license," which is a type of license for documentation. It is not for source code.
    – Brandin
    Oct 2 '18 at 5:26
  • "How about licensing documentation and inline code with different licenses?" - Could you explain what you mean by this? Documentation and source code are normally separate files. Sometimes there is developer documentation included as inline comments. Are you talking about licensing such documentation comments under a different license than the source code itself?
    – Brandin
    Oct 2 '18 at 5:28
  • @Brandin: gnu.org/licenses/fdl.html. I've seen some sites say "posts licensed under CC-BY-SA, code licensed under CC0", or something similar.
    – user289371
    Oct 2 '18 at 16:39

Neither the GPL nor the FLD allow you to relicense the covered works under MIT or BSD. You have to keep the respective licenses. Furthermore, the FDL allows no relicensing at all (aside from a historic clause that was only usable by Wikipedia). In particular, you cannot relicense FDL works as GPL. Because of this incompatibility, the FDL encourages but does not enforce included code samples to be dual-licensed.

You can always perform any relicensing if all copyright holders of that work agree to the relicensing. This tends to be impractical as copyright holders may be unknown, unreachable, or even dead.

It is not a problem if a repository contains works side by side that are subject to different licenses, as long as they do not form a single combined work. For distributing the repository, you will have to comply with all licenses independently. Fortunately, verbatim copies of the source forms are allowed by all open source licenses incl. GPL and FDL:

2. Verbatim Copying

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License.

For that reason, you also don't have to purge any trace of FDL code from the Git history if you remove that code. The Git history will still include FDL-licensed parts, but this doesn't affect the up to date works in the repository.

However, if you changed the FDL licensed works, you must only do so in compliance with the license. For example, you must amend or add a “History” section with “an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page”.

  • Thanks so much for your comment! You could go the other way though, right? Including MIT code in a GPL project?
    – user289371
    Oct 2 '18 at 17:10
  • Yes, sure. License compatibility is often a one-way street, so while you can't use GPL code in MIT projects, you can include MIT code in GPL projects. But you still have to comply with the MIT license, i.e. keep the copyright notice and MIT license notice intact.
    – amon
    Oct 2 '18 at 17:16

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.