Distributing a secure JAR -- for *compilation*

[Hegemony Cricket]

My company is hoping to distribute a JAR file containing a bunch
of API classes for some low-level underlying computations.

There seem to be a number of ways to distribute secure JAR files
that can later be *executed* securely. But we want to distribute
a JAR file that's as secure as possible but can still be used by end
users in *compilation*.

We've found yGuard, which will obfuscate a JAR file to make it at
least hard to decypher. However, we would also like to be able
to set a time limit on the JAR file's usability. At some point we might
also want to limit the JAR to only run on one platform (by IP or MAC
address).

The only thing I can think to do is some sort of license key check
that occurs in a base java class's static initializer, that halts the
program if the license is expired or invalid. This sounds like it
would be easy to hack out of though, even if the jar were obfuscated.

I can't imagine we're the first to want to do something like this,
but I can't seem to find any references to how to handle this
situation. Suggestions?
--Mark

[perry]

creating license keys as you have mentioned is not a bad idea. unless
you expect sales as a large as borland, i can't see too many hackers
wanting to tear your product apart. however, perhaps looking at the java
security api might provide a way for you to provide licensing to
individual customers.

- perry

"nothing is impossible, we just don't know how to do it yet" - albert
einstien

Hegemony Cricket wrote:

My company is hoping to distribute a JAR file containing a bunch
of API classes for some low-level underlying computations.

There seem to be a number of ways to distribute secure JAR files
that can later be *executed* securely. But we want to distribute
a JAR file that's as secure as possible but can still be used by end
users in *compilation*.

We've found yGuard, which will obfuscate a JAR file to make it at
least hard to decypher. However, we would also like to be able
to set a time limit on the JAR file's usability. At some point we might
also want to limit the JAR to only run on one platform (by IP or MAC
address).

The only thing I can think to do is some sort of license key check
that occurs in a base java class's static initializer, that halts the
program if the license is expired or invalid. This sounds like it
would be easy to hack out of though, even if the jar were obfuscated.

I can't imagine we're the first to want to do something like this,
but I can't seem to find any references to how to handle this
situation. Suggestions?
--Mark