Years ago I had already blogs about escrow agreements. The conclusion of escrow agreements (escrow agreements for the source code of software) is often justified by clients with the with the desire to reduce their dependence on IT companies. In the the assets of the IT company are declared insolvent or the IT company is or the IT company is no longer able to maintain the software for other reasons to maintain the software (i.e. to update it), the client should receive the decompiled code of the software, together with the "rights to use the software". to the software.
I. Old reasons against escrow agreements
The legal admissibility of such agreements of such agreements is highly controversial as a result of several decisions by the BGH highly controversial. One of the main reasons for concluding escrow agreements deposit agreements is to protect the client from insolvency. However, precisely this reason may not be stated as a condition in the escrow agreement. be mentioned as a condition in the escrow agreement.
Under normal circumstances, the the source code of the software and the transfer of the rights to use the rights of use would normally require the client to pay a lot of money to the contractor. would have to be paid. (According to the escrow agreement) but: The release of source code and source code and rights of use for the client is free of charge. free of charge. And: In the event of the insolvency of the IT company company, this puts the other creditors at a disadvantage.
This argument alone has already made deposit agreements worthless in my eyes. The companies that carried out the deposit have always argued that there has not yet been a published decision that expressly decision which expressly states that this provision of a deposit agreement is invalid agreement; however, there is also no court decision to the contrary, from which the opposite can be inferred. And believe me, if there were such a decision existed, it would be cited immediately by the depositories. be cited immediately.
The second point is factual: there is There is normally no technical documentation for the source code that would would "allow a third, knowledgeable programmer" to quickly familiarize themselves with the matrix of the software and develop it further. There are programming languages, that make completely separate technical documentation unnecessary, but this is this is not normally the case. And since most technicians are not the best best chroniclers of their own achievements, software cannot simply be simply "just like that" by another programmer.
II. New regulations for escrow agreements
A company from Southern Germany, which also carries out the registration of cars, also operates also operates on the market as a depository. The clients were offered additional services for the deposit, by means of which the software and quality of the software and the quality of the documentation for each new release. for each new release. This had led to much controversy.
Now I have learned from I have now received new regulations from various sources from this deposit that paint a completely different picture.
1) No insolvency as a reason for filing
The opening of the application for insolvency over the assets of the IT company is no longer a reason for the surrender of source code and editing rights. In my opinion correct in my opinion, because this would have led to the ineffectiveness of the deposit agreement would have been invalid.
2) Defective execution of the care contract
The reason given for the publication is now very often (and not only by the southern German company) the defective fulfillment the defective fulfillment of "the main contract", i.e. the software maintenance or maintenance contract.
I would not sign this formulation I would not subscribe to this generalization. Clear and measurable facts need to be so that people know what they are getting into. For example, the provision that the software will not be further developed over a longer period of time despite software has not been further developed and updated over a longer period of time; that the support has not worked over a longer period of time despite requests.
In addition, the regulation in its generalization can be challenged under the legal effectiveness of the GTC.
According to German law a GTC provision must be interpreted in such a way that the unfavorable case is also covered. should also be covered. If a company does not create does not create new releases or provide support over a longer period of time, insolvency may insolvency can also be the cause of the lack of performance. By means of a "catch all" clause, which covers all cases of inadequate performance by the IT by the IT company, however, a provision could have been agreed again which would have been agreed that would require the free transfer of source code and rights of use in the the event of insolvency.
3) Transfer of which rights?
It is also interesting to note that the rights of use for processing are not actually transferred within the scope of the escrow agreement, because the client does not receive more with the agreement than he already than he already has under the law. The escrow agreement states that the client receives the rights according to §§ 69d, 69e UrhG.
The Copyright Act always formulates always formulates in a second act which prohibition rights the rights holder is entitled to (§ 69c No. 1 to No. 4 UhrG). Without the consent of the rights holder, the source code may not be source code without the consent of the rights holder (§ 69c No.2 UrhG).
The law then shows the limits of the prohibition rights by stating that certain acts may also be carried out without may be carried out without consent (§ 69d UrhG) or cannot be prohibited at all. be prohibited at all. The making of a backup copy, for example, cannot simply be simply be prohibited, but is permitted to the client even without the consent of the permitted without the consent of the rights holder.
The right to edit the source code for the purpose of error correction (i.e. bug fixing), including decompilation is then permitted by law (and does not have to be be purchased by another contract) if the person carrying out the correction correction is an authorized user (i.e. has purchased the program) and there is no other way of correcting the error.
The transfer of rights therefore does not include the right to further development, but only bug fixing.
III. free transfer as creditor disadvantage
Because if the agreement does not give the customer more than he is already entitled to under law, the decisive argument for the ineffectiveness of the escrow agreement no longer applies. deposit agreement. The contract actually only gives the customer access to the decompiled source. And whether this is sufficient for the to qualify the escrow agreement as ineffective, I dare to doubtful.
IV Tips
1) For IT companies several points still apply:
a.) The release of the source code must be linked to precise and uninterpretable conditions. be made.
b.) Only the technical documentation documentation that is already being produced and no separate costs may be no additional costs may be incurred for the creation of the technical documentation. be incurred.
b.) Prohibitions must be agreed on the poaching and employment of programmers must be agreed. Normally normally, escrow agreements are not worth much because the know-how to the know-how for continuing the software is in the heads of the programmers. is in the heads of the programmers. Once the programmers have left the IT company, the software's the software is doomed to die. However, this is why the conclusion of every deposit agreement for the customer also always creates the the customer to poach the IT company's employees and then, in the second second step to make use of the escrow provisions.
2) From the perspective of the customer:
The only way to counter the problem of the lack of of escrow agreements, the only way was and is to conclude a purchase option with the with the IT company for the transfer of the rights to use the processing and source code. source code. If an appropriate sum is agreed for the service agreed, these provisions are insolvency-proof. The escrow agreements have long tried to circumvent and conceal this basically simple fact. disguise it.
The problem of of inadequate technical documentation of the source code can only be countered by measures that prevent the immediate departure of the programmers involved, for example by setting up a rescue company with other customers of the IT company, the purpose of keeping the company's employees employed for a while longer. for a while. The problem with this solution is the programmers themselves. If they would prefer to work for another company, it will not be possible to departure cannot be prevented.
