Re: [Zope] Propietary software with Zope.
Jerome Alet wrote:
1 - You can develop proprietary software with Zope. Proprietary software with Zope..... How would someone develop "closed source" software with Zope. ? It would be easy to just twickle around with Data.fs and use "python zpasswd.py -u newuser -p newpasswd" on a fresh zope installation and take the "protected" Data.fs to get access into the source code. Or, I am missing something ? How can code be protected in Zope, at least to the same (relative) level of a compiled object code? This has been a discussion going in our company with some customers as to how to protect developed code... Comments are welcome. Do not confuse 'proprietary' or 'closed source' with 'protected'. One could develop code people can see, but has a non-open source license. I can think of a few proprietary PHp and Perl products. >Yes, you can see the code, but legally, you are bound by license to not suck the code out for your own version. Bill Besides all the legalese which, of course applies here and can or can-not be enforced, I am talking about "closed source" here, this is the scenario: I do not want other branches/offices that do have Zope installed and due to the current requirements have manage access (they have their own in-house development) to see our code. The need is to put our code in those Zope's but we don't want them to see, access or modify the code. Of course, pure python (or "C" for that matter) is a possible answer but my question goes directly on how to keep code within the Zope environment, closed. I am sure many people are interested in this topic. I also know it is kinda contradictory with the overall Zope concept but, the terms are what I just described. How would you solve it ? Any comments or ideas ? Edward.
The original questioner needed the users of the system to be able to develop their own software, so I think that precludes this security-based model. I will have the same question eventually, because the server will live in a security domain I don't control. My customer will have root access to the machine, and I may want to discourage them from reading the swearing in the comments in my code :-) At 05:37 10/07/01 GMT, zope@zope.org wrote:
Besides all the legalese which, of course applies here and can or can-not be enforced, I am talking about "closed source" here, this is the scenario: I do not want other branches/offices that do have Zope installed and due to the current requirements have manage access (they have their own in-house development) to see our code.
The need is to put our code in those Zope's but we don't want them to see, access or modify the code. Of course, pure python (or "C" for that matter) is a possible answer but my question goes directly on how to keep code within the Zope environment, closed. I am sure many people are interested in this topic. I also know it is kinda contradictory with the overall Zope concept but, the terms are what I just described. How would you solve it ? Any comments or ideas ?
Edward.
On Tue, 10 Jul 2001, J. Cone wrote:
The original questioner needed the users of the system to be able to develop their own software, so I think that precludes this security-based model.
I will have the same question eventually, because the server will live in a security domain I don't control. My customer will have root access to the machine, and I may want to discourage them from reading the swearing in the comments in my code :-)
For the filesystem part I suppose that deleting all *.py *.c *.h would do it since Zope should be able to run on *.pyc and *.so alone (I've not tested) For the ZODB I can't see any solution if they have root access. bye, Jerome Alet
participants (3)
-
J. Cone -
Jerome Alet -
zope＠zope.org