In reality, it is much more expensive not to have a software trust agreement. Our customers say it best: the tripartite contract works in the same way as the master agreements mentioned above, but this is a unique event. This means that there are not several registered developers or licensees. There is only one developer, a licensee and a trust account. Another agreement should be put in place to make another trust contract. In addition, trust agreements often require parties to engage in alternative dispute resolution procedures, such as arbitration or mediation, in the event of a dispute over the disclosure of the source code. An often controversial question is whether an exit event actually occurred. While the parties strive to clearly and completely define the triggers for the publication of the software in software licensing and trust contracts, the language of these agreements cannot be clear as to whether certain circumstances are considered publication events. As a result, the seller can almost always deny that such an event has occurred. The recent legal proceedings between Vemics, Inc. and Radvision, Ltd.
(Vemics, Inc. v. Radvision, Ltd., 07-CV-0035, 2007 WL 1459290 (S.D.N.Y. May 16, 2007) is a striking example. In this case, Vemics acquired a software license from First Virtual Communications (FVC) and the parties entered into a licensing agreement that requires the software to be placed in trust and released under certain sharing conditions. The parties also entered into a separate trust agreement with the iron Mountain fiduciary officer. FVC filed for bankruptcy on March 11, 2005 and Radvision took over the licensing and trust agreement with Vemics in the interests of FVC`s rights and obligations. Vemics asked Iron Mountain to release the source code in January 2006 and claimed that the bankruptcy of FVC was an exit event. It is interesting to note that Radvision submitted that the bankruptcy of FVC did not constitute a valid basis for the publication of the software, even though the parties generally enter into source code agreements to protect the customer`s interest in the software in the concrete event of the seller`s bankruptcy. More than two years have passed since Vemics requested publication, with the parties still disagreeing on whether the source code will ever be published.
Even though it is finally published, the long delay and costly legal battle has been an expensive investment for Vemics. The technology developer deposits the technology in an Iron Mountain trust account. In the event that the technology developer is no longer able to support the technology (or another pre-negotiated condition), we give the technology buyer what is held in trust for the technology buyer, either to find another supplier or to exploit the technology in his own home. In essence, fiduciary software is the deposit of software source code from a third-party trust agent, such as Iron Mountain. The source code is managed securely by a trusted and neutral third party to protect the developer`s intellectual property while keeping a secure copy for the licensee if something happens, z.B. if the vendor can no longer support the software. If this is the case, the licensee requests that the source code be released from the trust account and may maintain its active activity.