Is Python suitable for a huge, enterprise size app?

[Maurice LING]

Peter Hansen wrote:

> Maurice LING wrote:
> 
>> It makes big difference (legally) to if the codes are there and 
>> someone sees it, to if the codes are locked in some packaged or zipped 
>> form and someone reverse-engineer it. It is legally as different as if 
>> you drop money on the ground and I pick it up, to pick-pocketing you 
>> and take the money.
>>
>> Nobody seems to be able to understand this simple logic.
> 
> 
> So you're saying that reverse engineering Java bytecode is illegal, 
> while doing the same with Python bytecode is not?  Or something like 
> that?  (And you're a lawyer, right?  Because if you're not, and you're 
> not citing your sources, why is it we should put any value in these 
> comments about what is (legally) true?)
> 
> -Peter

I am not saying reverse engineering Python bytecodes is legal while 
reverse engineering Java bytecodes is illegal. Please do not put words 
into my mouth, I am just saying "codes locked in some packaged or zipped 
form", reverse engineering is illegal unless specifically approved, be 
it Python bytecodes, Java bytecodes, Smalltalk, compiled executables etc 
etc... AND THIS HAD BEEN DISCUSSED IN OTHER THREADS, like in "bytecode 
non-backcompatibility" in April 2005 of python-list.

I am not a lawyer. Based on what I've read and seen, I won't try it. 
Below is an example of such articles by a law firm, citating case laws. 
Please google the term "reverse engineering computer sources" and you 
will find heaps of materials. You might like to test the depth of your 
pockets in courtroom, be my guest


 From http://www.jenkins-ip.com/serv/serv_6.htm

COMPUTER PROGRAMS

In the case of computer programs, the EU directive states (11) that the 
ideas and principles underlying a program are not protected by 
copyright, and that (12) logic, algorithms and programming languages may 
to some extent comprise ideas and principles.

Analysis of the function of a program (but not decompilation (13))is 
permitted under Article 5.3, if it is carried out by a licensed user in 
the normal use of the program.

Reverse engineering is allowed under Article 6, but only for the single 
purpose of producing an interoperable program (rather than a competing 
program).

For this purpose, in addition to reverse engineering itself (i.e. 
producing a high level version of the code) subsequent forward 
engineering to produce the interoperable program is permitted.

However, the reverse engineer has to cross a host of formidable barriers 
before he can make use of this right;

    1. It must be indispensable to reverse engineer to obtain the 
necessary information.
    2. The reverse engineering has to be by a licensee or authorised user.
    3. The necessary information must not already have been readily 
available to those people.
    4. Only the parts of the program necessary for interoperability 
(i.e. the interfaces) can be reproduced.
    5. The information generated by the reverse engineering cannot be 
used for anything other than achieving interoperability of an 
independently created program.
    6. The information cannot be passed on to others except where 
necessary for this purpose.
    7. The information obtained cannot be used to make a competing 
program (rather than just an interoperable one).
    8. The "legitimate interests" of the copyright owner or "normal 
exploitation" of the program must not be prejudice.

Thus, far from creating a general right to reverse engineer, these 
provisions create only the smallest of openings for the reverse 
engineer; they are intended for use only to defeat locked, confidential, 
proprietary interfaces.


(11) Council Directive 96/9/EC 11 March 1996; enacted in the UK as S.I. 
1997 No. 3032 13th recital
(12) 14th recital
(13) See, for example, Copyright, Designs and Patent Act 1988, Section 
29(4)

  SEGA ENTERPRISES LTD v. ACCOLADE INC 977 F.2D 1510 (9TH CIR. 1992)

This US software copyright case concerned Sega's video game console and 
cartridges. The cartridges had a 20-25 byte code segment which was 
interrogated by the console, as a security measure.

Accolade disassembled the code which was common to three different Sega 
games cartridges, to find the security segment, and included it in 
competing games cartridges.

The Ninth Circuit held this disassembly to be a permitted "fair use" of 
the copyright in the games programs.

ATARI v. NINTENDO 975 F.2D 872 (FED. CIR. 1992)

This US software copyright case concerned Nintendo’s NES video game 
console and cartridges. The cartridges contained a microprocessor, and 
program code, and was interrogated by the console microprocessor, as a 
security measure, like the Sega system. The security was potentially a 
two-way process, with the console checking for a valid cartridge and the 
potential for the cartridge to check for a valid console (which Nintendo 
did not actually do).

