I'll give a couple of ideas first, but please make sure that you read 
this entire message because I think you need to rethink your 
strategy.

The simple answer is that you can use a code obfusocator(sp?) 
like 4th Pass but that might result in code that may not run in all 
JVMs. You can only do this with servlets, it will not work with 
JSPs. While JSPs do end up as compiled java servlets, that's very 
servlet engine specific (you asked a similar question in an earlier 
message). 

Now for a better answer.

First, you're code is already protected. It's called US Copyright law. 

Second, nothing you do will protect your code. Nothing. Absolutely 
nothing at all. It might make it harder to break, but it won't stop it. 
That password on your C/C++ programs? Ha. Child's play. It just 
takes 1 person to do so. Then they can put that on the 'net. 

So what do you do? Well it seems from your message and from 
your website, that you're a consulting company. The bulk of your 
revenues are in support and planning. The software just makes 
your job eaiser. It's your expertise and your service (and partially 
your product) that makes people chose you over your competitor.

Thus what happens if someone does decompile your code. What 
are they going to do? Sell it? If that's the case, that would already 
have been done. 

I'm not saying that you should open-source it (though it is an idea), 
but that you should be focusing on improving your product, not 
trying to figure out how to keep people from stealing it. Just factor 
the cost of the potential of lost software revenue into your support.  
I mean look at Digital Creations and Lutris Solutions. These 
companies totally open-sourced their solutions (at least for DC, 
they did use to sell theirs). Anyone can use it. Anyone can offer 
consulting services on it. But these companies are growing and are 
more healthy now than they were before they open-sourced their 
code. Why? Because open-sourceing helped give them some 
marketing and put their technology into places that it wouldn't 
otherwise be. And then when people wanted support. Who do they 
turn to? The people who created it.

The answer is that you're spending a lot of time and energy 
focusing on something that probably won't work but more likely 
break your product. Instead you should be focusing on fixing bugs 
and adding new features. That's what's going to keep people from 
doing something with your code. The fact that you're doing it better 
than anyone else.

If the only reason why you're staying ahead is because of 
something in your software, then you're in a dead-end company. 
Eventually someone will figure that feature out (and probably 
without ever touching your code) and if they provide a better service 
for it (or even just give it away, look at IE and Netscape), you're 
dead meat.

Mark






On 1 Dec 00, at 8:53, pvancauteren@o... wrote:

> When we install our Java application at our customers site, we don't
> want our customers to copy the application to other computers or other
> web servers.  Our traditional C/C++ applications contain a password
> protection mechanism, but this seems difficult to implement in Java,
> since anyone with a decent Java knowledge can extract the 'security'
> class from the jar file, write his own 'security' class (that always
> returns true e.g.) and thus fool the application. Does anyone have
> this problem too ?  What is the best solution for this problem ? Note
> that this problem is somewhat related to the de-compilation of java
> classes problem too, so I think that an obfuscator or specific class
> loader might help here too.


Mark Wilcox
mark@m...
Got LDAP?