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.