So my team is planning to go open source with a project that has been in development together with an industry partner for some time now. We're not sure about the licensing yet, but GPLv3 looks promising so far. From the GPLv3 FAQ I figured our partner company will be allowed to keep a modified version of the program for internal use that uses their own proprietary code. My question now is, can the company while maintaining the program, publish only parts of the whole software that was evolved together with the proprietary parts?

For example they have library X1.0 which is GPLv3 licensed and Y1.0 which contains proprietary code and is only used internally. Let's say the company now continues development on the project internally and the results are library X1.1 and Y1.1. Are they now allowed to publish library X1.1 but keep Y1.1 for internal use only?

Thanks in advance for the advice.

  • Are there third-party GPL components involved? Does X or Y include GPL-licensed software written by someone outside the company? (I don't think this will substantially change the answer, but might make it a little simpler.)
    – apsillers
    Feb 1, 2019 at 13:44
  • What are your objectives for the open source license you choose? In other words, what do you want people to be able to do with the code and what do you want to prohibit? Key considerations: trademarks, patents, commercial use, modification, using the code in service products that aren’t distributed for installation. Feb 2, 2019 at 21:32
  • @apsillers Yes there are a lot of components involved that are licensed under different licenses. For example "The Apache License", MIT, GPLv3, and more.
    – Radioo
    Feb 4, 2019 at 8:01
  • @MichaelHogan Our objective is to make the biggest part of the software available to the public, but the company uses a proprietary library which is not to be given to the public. GPLv3 allows the company to keep a modified version with the prioprietary code for internal use to my understanding, but if we develop the software further and evovle it as a whole, do we have to publish it as a whole, or can we just publish a "subset" program, that does not include the proprietary parts?
    – Radioo
    Feb 4, 2019 at 8:03
  • @Radioo Licenses grant rights with stipulations, but don't really take rights away. As long as you're the sole copyright holder, (IANAL but) I think releasing X while keeping Y proprietary should be fine.
    – Will Chen
    Aug 8, 2023 at 3:45

2 Answers 2


I’m not a lawyer so I’ll give you an engineer’s perspective.

The answer to your question will depend on what rights you want to grant to others who use your code and what rights you want to restrict. If you have used other open source code in your project, your options may be limited. Here are the key questions I think about when choosing or evaluating an open source license.

Ownership. As the author and copyright holder you will always have a license to your code as long as you don’t transfer your ownership rights to some other person or organization. That means, regardless of how the code is licensed to others, you can do as you wish with the code. A license simply defines how others can use code you release under that license. You can also release future updates to your code under a different license that prior releases (MongoDB recently did this). What you cannot do is change a license of code already released to another party after you have released it.

Compatibility. What other software do you want your software to be compatible with? Review this Wikipedia article on Software License Compatibility and review related references. Note that compatibility flows one way. Projects with incompatible licenses cannot use your code, so if you pick a GPL3 license then only GPL3 or AGPL projects can build upon your work.

Software License Compatibility (source:Wikipedia)

Multi-Licensing. If you own the code, you can release it under multiple licenses. For example, you may offer a GPL license to projects that want to use the code for free and you may offer a commercial license to projects that can’t use GPL code but are able to pay you for a commercial license. Multi-licensing can confuse your users and get people who think your code is free into trouble, so be cautious and communicate clearly if you choose a multi-license strategy.

Patents. Some licenses, like Apache 2.0, also authorize users of your code to use your patents. Other licenses, like Mozilla Public License, retain patent rights. Retaining patent rights doesn’t mean people must pay you to use your patents, but it does mean you can defend your patents or ask people using your code in a way you dislike to stop violating your patents. You need to decide which approach you want to take.

Trademarks. Some licenses, like BSD 3-Clause, prohibit users of your code from using your trademarks and branding. This prevents them from making a derivative work & offering it under your brand. If the brand name of your software is important then it may be important to protect. People can still use BSD 3-clause code, but they need to advertise and market it under their own name.

Enforceability. Licenses are legal documents and not all of them will hold up in court. To increase the odds your license will be legally meaningful it can help to pick a popular open source license that has been tested by others. GPL has been around for a while, and I think has survived in court, so it is an example of a well known and tested license. The Open Source Initiative works to identify, evaluate, and promote licenses and is one place you can check to understand how popular or open various licenses are.

While Creative Commons licenses aren’t appropriate for code, it’s worth reading some of the articles on the Creative Commons website. They explain licensing in an approachable way. I’ve learned a lot from them.

  • I've already stumbled upon this chart you have included, but looks like I've missinterpreted it. So if we already use software that is licensed under MIT, Apache 2.0 and GPLv3 we can't really publish under GPLv3 anymore, since we use less restrictive software? Or can we publish it as a whole under GPLv3 and but keep the used (unmodified) packages licensed under less restrictive licenses with their according license?
    – Radioo
    Feb 4, 2019 at 8:16
  • The source of the image (dwheeler.com/essays/floss-license-slide.html) states that you can combine software under different licenses in this chart by going "from left to right" by using the arrows and finding a common reachable license. In that case if we use MIT, Apache 2.0 and LGPL licensed software, we should still be able to publish under GPLv3, right?
    – Radioo
    Feb 4, 2019 at 8:37
  • Your situation sounds pretty complex so I’d recommend getting advice from an expert (ideally from your company’s legal department). My understanding is that your interpretation of the diagram is correct and you can license a larger work GPLv3 if it is built from components released under more permissive licenses to the left in the chart. MIT, Apache 2.0, and LGPL projects will not be able to use your GPLv3 code until your work enters into the public domain. Feb 4, 2019 at 16:12
  • I see, so basically I do have to follow the chart to the right to a license, that is reachable by all sublicenses. Yes our situation is in fact a bit complicated, especially because the software has already been sold within a bundle of software on a VM to hundreds of companies. We are planning to ask the legal department of our industry partner, but we first wanted to get an overview if it's possible at all, or if we had to invest a major amount of work to achieve to be able to go open source. Thanks for your input, it was very helpful!
    – Radioo
    Feb 5, 2019 at 7:32

Are the binaries being distributed or used only in-house? If not distributed, there are no distribution requirements whatsoever.

If the binaries are distributed, the corresponding source must be distributed or made available.

What you need to look for is how any proprietary code is used. A proprietary library can legally be linked to software distributed under GPLv3, according to the appropriate FAQ, but it requires special permission. This is permission to link. The program as a whole is still covered by GPLv3, but if you're the copyright holders no license terms matter, as you can release however you want. This doesn't apply if you use GPLed software from somewhere else.

The company you're providing the software to may not be able to distribute it as a system, but it can certainly release any GPLed code it likes, including a library.

  • If the company paid @Radioo’s to write the code or co-authored the code, then the company may already be a copyright owner. In that case, the company may have full rights to the code regardless of how it is later licensed to others. Feb 4, 2019 at 1:04
  • The binaries of the proprietary parts will not be included in the publicly distributed version of the software. We also use GPLed software and even software under other licenses. My team is also employed by this company, so the ownership of the program is certainly theirs.
    – Radioo
    Feb 4, 2019 at 8:08

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.