There are two different issues here:
- a legal "May I...?"
- a technical "Should I...?"
For the legal side, there is one major case where this would not be allowed. If your project uses someone else's code that is under the GPL (or other copyleft license), then the terms of the GPL require your code to also be licensed as a whole under the GPL when you choose to distribute it. If you choose to distribute the code in binary form, then an issue arises, because the GPL requires that you accompany distribution of GPL'd binaries with their full corresponding source code. Omitting aFunction
in the program's corresponding source would be a GPL violation, since you distributed a derivative of someone else's GPL-licensed code in binary form but failed to share the complete corresponding source of the binary.
If you are the sole author of the code, or distribute the incomplete source only, or are not using a copyleft license that requires corresponding source alongside binaries, then you do not have this issue. For example, the permissive MIT/X11 license requires no corresponding source to accompany a binary, so if you choose to share almost everything except one function, you're going above and beyond what such a permissive license requires.
On the technical side, the fact that you feel the need to do this strongly suggests some kind of inferior security through obscurity. This is captured in Kerckhoffs's principle, which may be summarized as, "The security of a system should depend entirely on the secrecy of a random key value. It should not be a problem if an attacker learns how the system operates."
If you have a security system that relies on its operation remaining secret rather than on a random key value, it probably is not a very strong security system. (All serious modern cryptographic systems are designed with this principle in mind.) When distributing your source code, you should keep the key secret, but simply provide users a way to generate or provide their own key(s). The key is not code within the software system; it is a configuration value provided to the system. (I have a related answer for the question Open Source Projects with Encryption Keys.)
Alternatively, if your secret system is a system for flagging bad behaviors (e.g., Stack Exchange bans users after a they match a secret pattern of bad behavior) and you keep it secret to keep users from skirting the line, I still think configurable-values are the way to go. Don't write you system to say
after 3 bad actions, ban the user for 24 hours
Instead, say
after N bad actions (which is the set of actions in {A1, A2, A3,...}), ban for H hours
where N, {A}, and H are values specified by the administrator running the system.