I am working on a prototype for a software system, which (at least at the start) will be closed source.

In order to save time, I'm thinking of using (that is, statically linking) a library that is licensed under GPLv3, so I can test my design quickly. If I distributed the software at this stage, I'd have to distribute source code along with it.

What if I don't, but satisfy myself that my system works, and then replace the GPL library with my own code before distributing? Would the result be "contaminated" by the GPL?

I have a feeling that retaining the GPL library in my Git history or not may make a difference.

  • 16
    I like the expression "contaminated by the GPL". Mar 7, 2015 at 13:56
  • 7
    it goes well with the viral nature of the license :)
    – Laurent S
    Mar 7, 2015 at 14:21
  • 5
    Correct me if im wrong, but you want to release a closed-source system, while simultaneously hosting the code on git? (and I presume this git is readable by others, as otherwise why would you worry about having a GPL lib in the history?) Mar 7, 2015 at 15:39
  • 3
    @user2813274, you can have a private Git repository. Mar 7, 2015 at 18:12
  • 5
    When you find this question interesting, you might also be interested in the proposal for the new Open Source Stackexchange.
    – Philipp
    Mar 7, 2015 at 22:06

7 Answers 7


The GPL writes:

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

So this condition only applies if your work is "based on" the library, which the licence defines as follows:

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

That is, your program is "based on" the library if and only if it is a derivative work according to copyright law. The legal definition of that term varies somewhat among jurisdictions, and usually does not directly address software. For instance, the US Copyright Act writes:

A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a “derivative work”.

What this means for software must be interpreted by the courts, based on earlier similar rulings. I am not sufficiently familiar with the relevant case law in your jurisdiction to say with certainty how a court would decide your case. One could argue that "replacing the GPL library with own code" is an act of translation, particularly if your code is strongly inspired by the GPL implementation. Even reusing the API of the GPL library could land you in hot water (see Oracle vs. Google).

If the answer matters to you, I recommend seeking competent legal advice rather than asking strangers on the internet.

  • 1
    ok, this is interesting, I didn't realise that sharing an API could be considered a derivative work.
    – Laurent S
    Mar 8, 2015 at 0:17
  • This answer makes the same point i was trying to make in my answer below, but in a much clearer way. +1 Mar 8, 2015 at 13:08

As long as you don't release the software to anyone while you are linking to GPL'd libraries, you are safe. The viral aspect of GPL only kicks in if you distribute your software.

It would be better if you could find a library with a more permissive licence, of course, like LGPL or APL2 or MIT.

  • Clearly, I'll try to find another library with a permissive license. But failing that, it sounds like I could have old GPL code in the git history, and not break the terms of it, by distributing the future state of the code.
    – Laurent S
    Mar 7, 2015 at 14:36
  • 5
    This answer does not taking into consideration the risk of creating a derived work when implementing the new version of the library. Mar 7, 2015 at 18:18
  • 4
    @Ptolemy Keep in mind that if your git history is released, you have released the old version. It does not have to be in binary form to count.
    – piojo
    Mar 7, 2015 at 19:03
  • 2
    @piojo On the other hand, that at most obligates you to license that old version under GPL (and distribute source for it); if at some point you find yourself with the sole copyright to the code, you can make all future versions closed-source (although the old versions continue to be under the GPL). Depending on how much proprietary stuff is in the old version, you may or may not have a problem.
    – cpast
    Mar 7, 2015 at 23:21
  • 1
    As long as Laurent S is the author and copyright owner of all the other code next to the GPL he is safe, too. He can and is allowed to release the whole work under the terms of GPL3 just in case this might be the outcome later on. This might be unwanted, but OP clearly is safe in any case (if copyright is owned).
    – hakre
    Mar 7, 2015 at 23:26

I don't think your question is actually about the GPL. It's about the prototype and whether it will be used in the future as the basis for the deliverable software system.

If you're making a throwaway prototype and you are not going to reuse any of the code in your deliverable system, then go ahead and use a GPL library.

Three Approaches You Can Take

However, if you're going to evolve the prototype (something lots of managers push for!) you have three approaches you can take:

  1. Move the non-core parts into separate applications that communicate with your core over JSON or a REST API or some other Inter-Process Communication language/library. Your non-core parts thus can be GPL as well and you can use any GPL libraries in them.
  2. Design your code so that you can swap the libraries out. This means creating a facade that hides the implementation details. When you're ready to switch to a proprietary library or MIT/BSD library.
  3. Don't use the GPL'd code at all.

I suggest you go with the first approach because then you have open source work that you can use in the future as part of your professional portfolio.

The second approach is also good because that's how you should be designing the system anyway, creating the exact functions/classes you need and stubbing them out until you have the library or custom code that fills in that functionality.

  • 2
    Putting the GPL code into another process does not per-se mean it's no longer part of the program, and thus no longer relevant for licensing the rest. It can help separating them good enough though. Mar 7, 2015 at 16:10
  • 1
    @Deduplicator if they're separate applications that's not enough, they have to be treated as a separate code base, you're right. Kinda like what Twitter does with Bootstrap and what Facebook does with all its libraries. Non-core open source with core proprietary code.
    – user7433
    Mar 7, 2015 at 16:43
  • @omouse, I can't do 1, since it's embedded software. 2 was my first thought, but seeing what Ptolemy and meriton mention, it sounds like I'd be making derivative works, so 3 is probably the way to go.
    – Laurent S
    Mar 8, 2015 at 0:15
  • 1
    Re: "I don't think your question is actually about the GPL": I disagree. A software license certainly could forbid this sort of use. An answer that ignored the "GPL" part of the question, and just took it as a general question about an open-source license with restrictive terms and viral behavior, would have to resort to "we don't know, you'll have to read the terms of the license".
    – ruakh
    Mar 8, 2015 at 5:51
  • If you create a derivative work, and throw it away, you still have created a derivative work and you may only do that with permission / license of the original copyright holder. With GPL you have that license (if you never distribute the derivative work before throwing it away). With other license, you may not have the permission. Suing you for damages might be difficult though.
    – gnasher729
    Mar 9, 2015 at 0:26

I can think of two aspects to consider with your approach. The first is straightforward, by not distributing your project or (or as it's GPLv3, making it available for public use) whilst you are using code that is released under the GPL, it is hard to see how you would be required to distribute your code under the GPL license too under the redistribution terms.

The second aspect is possibly more significant to you. When you create your own implementation to replace the GPL library, you need to be careful not to create an derivative work. Whilst I am sure you have good intentions, on not directly copying source code - you are more likely than not going to copy significant portions of the library API.

If this is a commercial product, this risk needs to be considered and assessed by reading through the GPLv3 license carefully, and where there is doubt, asking for a professional legal opinion.


If you are planning to write your own code to replace the GPL code you will have a potential problem because you are not writing the code in a clean room environment. You would really want to have someone who has never looked at the GPL code write any replacement library. On the other hand if you want to simply swap out a GPL library for an already published library that is under another license then this is not a problem, the other library was presumably already written in a clean room environment.


If you provide access to the revisions using the GPL'd code, they will be completely GPL'd. But you don't want to, as that wouldn't be closed-source...

For any later state which no longer uses any GPL'd code, that you used GPL-code sometime earlier is simply irrelevant.


The GPL is only triggered on distribution... you can do whatever you want if you don't release a modified version or derivative work.

I have a feeling that retaining the GPL library in my Git history or not may make a difference.

If you mean publishing your source to a public repository like GitHub, then yes, you may have an issue. Just using git is irrelevant if it's private.

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