Code protection in Zope
Now that the issue has come up... What would be a good way to protect code in Zope, both in straight Python code in the file system -Products/Extensions- and dtml/tal ? We have developed solutions which would like to install in customer's equipment, nevertheless, we can't or don't want to give out the source code and/or risk the products to be distributed without the appropriate permissions, therefore we are looking for some sort of safeguarding the code. I know this may look as against the "Open Source" model, but unfortunately, contracts, NDAs and all that stuff DO exist and therefore we are obliged to comply with them. Any comments are more than welcome. Edward
by the way, .pyc files don't protect your code very well, if that's why you're shipping only them.
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's JONIC LIMP BIMBO! (random hero from isometric.spaceninja.com)
There is really no good way to protect Python code. Neither the Python sources nor the compiled byte-code. Maybe contact Marc-Andre Lemburg from egenix.com...he gave a talk on a solution to protect sources during the last EuroPython conference....but I can not remember the details. -aj --On Mittwoch, 4. Februar 2004 12:25 Uhr -0600 Celula Research <fb@celula.com> wrote:
Now that the issue has come up...
What would be a good way to protect code in Zope, both in straight Python code in the file system -Products/Extensions- and dtml/tal ?
We have developed solutions which would like to install in customer's equipment, nevertheless, we can't or don't want to give out the source code and/or risk the products to be distributed without the appropriate permissions, therefore we are looking for some sort of safeguarding the code.
I know this may look as against the "Open Source" model, but unfortunately, contracts, NDAs and all that stuff DO exist and therefore we are obliged to comply with them.
Any comments are more than welcome.
Edward
by the way, .pyc files don't protect your code very well, if that's why you're shipping only them.
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's JONIC LIMP BIMBO! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Wed, Feb 04, 2004 at 12:25:14PM -0600, Celula Research wrote:
Now that the issue has come up...
What would be a good way to protect code in Zope, both in straight Python code in the file system -Products/Extensions-
This is a FAQ on comp.lang.python. The general consensus is that you can't, but nobody really cares ;-) pyc and pyo files require significant work to convert back to anything like human-readable python source, but anyone who's determined enough code eventually do it. This is not unique to python. http://mail.python.org/pipermail/python-list/1999-April/000666.html
and dtml/tal ?
make sure your users don't have unnecessary permissions, notably "View Management Screens". -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's INTER ! (random hero from isometric.spaceninja.com)
Celula Research wrote:
Now that the issue has come up...
What would be a good way to protect code in Zope, both in straight Python code in the file system -Products/Extensions- and dtml/tal ?
We have developed solutions which would like to install in customer's equipment, nevertheless, we can't or don't want to give out the source code and/or risk the products to be distributed without the appropriate permissions, therefore we are looking for some sort of safeguarding the code.
I know this may look as against the "Open Source" model, but unfortunately, contracts, NDAs and all that stuff DO exist and therefore we are obliged to comply with them.
I don't mean to sound glib, but I would suggest that you solve your contractual problems with contractual solutions. The legal system is your best defense in this area. Technical solutions for copy protection fail left and right, and a number of computer scientists will tell you that this may be because it's impossible. There have been on this list several discussions where we explored the various options. See "Zope application offline - how to apply a license ptotection?" 8/14/2003 "How do I encrypt files in the ZODB" 7/22/2003 The easiest option is to use a machine with an encrypted filesystem that you control as much as possible, down to the padlock on the case. This isn't foolproof, but it would take a lot of work to get root on such a machine and thus access your code. If you want to hand somebody Zope code such that they can't copy it but can run it, I suppose there are ways to extend Python to interpret code that requires some sort of key to decrypt, and to come up with a similar scheme for templates too, but I wouldn't want to try it. Techniques for obfuscation are easier, but still not simple. --jcc -- "He who fights with monsters should look to it that he himself does not become a monster. And when you gaze long into an abyss the abyss also gazes into you."
On Friday 06 February 2004 03:39 pm, J Cameron Cooper wrote:
Celula Research wrote:
We have developed solutions which would like to install in customer's equipment, nevertheless, we can't or don't want to give out the source code and/or risk the products to be distributed without the appropriate permissions, therefore we are looking for some sort of safeguarding the code.
I don't mean to sound glib, but I would suggest that you solve your contractual problems with contractual solutions. The legal system is your best defense in this area. Technical solutions for copy protection fail left and right, and a number of computer scientists will tell you that this may be because it's impossible.
You know, people say all the time that Python can't be obfuscated, as if it were something new, but this is really true of machine code generated by C or C++, too. You can always "disassemble" it. This may be somewhat easier in Python, but it's not a huge difference. To the typical end-user, the use of Python byte code (*.pyc files) is probably quite adequate. Saying that this is pointless is a bit like saying that padlocks are pointless, because anyone with a bolt cutter can get through them. At some level, it's true -- all security can be defeated. I can't comment on the utility of contractual clauses to deal with this issue, though it seems likely that you can. No one will read them, though. OTOH, if I get only *.pyc files from somebody, my first guess is going to be that they did that because they didn't want me to read their sources. Certainly, unless I'm awfully motivated, I'm not going to bother trying to disassemble them. So unless you love to spend lots of time in court ( :-P ), I imagine that privacy-strength protection is in order, in addition to any added fine print. And that's easy -- just ship byte-code. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
participants (5)
-
Andreas Jung -
Celula Research -
J Cameron Cooper -
Paul Winkler -
Terry Hancock