(original) (raw)
On 12/4/06, Neil Toronto <ntoronto@cs.byu.edu> wrote:
No. Part of the issue is there is no way to syntactically support entering the password to decrypt the zip file. One solution, though, would be to write an importer/loader object for zip files that was instantiated with a password and that could then handle the decryption.
-Brett
Martin v. Löwis wrote:
> Brett Cannon schrieb:
>
>> Did they say why they wanted to distribute bytecode files? I assume it
>> is either for space considerations or they think it will help to protect
>> their IP somehow.
>>
>
> It's to protect the IP (i.e. for proprietary software). They are aware
> of decompyle, but still consider byte-code only distribution of their
> code necessary for protection.
It sounds like a trade secret issue. You have to take reasonable
measures to protect trade secrets in order for them to be legally
recognized as such. I wouldn't be surprised if compiling to bytecode
counts. There are similar provisions in copyright due to the DMCA (which
seems to require nothing stronger than, say, ROT26), but I don't think
this is the right context for that.
Space considerations shouldn't be much of an issue, since you can (and
should in many cases) distribute your code in a ZIP file, and code
compresses quite well. Can Python import modules from encrypted ZIP
files? That'd be an interesting way to protect a trade secret, and
probably safer (in the courts) than distributing bytecode.
No. Part of the issue is there is no way to syntactically support entering the password to decrypt the zip file. One solution, though, would be to write an importer/loader object for zip files that was instantiated with a password and that could then handle the decryption.
-Brett