Copyright

Asset protection

How to build an efficient and technical body of evidence a legal advisor, a lawyer or an arbitrator may require in case of an ownership or liability litigation?

In the strict sense of law, software ownership depends on its source code. It also follows that in the event of a piracy allegation, the judge will decide according to form more than to substance. In other words a software application originally written in C++ and rewritten by a pirate in Java will no longer have the same form and so would not legally be considered a forgery.

But jurisprudence lends more importance to the substance, including the way the IT property is built, the technical documentation including specifications, architecture documents, internal coding rules and technical choices regarding initial design decisions, when considering an alleged act of piracy. Recent jurisprudence also lends importance to any relationship between the alleged pirate and the company that is victime of the alleged piracy, e.g. if the alleged pirate is a former employee, client or subcontractor of that company.

The law protects not only the source code but all the material that contributes to creating the source code including analysis documents, functional and detailed specifications, architecture, internal coding and naming rules, development environment choices (always deliberate choices and more and more complicated, especially when considering open source components), etc. Consequently the body of evidence of ownership will be stronger if the Deposit technical contents are complete (source code, technical and end user documentation, build procedures, etc.) and if it contains successive major releases.

The LOGITAS Escrow System objectives are as follows:

To help the Depositor to build a backup of his IT property including a maximum number of initial analysis and design elements and specifications of the development environment necessary for creation of the source code and consequently the deliverable versions.

Encourage the stockpiling of the source code for each successive major version and if possible of copies of the configuration management system database (VSS, CVS, etc.) in order to build a solid body of evidence of ownership.

These deposits will constitute the technical part of the evidence on which the Depositors' attorney can rely to establish proof of piracy, should such an event occur.

Consequently, the accurate description of the selected development and packaging/flashing environments (particularly when involving open source, and/or downloaded libraries, fixes, and patches are concerned) installed to create the IT property may be determinate. Such development and packaging environments are not trivial and will usually determine the structure and organization of that property. Thus being able to reinstall the relevant development environment in front of a court commissioned expert, even 3 years after the Deposit was done, will constitute extremely valuable evidence of ownership.

Indeed, a software forgery created solely by recompiling stolen code on another platform with perhaps a few source code or packaging modifications is difficult to counter when the Depositor only has previously deposited source code to demonstrate. On the other hand, modifying software enough for it to be different from the original pirated code on which it is based in effect becomes a rewrite of that original code.

Such piracy requires a lot of time and effort and is thus not as profitable as it consists solely of reusing the main concepts and functionalities of the original software, ideas and functionalities which cannot be legally protected (except by a patent). Solidly built deposits will allow the Depositor to engage with the alleged pirate from a strong position in order to find a fair solution (presumably with the assistance of an expert or arbitrator) before having to resort to suing him (a process which is always time consuming, distracting and expensive).

With regard to legal procedures, it is easier to obtain a court order to seize counterfeit property when the Depositor is able to show a history of reliable deposits.

Let us now consider the question of delivering source code to the End User or Authorized Third Party without transferring ownership of the software , for example for maintenance or integration purposes. From the Depositor's point of view, the best way to protect ownership is of course to not deliver or demonstrate the source code. From the End User perspective, the best way to limit his own responsibility is to not have access to the source code but rather to depend on the Depositor for maintenance and consequently to assume responsibility in case the software is the subject of litigation for damage or regarding ownership.

The above notwithstanding, End Users often prefer to obtain the source code from the Depositor, if only for reasons of security and to reduce their supplier dependence. This approach only makes sense if the End User trains his own developers on the delivered source code, both the original and each successive released version, to be able to react efficiently in case of a crash. If this is not the case, the legal risks of having the source code outweigh the other benefits.

In other words, a solid deposit often allows litigations to be solved via negotiations based on a complete technical (and so indisputable) evidence of the state of the concerned IT property.

This body of evidence can be useful for many reasons other than ownership disputes.

For example it can be useful to show evidence of the state of an IT property for civilian or contractual liability purposes when a software owner engages a subcontractor to reengineer, maintain or develop part of the property, whether this involves transfer of ownership of all or part of the produced work.

It is not uncommon to see a software house or a computer manufacturer outsources the maintenance or part of their development to offshore subcontractors (in Eastern Europe, India, China, etc.). In such a case it is important to be able to show evidence of the state of the IT property via an external validated deposit, both at the moment of transfer to the subcontractor and the return of the updated work to the contractor, even if the contractor retains full ownership of the property and the updates.

If and when a subcontractor goes out of business, it is often the case that the Liquidator or the assignees are not able to clearly identify the ownership of the components between the various parties. This will deter a rescuer from taking over maintenance and ongoing development of the property or from acquiring the subcontractor's business and potentially hiring the appropriate developers. This is always to the detriment of the End User.

A licence agreement may include a provision allowing the End User to receive a copy of the "Sources" or parts thereof that are necessary for integration or complementary development purposes (without transfer of ownership). This is particularly the case when the licensed software is itself a development tool. It is therefore important to be able to show evidence of the state of the source code at the moment of transfer to the Licensee. This transfer can be done via LOGITAS who will keep a copy as evidence and will testify in writing to its state.

On the other hand, an End User who funds an entire outsourced development project will normally require full ownership transfer for the simple reason that he contributed to the design and specification of the IT property by providing part of his professional knowledge and he does not want that knowledge to be disclosed to a competitor, thereby retaining the maximum benefit from his investment. The Deposit will identify and preserve the exact state of the software at handover.

Worldwide protection offered by a LOGITAS Deposit:

In the case of civil or penal legal proceedings, the actual court and attorneys will be appointed depending on the geographic location of the Depositor and/or other party, and the nature of the dispute. It may also be the case that the competent court will have been previously specified in a related contract agreement.

On the other hand the physical location of the deposit is immaterial. Whether it is stored in France, the United States, Japan or elsewhere, what is at stake is the technical content. The value of a deposit as a body of evidence lies in its technical content, not where it is deposited.

So independent of the jurisdiction, problem or nature of the litigation, the prosecuting lawyer will always need a strong software deposit as a technical foundation on which to make his case. The purely technical nature of the LOGITAS Deposits means they are available and applicable worldwide.

This is how a French company obtained $ 150 million damages in a New-York court in 1999 from an US one who unfairly sued them for forgery, presumably intending to stop their growing business in the United States. Within the frame of that litigation, LOGITAS released 7 years of stockpiled deposits of this French company, accompanied with the relevant LOGITAS Deposit Certificates, accurately describing the content of the successive deposits, the corresponding technical development environments and the detailed verifications performed on each deposited version.

The body of evidence the LOGITAS deposits contained proved to be sufficient to allow the New York Court to determine the genuine owner of the software and to conclude that the US company was bringing an unfounded case. It led it to negotiate rather than pursue a long and risky appeal.