What should be deposited? This is the core foundation of the LOGITAS Escrow System. It is always possible to proceed, even with a weak agreement or inappropriate release procedure if the deposit is complete, well described and documented, even if only by interim ruling. On the other hand a proper Escrow agreement and correct release procedure will be of no use if based on a deposit which is too old, unusable or non-existent. The LOGITAS Escrow system is based on the following rules: Deposits are delivered to LOGITAS in duplicate and stored in two different locations. This enables LOGITAS to recover from the other deposit in case of fire, water damage, theft or any other destruction without requiring the Depositor's help, thereby maintaining the body of evidence efficiency and its associated legal value. Dual storage also permits recovery from the second copy in case of media damage. Deposit contents: The deposited elements alone must be sufficient to enable any competent engineer to gain control of the software in order to maintain it should the Depositor be in temporary or permanent maintenance default, under reasonable conditions and after a reasonable delay. The LOGITAS Escrow System allows an Escrow Agreement to cover a single software tool, component, application or library as a homogeneous asset potentially containing multiple versions, modules, databases, supported platforms and End User specific custom developments. The content of the future deposit is described in the Honor Declaration which will accompany it, whether this be an initial deposit or update, and will be its technical check-list and description. This honor declaration will be established as a draft by the LOGITAS Engineer with the Depositor engineers. It will include: a A summary of the deposited IT asset, specifying the deposited version, main modules and/or functionalities as listed in the End User licence(s), a The required Third-Party development and packaging tools and environments. These components are not owned by the Depositor and are used under license (commercial, open-source, freeware, etc.) The End user shall have to re-install them in order to restart maintenance by himself. a The list of deposited elements including source code, scripts, reference database dump and database creation scripts, initial parameterization and population scripts, other procedures, documentation, etc. This list will describe the deposit's organization. a The format of the deposit, including the chosen media, description of any backup/restore and compression tools, the chosen format as well as the required platform to read and install the deposit. Accumulation of new versions, releases, modules, platforms or even End User specific custom developments within the frame of a single LOGITAS Escrow Agreement. This allows the Depositor to protect, all the concerned End Users, independently of the platform, module, version, or specific custom development they are using, within a single centralized and regularly updated LOGITAS deposit. More and more frequently LOGITAS is asked to release one sample to the Depositor when for example an End User has to reply to a Tax Department or Regulating authority requirement to verify the concerned software is running correctly and to validate the output data (e.g. accounting, medical follow-up, banking regulations such as BAFI (France) or BALE II reporting, etc.). Even if older versions are no longer commercially available, they still may be submitted to verification by fiscal, banking or other authorities so they must remain in deposit. Note: In the case of maintenance default the best way to help an End User is not necessarily to deliver him the deposited source code since he is unlikely to have engineers with the requisite skill set on staff. However having a single repository for all the knowledge and development done by the Depositor will help the End User find a partner or potential acquirer to take on the maintenance and development, since they can evaluate the content and completeness of the deposited material and proceed with full knowledge of the facts. LOGITAS can also help to identify a provider sufficiently knowledgeable about the relevant development environment from amongst its Depositors. All major releases must be added to the Deposit. Except on specific customer request, it is unreasonable to ask a Depositor to update the deposit for each patch and/or minor release, however the LOGITAS Escrow system does allow the addition of the configuration management system database (CVS, Subversion, Visual Source Safe, Perforce, etc.) to the deposit on a more frequent basis. The deposit must contain all available development and maintenance documentation. This documentation is an essential part of the body of evidence of ownership of an IT property as well a necessity for its effective maintenance and durability. Nonetheless it is counterproductive to ask a software provider to reverse engineer missing or old documentation as it may stop the Deposit process and discourage the development team. On the other hand an initial deposit made on good faith will help clearly identify what documentation exists, and what procedures needs to be implemented in order to create, improve or augment that documentation. The initial deposit is not necessarily the most important for an End User. The most important is the one done at the latest date preceding a potential maintenance default. The documentation should contain the following: a Description and detailed installation procedures for the development, packaging and deployment environments, particularly when the deployment environment is outsourced by the End User to the Depositor or a Third Party provider (e.g. Extranet, ASP solution, outsourced administration and back up, etc.) a Internal naming rules, development standards and rules, architecture description, user guides for internal development and maintenance tools. These documents are required for any efficient code review and/or to train new engineers or interns on the software. a Build and packaging procedures (manual operations, scripts, .bat, .sh, makefiles, parameterization, etc.) to be executed to build the End User deliverable or flashable version from the deposited material alone. a The database documentation (Entity-Relationship diagram, physical model, table descriptions, etc.) a Existing functional and detailed specifications (although user guides are usually more up to date than the functional specification). a More generally, any documentation enabling an engineer who knows the development environment to understand the software and take on its maintenance within as short a timeframe as possible. The deposit must be subject to a basic set of verifications. At the very least the media legibility should be verified to ensure there are no problems due to any of the following : a missing or incorrect passwords a undefined compression or backup/restore environment and procedures a file attributes such as read permissions, owner, etc., a incorrectly parameterised CDROM or DVD writing tools a compressed long names , empty directories, etc. In any event an efficient validation procedure should include the procedure described above in § "On -the-spot Deposit Verification". Creating LOGITAS deposits usually lead depositors to a simple quality process (crash recovery back up for the current development team) which can be built upon to create more efficient and complete deposits over the years without overwhelming the developers with a huge one-off "administrative" task which will bring them no closer to hitting their short term deadlines. In many cases the deposit process helps Developers to automate back up and build procedure, clean the source code and the hard disk of unneeded or unused files , and to make an inventory of the existing documentation, etc. End User participation in the Logitas Verification With the Depositor's Formal agreement, the LOGITAS Escrow System allows the End User or Authorized Third Party, to attend the LOGITAS verification procedure. Said verification may occur in the Depositor or End User's offices. If the LOGITAS assignment is to check the completeness and consistency of the deposit from a technical point of view, the End User is much more apt to validate the functionalities he is expecting from the execution software built during the Verification process. Furthermore and when considering complex IT properties including hardware components, smartcards, black boxes, robotics etc. the End User will be in the ideal position to validate that the Deposit contains all the components as described in its functional requirements document or included in its acceptance procedure and checklist. When the Depositor does not want the End User or Authorized Third Party to attend the LOGITAS validation procedure, the latter may ask LOGITAS to carry out some specific complementary verification on his behalf. These complementary verifications will be provided in advance of the Verification by the interested party.
[mailto:contact@logitas.com]
[./equipe_uspag.html]
Contact : +33 (0)1 45 607 678 contact@logitas.com Our cell phones
[./telechargement_uspag.html]
Download PDF documentation
[./telechargement_uspag.html]
[./accueil_uspag.html]
[./accueilpag.html]
[./accueil_uspag.html]
[./equipe_uspag.html]
[./references_utilisateurs_uspag.html]
[./references_editeurs_uspag.html]
[./societe_uspag.html]
[./sys_def_uspag.html]
[./tarifs_uspag.html]
[./sys_cont_abo_uspag.html]
[./sys_contrats_uspag.html]
[./systeme_contractuel_uspag.html]
[./assistance_contractuelle_uspag.html]
[./sys_remise_dep_uspag.html]
[./dep_intermediaire_uspag.html]
[./dep_conserv_uspag.html]
[./dep_controle_uspag.html]
[./depot_contenu_uspag.html]
[./dep_conseil_uspag.html]
[./synthesedemarche_uspag.html]
[./qualite_uspag.html]
[./respon_civile_uspag.html]
[./valo_patrimoine_uspag.html]
[./protection_patrimoine_uspag.html]
[./protection_client_uspag.html]
[./enjeux_uspag.html]
[https://www.logitas.com/php/upload.php5]
[https://www.logitas.com/php/files.php5]
[https://www.logitas.com/php/files.php5]
[./accueil_uspag.html]
[Web Creator] [LMSOFT]