Code obfuscation in heavily templated library

613 Views Asked by At

Large portion of our commercial C++ library relies on templates. We plan to sell our product as header files and dynamically linked libraries (closed-source), but because most of our code base is concentrated in headers, we would de facto be releasing it as open-source with small, easily replaceable chunks missing.

Here is an example of what one of our classes from library interface look like:

template<class ItInput, class ItOutput>
struct serialize{
  ItOutput operator() (ItInput first, ItInput last, ItOutput d_first) {
    // operation on pointers (assuming that ++, -- and * operators work as expected for pointers) 
} 

Is there a way to provide level of obfuscation to our templated code equal to or better than compilation of regular code (i.e. technically reversible but not profitable nor optimal to do so)?

EDIT: To clarify, our goal is to prevent users from reading the implementation, not prevent unlawful copying of our work. For the sake of the question please assume we have a valid reasons for this requirement.

1

There are 1 best solutions below

1
On

we would de facto be releasing it as open-source

Wrong. "open source" means that your license is compatible with the OSI and it is likely to not be.

Ask your lawyer.

You are wrongly seeking a technical answer to a legal issue.

Is there a way to provide level of obfuscation to our templated code equal to or better than compilation of regular code

If you have time to spend, you might for example replace every identifier in your library with some useless junk. For example, if you use the secret identifier, add something like

#define secret s_1eovFxBcc2F

before any other code. Later you could even run a script replacing every occurrence of secret with s_1eovFxBcc2F. Of course your secret should not appear in any system headers that you use.

IMHO, that would be a loss of time, but might make your manager happy.

What really matters is the license applicable to your clients. No serious business (and certainly not the big ones) can afford going against the law.

To clarify, our goal is to prevent users from reading the implementation,

Then provide only, as the published interface of your library, a set of C-like (and probably declared extern "C") functions, with only opaque data types.

BTW, did you consider the opposite approach, of making your library open source, perhaps with a GPL license (and sell alternative, less free software friendly, licenses), so that every (distributed) program using it has to be GPL-ed also (or has to buy your expansive other license)?

(I insist, legal issues usually don't have technical only solutions)