Copy-protecting a static library

Question

I will soon be shipping a paid-for static library, and I am wondering if it is possible to build in any form of copy protection to prevent developers copying the library.

Ideally, I would like to prevent the library being linked into an executable at all, if (and only if!) the library has been illegitimately copied onto the developer's machine. Is this possible?

Alternatively, it might be acceptable if applications linked to an illegitimate copy of the library simply didn't work; however, it is very important that this places no burden on the users of these applications (such as inputting a license key, using a dongle, or even requiring an Internet connection).

The library is written in C++ and targets a number of platforms including Windows and Mac.

Do I have any options?

Answer 1

I agree with other answers that a fool-proof protection is simply impossible. However, as a gentle nudge...

If your library is precompiled, you could discourage excessive illegitimate use by requiring custom license info in the API.

Change a function like:

jeastsy_lib::init()

to:

jeastsy_lib::init( "Licenced to Foobar Industries", "(hex string here)" );

Where the first parameter identifies the customer, and the second parameter is an MD5 or other hash of the first parameter with a salt.

When your library is purchased, you would supply both of those parameters to the customer.

To be clear, this is an an easily-averted protection for someone smart and ambitious enough. Consider this a speed bump on the path to piracy. This may convince potential customers that purchasing your software is the easiest path forward.

Answer 2

A C++ static library is a terribly bad redistributable.

It's a bot tangential, but IMO should be mentioned here. There are many compiler options that need to match the caller:

• Ansi/Unicode,
• static/dynamic CRT linking,
• exception handling enabled/disabled,
• representation of member function pointers
• LTCG
• Debug/Release

That's up to 64 configurations!

Also they are not portable across platforms even if your C++ code is platform independent - they might not even work with a future compiler version on the same platform! LTCG creates huge .lib files. So even if you can omit some of the choices, you have a huge build and distribution size, and a general PITA for the user.

That's the main reason I wouldn't consider buying anything that comes with static libraries only, much less somethign that adds copy protection of any sort.

---

Implementation ideas

I can't think of any better fundamental mechanism than Shmoopty's suggestion.

You can additionally "watermark" your builds, so that if you detect a library "in the wild", you can determine whom you sold that one to. (However, what are you going to do? Write angry e-mails to an potentially innocent customer?) Also, this requires some effort, using an easily locatable sequence of bytes not affecting execution won't help much.

You need to protect yourself agains LIB "unpacker" tools. However, the linker should still be able to remove unused functions.

---

General thoughts

Implementing a decent protection mechanism takes great care and some creativity, and I haven't yet seen a single one that does not create additional support cost and requires tough social decisions. Every hour spent on copy protection is an hour not spent improving your product. The market for C++ code isn't exactly huge, I see a lot of work that your customers have to pay for.

When I buy code, I happily pay for documentation, support, source code and other signs of "future proofness". Not so much for licencing.

Answer 3

Ideally, I would like to prevent the library being linked into an executable at all, if (and only if!) the library has been illegitimately copied onto the developer's machine. Is this possible?

How would you determine whether your library has been "illegitimately copied" at link time?

Remembering that none of your code is running when the linker does its work.

So, given that none of your code is running, we can't do anything at compile or link time. That leaves trying to determine whether the library was illegitimately copied onto the linking machine, from a completely unrelated target machine. And I'm still not seeing any way of making the two situations distinguishable, even if you were willing to impose burdens like "requires internet access" on the end-user.

My conclusion is that fuzzy lollipop's suggestion of "make something so useful that people want to buy it" is the best way to "copy-protect" your code library.

Answer 4

copy protection and in this case, execution protection by definition "places a burden on the user". no way to get around that. best form of copy protection is write something so useful people feel compelled to buy it.

Answer 5

You can't do what you want (perfect copy protection that places no burden on anyone except the people illegally copying the work).

There's no way for you to run code at link time with the standard linkers, so there's no way to determine at that point whether you're OK or not.

That leaves run-time, and that would mean requiring the end-users to validate somehow, which you've already determined is a non-starter.

Your only options are: ship it as-is and hope developers don't copy it too much, OR write your own linker and try to get people to use that (just in case it isn't obvious: That's not going to work. No developer in their right mind is going to buy a library that requires a special linker).

Answer 6

If you are planning to publish an expensive framework you might look into using FLEXlm.

I'm not associated with them but have seen it in various expensive frameworks often targeted Silicon Graphics hardware.

Answer 7

A couple ideas... (these have some major draw backs though which should be obvious)

For at compile time: put the library file on a share, and give it file permissions only for the developers you've sold it to.

For at run time: compile the library to work only on certain machines, eg. check the UIDs or MAC ids or something

Answer 8

I will soon be shipping a paid-for static library

The correct answer to your question is: don't bother with copy protection until you prove that you need it.

You say that you are "soon to be shipping a paid-for static library." Unless you have proven that you have people who are willing to steal your technology, implementing copy protection is irrelevant. An uneasy feeling that "there are people out there who will steal it" is not proof it will be stolen.

The hardest part of starting up a business is creating a product people will pay for. You have not yet proven that you have done that; ergo copy protection is irrelevant.

I'm not saying that your product has no value. I am saying that until you try to sell it, you will not know whether it has value or not.

And then, even if you do sell it, you will not know whether people steal it or not.

This is the difference between being a good programmer and being a good business owner.

First, prove that someone wants to steal your product. Then, if someone wants to steal it, add copy protection and keep improving your product.

Answer 9

I have only done this once. This was the method I used. It is far from foolproof, but I felt it was a good compromise. It is similar to the answer of Drew Dorman.

I would suggest providing an initialisation routine that requires the user to provide their email and a key linked to that email. Then have a way that anyone using the product can view the email information.

I used this method on a library that I use when writing plugins for AfterEffects. The initialisation routine builds the message shown in the "About" dialog for the plugin, and I made this message display the given email.

The advantages of this method in my eyes are:

1. A client is unlikely to pass on their email and key because they don't want their email associated with products they didn't write.

2. They could circumvent this by signing up with a burner email, but then they don't get their email associated with products they do write, so again this seems unlikely.

3. If a version with a burner email gets distributed then people might try it, then decide they want to use it, but need a version associated to their email so might buy a copy. Free advertising. You may even wish to do this yourself.

I also wanted to ensure that when I provide plugins to a company, they can't give my library to their internal programmers to write plugins themselves, based on my years of expertise. To do this I also linked the plugin name to the key. So a key will only work for a specific plugin name and developer email.

To expand on Drew's answer - to do this you take the users email when they sign up, you tag a secret set of characters on the end and then hash it. You give the user the hash. The secret set of characters is the same for all users and is known to your library, but the email makes the hash unique. When a user initialises the library with their email and the hash, your library appends the characters, hashes it and checks the result against the hash the user provided. This way you do not need a custom build for every user.

In the end I felt anything more complex than this would be futile as someone who really wanted to crack my library would probably be better at it than I would be at defending it. This method just stops a casual pirater from easily taking my library.