Recently I got an e-mail from a package maintainer asking me to unlist my fork of said package from NuGet due to my fork "confusing nuget users".

I've never encountered a request like this before and as I have a few more forks like that I now wonder whether I'm doing something wrong and if I should unlist my other forks as well.

  • source code of the original package (any my fork too) is available on GitHub
  • there is no LICENSE.md file but in the readme is a section stating:

This project is Copyright © 2021 XXX. Free for non-commercial use. For commercial use please contact the author.

  • clicking "License Info" on NuGet brings up Apache 2.0 license for both the original repo and the fork (which is weird as the author is prohibitng commercial use in GitHub readme without a commercial license)
  • Me and my friends needed to use the package with a change (a minor one but still blocking our use cases)
  • I've opened a PR with said change and got no response from the maintainer
  • hence I've published my fork to NuGet
  • the original package is called Package, my fork was available as Package-lof (my handle, unlisted after I got the request)

Am I legally required to comply with this request to unlist?

  • What is the question? And what does it have to do with the law?
    – bdb484
    Apr 18, 2022 at 3:08
  • I'm interested in whether or not I have to honor the unlist request. I believe the answer is in the licensing law which I don't know much about (hence I ask here) Apr 18, 2022 at 3:16

2 Answers 2


It would appear from your description that the author released this under a license "Free for non-commercial use" Or possibly under the Apache 2.0 license. In either case you have the right to create and distribute derivative works, which is what a fork would be. The original author has no eight to demand that you unlist your fork, or even rename it. However, if users are in fact being confused, offering to rename might be courteous.

The author has, if you have described the situation correctly, given up many of the copyright-based rights that s/he wpould otherwise retain.

  • 1
    “The author has … given up many of the copyright-based rights that s/he would otherwise retain” – it is not at all apparent from the description that the software would have entered the public domain in any way. It is also not clear that permission to “use” the source code implies permission to modify it. The entire situation is quite unclear, but it is very possible that OP infringed on the author's copyright and could be required to take the modified package down.
    – amon
    Apr 18, 2022 at 8:38
  • 1
    @Amon I never said or suggested that the software entered the public domain. I took the statement "free for non-commercial use" to be a general permissive license, (roughly comparable to a CC-BY-NC, say) but it is less than clear. What force the platform indication of the Apache license has is also less than clear. Apr 18, 2022 at 15:24

If you have validly received a copy of the source code under the Apache-2.0 license, then you have the right to create and publish modifications – and you could not be asked to take your fork down.

But it is not at all clear that you received the software under the Apache-2.0 license. You state that the licensing information for the source code mentions that it is “Free for non-commercial use”. There are a number of problems with this:

  • Permission to use a software does not necessarily imply permission to create derivatives, i.e. to modify the software.
  • What counts as non-commercial is quite unclear. All Open Source licenses allow commercial use. If you only had permission to non-commercial use, you definitely can't license the software to others under the Apache-2.0 license.
  • It may be necessary to distinguish between the license of the NuGet package and the license of the source code on GitHub. The original author can disallow commercial use of the source code, while still allowing commercial use via an Apache-2.0-covered NuGet binary.

Thus, it is quite possible that the creation and/or publication of your forked package constitutes copyright infringement.

Given that this licensing status is unclear, and that you don't have a particularly convincing argument that you received the source code under the Apache-2.0 license, the safest approach would indeed be to take your NuGet package down. Nevertheless, you might have been allowed to create a modified package for your own non-commercial purposes – but sharing it under the Apache-2.0 license is a problem.

A somewhat safer route might have been to reverse-engineer the Apache-2.0 licensed NuGet package instead of using the source code that doesn't have a clear license, but now it's probably to late.

Without understanding further details about this project, I would:

  • Unlist the forked NuGet package.
  • Make sure that the forked source code does not claim that the entire source code is Apache-2.0 covered (but at most, your own modifications).
  • Use some other mechanism to share the modified software with your friend for your non-commercial purposes.
  • In the future, stick to dependencies that are clearly and unambiguously licensed under an OSI-approved Open Source license, taking into account that not all licenses require the source code to be made available under the same terms.

For background on dealing with projects with unclear licenses, consider reading What can I assume if a publicly published project has no license? on Open Source Stack Exchange. From the answer by RubberDuck:

[…] In short, the only thing you can safely assume is that you have no rights to do anything at all with this code. In the particular case of GitHub, you can fork the repository and view the code, but nothing more.

  • Thanks for taking the time to write such an in depth answer. There's a lot in it for me. The confusion around licenses is due to the fact that there is a file in the source code responsible for setting the license under which the published package will be available. This file is set to Apache 2.0. I believe I have obtained the source code under "free for noncommercial use" license as that is the one on GiHub from where I have cloned the repository. I did not know one can license the source code and built binaries on NuGet differently but it makes sense as you put it. Apr 18, 2022 at 12:17
  • My fork is unlisted and luckily I got in touch with the maintainer and there seems to be mutual understanding, I hope we can get an OSI-approved Open Source license on the GitHub repository as that would be the clearest way. Also thanks for including the last paragraph, that was a great piece of information. Apr 18, 2022 at 12:20
  • One point which is still unclear to me is whether the license on GitHub "This project is Copyright © 2021 XXX. Free for non-commercial use. For commercial use please contact the author." allows for creating derivative (in non-commercial way) works and redistributing them as that seems to be a conflicting point with David's answer (if I got it correctly) Apr 18, 2022 at 12:24
  • @MatějŠtágl Yes, David and I disagree on that point. Most Open Source licenses explicitly permit use, modification, and distribution. The original project in question here does not, which could indicate that the author only intended to give permission to run the software, but no permission to modify or redistribute it. Because this is unclear, it is safer to assume that you haven't received such permission. However, David might know of case law in his jurisdiction that confirms his “permission to use is permission to create derivative works” interpretation.
    – amon
    Apr 18, 2022 at 14:54
  • 1
    @MatějŠtágl It is certainly possible under US law to grant permission to run software but not to copy it, or permission to copy and distribute a binary but not to modify it, or permission to copy a binary but not source code, or one of many other combinations. The question is what the author intended by the unclear word "use". I was assuming that "use" included permission to run, copy, and modify. A proper open source license would make those permissions explicit. Permissive licenses that are not OSI compliant should still make it clear just what permissions are, and what are not, granted. Apr 18, 2022 at 15:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .