Hi Leon, Thanks for the notes, may be parallel to our sales we may spend some time on the points you mentioned to protect our selves in the future.
Best Regards, Kranti K K Parisa On Thu, Jan 21, 2010 at 9:54 PM, Leon Rosenberg < rosenberg.l...@googlemail.com> wrote: > Hello Kranti, > > first of all I strongly believe in open source software and don't like > to obfuscate things. But well. > > 1. If you have internet connectivity on the target server you could > only deploy a skeleton of your application and load the > protect-worthly classes > directly from your servers with own classloading with some funny > remoteid exchange system. This way even the compile version of the > application will never be directly available on customers hard drive > (you must consider swapping and memory snapshots, but modern OSes > encode them). It's cheap but will probably add a load of complexity, > which you have to manage and, logically, your customer have to pay. > > 2. precompile jsps and use a code obfuscator on the jsps and compiled > classes (they replace all private methods and variables with a1,a2, > and so on). There are some on the market, more or less good. Use also > css/js minifier, they obfuscate as well. > > 3. create a genial encryption algorithm with some one-time passwords > and let the customers call you each time they restart the server for a > new password. Maybe charge them per password. The server can then > decrypt the classes with the password before it starts the webapp. > > 4. put the code and tomcat onto a usb stick with unreadable filesystem > and hack yourself into the usb protocol. Drawback: you'll have to > patch the browsers to accept urls like usb://localhost/yourapp. > > 5. stop wasting your time and invest it into developing new features > and actually selling your product. If its worth copying it will be > copied this way or other. So far no one has managed to protect its > software against copying, better concentrate on things you really CAN > achieve. > > regards > Leon > > 2010/1/21 Kranti™ K K Parisa <kranti.par...@gmail.com>: > > Well there are soo many comments on the cost of IP and other tools. when > we > > are a small team started working on a web based product with open source > > tools, for sure we can't spend too much on the tools to protect the IP > > rights. because once we deploy for few clients, if its a good product, > what > > if they steal the code and also ideas. i agree to have legal terms and > all > > that stuff. but that would be a big story for us being small. > > > > so just wanted to see if anything available to protect our work, ideas > > (ideas at code implementation level by using different opensource > > technologies, well there are many companies who started like this). > > > > anyways thanks for the comments, i would love to share if we invent > anything > > in this process, because small is big and it matters :) > > > > Best Regards, > > Kranti K K Parisa > > > > > > > > On Thu, Jan 21, 2010 at 5:00 PM, André Warnier <a...@ice-sa.com> wrote: > > > >> Peter Crowther wrote: > >> > >>> 2010/1/21 Kranti™ K K Parisa <kranti.par...@gmail.com> > >>> > >>> > >>>> How could we achieve this without the above tool? Because the pricing > of > >>>> the > >>>> above tool is very costly. > >>>> > >>>> Well, you could always spend the developer-years to create your own > >>>> version > >>>> > >>> of that tool... which would probably be *more* costly. > >>> > >> > >> > >> I'll add something to that, just for the sake of it. > >> I personally find this situation ironic : here we have someone who wants > to > >> protect their own code, presumably so that they can charge the customer > for > >> a copy of it, in order to get back their cost of development and some > >> justified profit for their work. > >> But the same people are apparently unwilling to pay for a product that > >> would allow them to do so, and is sold on the same terms. > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