Atari disassembled the program code which performed the security 
signalling exchange (the interface code). However, they also had access 
to a copy of the source code from the US Copyright Registry, to obtain 
which they stated (untruthfully) that it was for the purposes of litigation.

They implemented the signalling exchange to validate the cartridge, thus 
achieving compatibility of their cartridges with Nintendo consoles. 
However, they went further and implemented the rest of the interface, to 
validate the consoles, apparently in case Nintendo changed their product 
in future. In each case, they copied some actual code, allegedly only to 
the extent necessary.

The Court held that the intermediate copying during reverse engineering 
was legitimate, as "fair use". However, Atari infringed copyright 
nonetheless, in going too far in copying beyond what was strictly 
necessary. The programmer apparently also had sight of the source code 
from the US Copyright Registry, casting some doubt on whether the 
copying was solely due to the reverse engineering operation.

Finally, Nintendo had a patent on the interface, and Atari were found to 
infringe that too.

AUTODESK INC v. DYASON [1992] RPC 575 & (NO. 2) [1993] 12 RPC 259

This Australian software copyright case concerned a CAD package, which 
was supplied with a hardware device containing an EPROM, called the 
AutoCAD lock, which operated with part of the package called the 
"Widget-C" program. The program sent a challenge signal to the lock, 
which replied with a return signal. The program checked the return 
signal against a lookup table. The lookup table comprised 16 bytes of a 
30kByte program. An encrypted form of the lookup table was held in the 
lock EPROM.

The Defendant studied the signals with an oscilloscope, and read them. 
Apparently, the correct contents of the EPROM were deduced from this 
functional analysis, without reading of the EPROM. They then produced an 
alternative lock device. The Plaintiff alleged that the table was a 
substantial part of the program, and that the program had thus been copied.

The Court held that the table was a substantial part of the program (an 
issue of importance rather than size) and that it had been copied, and 
that this was an infringement. A move to re-hear the case, on the basis 
that the Court had misunderstood, was dismissed (with dissenting 
judgements).

POWERFLEX SERVICES PTY LTD v. DATA ACCESS CORP [1997] 12 EIPR 732

This Australian software copyright case concerned a database management 
system (Dataflex) which was "cloned" by the Defendant. Apparently, 
although the Court referred to reverse engineering, the Defendant did 
not actually analyse the code by decompilation or disassembly, but read 
the manual to produce a lookalike using the same commands and file 
structures. All this was held not to infringe.

However, Dataflex used compression of records, using a stored table of 
Huffman codes to compress and decompress. The table thus constituted an 
interface between the program and the files. There is no indication that 
the files were to be shared with other programs, so the table was not an 
interface to non-competing interoperable programs. The Defendant wanted 
his program to be able to read files created by Dataflex and so he 
calculated the required compression table, apparently from inspection of 
stored records, which therefore reproduced that of Dataflex.

It was held that although the table was not a substantial part of the 
program (or even part of the program at all), it attracted literary 
copyright as a compilation in its own right, and that copyright was held 
infringed.

CREATIVE TECHNOLOGY LTD v. AZTECH SYSTEMS PTE LTD [1997] FSR 491

This Singapore software copyright case concerned the Sound Blaster PC 
Sound Card It contained firmware, and was supplied with an ancillary PC 
program to operate with it. The Defendants wanted to produce a sound 
card which could interoperate with PC programs which would operate with 
the Sound Blaster – in other words, to create a competing substitute. 
They bought and studied a Sound Blaster and ancillary program. They were 
held (on the balance of probabilities) to have disassembled and reverse 
engineered the firmware, and admitted running the ancillary program 
(which they pleaded as a "fair dealing"). In their product, only about 
4% of the code was identical to that of the Sound Blaster firmware, but 
that 4% included redundancies and errors present in the original, 
suggesting copying (going beyond that which is necessary).

The Court held (reversing the first instance) that although the ultimate 
products did not involve a substantial reproduction of the original 
program, there was clear evidence that reverse engineering had been used 
and hence that an intermediate copy had been made. This and the admitted 
copying (in unlicensed use) of the ancillary program were both not "fair 
dealing", and hence infringed.