views:

287

answers:

7

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?

+2  A: 

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.

fuzzy lollipop
not necessarily, try to be more creative...
Inverse
then explain if you are so full of creative ideas on how to prevent something that is impossible to prevent
fuzzy lollipop
+3  A: 

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.

Anon.
A: 

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).

Michael Kohne
+6  A: 

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.

Shmoopty
I was going to suggest this, but this would require the license to be compiled into the library for each developer. While not impossible, it might be impracticable.
ChrisF
@ChrisF: Edited with a practical solution to that.
Shmoopty
this places a burden on the end user which is specifically forbidden in the question
fuzzy lollipop
I don't think this is too much burden on the client programmer. However, I don't really get it--are you suggesting a custom build for each customer? If not, how would this mechanism really protect against copying--the illegal copier would just need to supply the username and the hash together with the binary.
Nikola Gedelovski
A: 

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.

epatel
A: 

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

Inverse
In order for the linker to access the shared library, it will have to be representable in some form that can simply be copied.
Tom
all these ideas put some kind of burden on the end user, which is specificaly mentioned as not allowed in the question
fuzzy lollipop
+6  A: 

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.

peterchen
Watermarking is easy: just put it in as a string. (It's probably best to put it in twice: once as plain text, so people know that it's there, and once encoded, in case someone changes the string.)
Chip Uni
Why distributing a C++ static library any more terrible than a C library or C++ dynamic library? C++ ABI is complex, but most likely symbol mangling will prevent linking libraries with incompatible ABI.
Alex B
@Checkers: You are right - you can run into many of these issues as well one way or another. Most DLL interfaces know to avoid that, though. ----- @Chip Uni - My point was that "a simple string" is easily edited out.
peterchen