We make internal development as a software asset in five steps
Hi, Habr. My name is Vladimir Razuvayev, I am the head of the business consulting department. Our team is committed to helping customers understand and manage the value of software assets. In this post, I propose to talk about internal development, which in one way or another is in almost any company.
The text is divided into three parts. In the first one I will talk about five important steps to formalize such developments. This formalization will help not only to secure the company’s rights to these developments, but also to reduce the legal risks associated with the “interception” of software rights by former employees, as well as the economic risks of mis-accounting of software as an asset. From the second part, it will become clear what rights to a software product created for the company are directly owned by programmers. And in the third part I will explain why it is so important to properly execute the documents and what risks the developer may face.
')
The experience of the last three years shows how the attitude of companies towards internal development has changed. Even simple, created on the knee software, is perceived as a kind of entity that has its own value. In some companies, the value of internal development has also increased under the influence of the import substitution policy: for them, software written by their own team of programmers is an alternative to foreign products, often already quite close to them in terms of functionality. Be that as it may, organizations are striving to formalize internal developments - we see this in the number of relevant appeals to our department.
By formalization, we mean first of all the proper documentation of the created result of intellectual activity. It should be clearly understood that, in accordance with the current legislation, the copyright on a computer program arises from the moment of its creation by virtue of the very fact of its creation. It is true that if an employee working for a labor contract organization develops a software product for a company, then this software product should belong to the company, since this is his job, and it is for this that he receives wages and other types of compensation (bonuses and other compensatory payments). However, it is extremely important to understand that two things are distinguished in copyright - copyright (intangible) and so-called. exclusive right (substantive law, right to dispose of the object of copyright). And if copyright arises by virtue of creation and belongs to the individuals who created the product, then the “material” right is subject to fine-tuning of documents. The mechanism for protecting internal development is included in five steps.
Step one. Within the framework of an employment contract, formalize the functions of employees and emphasize that the duties of an employee include the development of official works, computer programs, databases, etc. Also check the employment contract that has already been signed by the parties - this may be a sample document in which items on the development of official works may not be specified. In this case, enter into an additional agreement with the developer, which should focus on the functional tasks of the specialist, as well as prescribe the ownership of the company's exclusive rights to the employer. Also in the contract must be specified the procedure for payment of royalties for established computer programs. Author's remuneration may be included in wages, bonuses, or other types of material incentives.
Step two. Always make a service task for the development of computer programs. Strictly speaking, any development should begin with it. The service task is prepared in free form. It contains the objectives of a specific project, the development of which is planned to begin, as well as some brief description of the functionality or tasks that the created application will solve. It is perfectly ideal if the service tasks will be prepared for specific modules of the solution being developed and contain a complete and clear technical task for each module. If there is no such document, it is recommended to develop it for current projects, or to compose a new one for the development of a previously developed product, in which the ownership of the company's exclusive rights should be additionally prescribed. We simplify our customers' lives and offer them ready-made templates, but you can write in free form.
Not terrible, if you did not make a service task at the previous stages of development. Your product is probably being finalized, and starting the practice of assignments makes sense as the product develops. In this case, formulate the task so that it is clear from the context: it is the existing solution that is being developed, which was previously worked on, that is being finalized. If the official tasks were somehow formulated, it would be useful to conduct their audit, either independently or with the help of a consultant involved. This will make it possible to understand whether everything is in order with the documents, if not, then put them in order. You need to understand that your own software, which has no documents, will be perceived by the inspection bodies as pirated. And these are unnecessary risks that any company needs.
Step three. Make it so that the developer (if he is alone) or the team leader (if you have a development department) prepare you a memorandum on the performance of the service task. It contains information about the functionality of the developed module, or about the functionality of the product as a whole. Also in circulation should be the thesis that the software product is ready for operation. In fact, the memo document documents the fact of fulfillment of the service task and is an analogue of the act of reception and transmission.
Step Four. On the basis of a memorandum, a specially appointed commission analyzes the possibility of accepting a software product in test or industrial operation, after passing which, on the basis of the acceptance certificate, an order is formed for organizing the transfer of this software into commercial operation.
Step five. After the order of the organization that the product was put into operation, an order should be prepared on putting the software on the balance sheet, determining its initial cost, useful life, etc. How to do this? It is necessary to create an expert council that, as part of the discussion of software functionality, will issue recommendations and estimates related to the cost of the software. Recommendations of experts are best formulated in the form of a protocol, which should then be transferred to the accounting department. The initial cost is determined independently by the developer and most often includes direct costs directly. Do not overstate the cost of software, because after accounting, the company will have to pay taxes, which will depend on the initial cost. Detailed rules for the formation in accounting and financial statements of information on intangible assets of organizations are set by PBU 14/2007 (Accounting Regulation “Accounting for Intangible Assets”, annex to the order of the Ministry of Finance of the Russian Federation of 27.12.2007 No. 153).
So, for internal development to be fully formalized, it must be protected by the following documents:
1. Service Task
2. Report on the assignment
3. The act of acceptance of the software product for use in the company
4. Order on putting the software on the balance sheet
Sensibly and correctly conducted the process of formalization turns internal development into a software asset. In legal and accounting terms, this results in an intangible asset that increases the capitalization of the company. Despite its intangible status, a software asset has a lot in common with ordinary assets, but, above all, it is its value. A company can earn, for example, by transferring non-exclusive rights to a software product to other companies / users or use it in an organization, optimizing the costs of tasks that have not previously been automated, reducing labor costs for their implementation. If this development is an expensive product, it will significantly increase the capitalization of the company.
On Habré, the question of the importance of registering applications with Rospatent was repeatedly raised. In my opinion, this is highly desirable, since the evidence of Rospatent does not describe the software product as such, but the totality of its characteristics that determine its value to the user. By investing money and time in the protection of the application, you can to some extent protect your development from repetition. Important: during registration, Rospatent makes a formal examination of the application received, but does not make a detailed examination of the software product. Therefore, the correct preparation of an application for intellectual protection of a software product is really another story. In this case, I note that in accordance with the current legislation of Russia, state registration of a computer program is not mandatory. That is, one cannot say that if you do not register a computer program with Rospatent, you will not be able to protect your rights to it, because, I repeat, copyright arises by virtue of creating a product, and not by virtue of its registration anywhere It was.
This is a very frequent question from programmers: “What benefit do I, as a creator, get from the formalization of an application I have written?” Most likely, it does not carry any cash benefits with itself, since the creator has already received a reward for the work done, and he no longer has any property rights to the software written by him. Non-property rights allow you to entertain your own ego and add a project to your portfolio. For example, the author of the development has the right to suggest the name of the software himself, to allow him to indicate his name in the context of the application. But keep in mind that the right to indicate the name of the author, or not to indicate it, is also governed by the above-mentioned employment contract. I will also note that non-property rights extend to several people, that is, the product may have several authors.
Please note that if at the development stage, or within three years after, the employer announced that the software product is a commercial secret, it is prohibited to disclose any information about the software.
My colleagues and I often have to deal with a situation where the owner or top managers of customer companies do not even know what software and for what purposes the development team created. We receive information about such software at the very first stage of the Software Asset Management procedure, when special tools scan servers and PCs in the company-customer. Having found such “artifacts”, we, together with responsible employees, raise the necessary documentation and at least understand that we are facing an internal development.
Imagine the situation that a company comes to the test, which reveals an incomprehensible "left" software, for which there is no documentation confirming its licensing. The excuse “our programmers have developed this” in this case does not work, we need supporting documents. Without them, companies may face the withdrawal of hardware and software until clarification of circumstances. Probably, the company will sooner or later prove that this software is their own development, but the effort and time spent on this is not comparable to the risks for business continuity that the company may incur. Such is the horror story instead of the conclusion.
If you have any questions - write in the comments, I will try to answer.
The text is divided into three parts. In the first one I will talk about five important steps to formalize such developments. This formalization will help not only to secure the company’s rights to these developments, but also to reduce the legal risks associated with the “interception” of software rights by former employees, as well as the economic risks of mis-accounting of software as an asset. From the second part, it will become clear what rights to a software product created for the company are directly owned by programmers. And in the third part I will explain why it is so important to properly execute the documents and what risks the developer may face.
')
The experience of the last three years shows how the attitude of companies towards internal development has changed. Even simple, created on the knee software, is perceived as a kind of entity that has its own value. In some companies, the value of internal development has also increased under the influence of the import substitution policy: for them, software written by their own team of programmers is an alternative to foreign products, often already quite close to them in terms of functionality. Be that as it may, organizations are striving to formalize internal developments - we see this in the number of relevant appeals to our department.
Five steps to formalize internal development
By formalization, we mean first of all the proper documentation of the created result of intellectual activity. It should be clearly understood that, in accordance with the current legislation, the copyright on a computer program arises from the moment of its creation by virtue of the very fact of its creation. It is true that if an employee working for a labor contract organization develops a software product for a company, then this software product should belong to the company, since this is his job, and it is for this that he receives wages and other types of compensation (bonuses and other compensatory payments). However, it is extremely important to understand that two things are distinguished in copyright - copyright (intangible) and so-called. exclusive right (substantive law, right to dispose of the object of copyright). And if copyright arises by virtue of creation and belongs to the individuals who created the product, then the “material” right is subject to fine-tuning of documents. The mechanism for protecting internal development is included in five steps.
Step one. Within the framework of an employment contract, formalize the functions of employees and emphasize that the duties of an employee include the development of official works, computer programs, databases, etc. Also check the employment contract that has already been signed by the parties - this may be a sample document in which items on the development of official works may not be specified. In this case, enter into an additional agreement with the developer, which should focus on the functional tasks of the specialist, as well as prescribe the ownership of the company's exclusive rights to the employer. Also in the contract must be specified the procedure for payment of royalties for established computer programs. Author's remuneration may be included in wages, bonuses, or other types of material incentives.
Step two. Always make a service task for the development of computer programs. Strictly speaking, any development should begin with it. The service task is prepared in free form. It contains the objectives of a specific project, the development of which is planned to begin, as well as some brief description of the functionality or tasks that the created application will solve. It is perfectly ideal if the service tasks will be prepared for specific modules of the solution being developed and contain a complete and clear technical task for each module. If there is no such document, it is recommended to develop it for current projects, or to compose a new one for the development of a previously developed product, in which the ownership of the company's exclusive rights should be additionally prescribed. We simplify our customers' lives and offer them ready-made templates, but you can write in free form.
Not terrible, if you did not make a service task at the previous stages of development. Your product is probably being finalized, and starting the practice of assignments makes sense as the product develops. In this case, formulate the task so that it is clear from the context: it is the existing solution that is being developed, which was previously worked on, that is being finalized. If the official tasks were somehow formulated, it would be useful to conduct their audit, either independently or with the help of a consultant involved. This will make it possible to understand whether everything is in order with the documents, if not, then put them in order. You need to understand that your own software, which has no documents, will be perceived by the inspection bodies as pirated. And these are unnecessary risks that any company needs.
Step three. Make it so that the developer (if he is alone) or the team leader (if you have a development department) prepare you a memorandum on the performance of the service task. It contains information about the functionality of the developed module, or about the functionality of the product as a whole. Also in circulation should be the thesis that the software product is ready for operation. In fact, the memo document documents the fact of fulfillment of the service task and is an analogue of the act of reception and transmission.
Step Four. On the basis of a memorandum, a specially appointed commission analyzes the possibility of accepting a software product in test or industrial operation, after passing which, on the basis of the acceptance certificate, an order is formed for organizing the transfer of this software into commercial operation.
Step five. After the order of the organization that the product was put into operation, an order should be prepared on putting the software on the balance sheet, determining its initial cost, useful life, etc. How to do this? It is necessary to create an expert council that, as part of the discussion of software functionality, will issue recommendations and estimates related to the cost of the software. Recommendations of experts are best formulated in the form of a protocol, which should then be transferred to the accounting department. The initial cost is determined independently by the developer and most often includes direct costs directly. Do not overstate the cost of software, because after accounting, the company will have to pay taxes, which will depend on the initial cost. Detailed rules for the formation in accounting and financial statements of information on intangible assets of organizations are set by PBU 14/2007 (Accounting Regulation “Accounting for Intangible Assets”, annex to the order of the Ministry of Finance of the Russian Federation of 27.12.2007 No. 153).
So, for internal development to be fully formalized, it must be protected by the following documents:
1. Service Task
2. Report on the assignment
3. The act of acceptance of the software product for use in the company
4. Order on putting the software on the balance sheet
Sensibly and correctly conducted the process of formalization turns internal development into a software asset. In legal and accounting terms, this results in an intangible asset that increases the capitalization of the company. Despite its intangible status, a software asset has a lot in common with ordinary assets, but, above all, it is its value. A company can earn, for example, by transferring non-exclusive rights to a software product to other companies / users or use it in an organization, optimizing the costs of tasks that have not previously been automated, reducing labor costs for their implementation. If this development is an expensive product, it will significantly increase the capitalization of the company.
On Habré, the question of the importance of registering applications with Rospatent was repeatedly raised. In my opinion, this is highly desirable, since the evidence of Rospatent does not describe the software product as such, but the totality of its characteristics that determine its value to the user. By investing money and time in the protection of the application, you can to some extent protect your development from repetition. Important: during registration, Rospatent makes a formal examination of the application received, but does not make a detailed examination of the software product. Therefore, the correct preparation of an application for intellectual protection of a software product is really another story. In this case, I note that in accordance with the current legislation of Russia, state registration of a computer program is not mandatory. That is, one cannot say that if you do not register a computer program with Rospatent, you will not be able to protect your rights to it, because, I repeat, copyright arises by virtue of creating a product, and not by virtue of its registration anywhere It was.
What can an ordinary developer expect?
This is a very frequent question from programmers: “What benefit do I, as a creator, get from the formalization of an application I have written?” Most likely, it does not carry any cash benefits with itself, since the creator has already received a reward for the work done, and he no longer has any property rights to the software written by him. Non-property rights allow you to entertain your own ego and add a project to your portfolio. For example, the author of the development has the right to suggest the name of the software himself, to allow him to indicate his name in the context of the application. But keep in mind that the right to indicate the name of the author, or not to indicate it, is also governed by the above-mentioned employment contract. I will also note that non-property rights extend to several people, that is, the product may have several authors.
Please note that if at the development stage, or within three years after, the employer announced that the software product is a commercial secret, it is prohibited to disclose any information about the software.
Why is paper work important?
My colleagues and I often have to deal with a situation where the owner or top managers of customer companies do not even know what software and for what purposes the development team created. We receive information about such software at the very first stage of the Software Asset Management procedure, when special tools scan servers and PCs in the company-customer. Having found such “artifacts”, we, together with responsible employees, raise the necessary documentation and at least understand that we are facing an internal development.
Imagine the situation that a company comes to the test, which reveals an incomprehensible "left" software, for which there is no documentation confirming its licensing. The excuse “our programmers have developed this” in this case does not work, we need supporting documents. Without them, companies may face the withdrawal of hardware and software until clarification of circumstances. Probably, the company will sooner or later prove that this software is their own development, but the effort and time spent on this is not comparable to the risks for business continuity that the company may incur. Such is the horror story instead of the conclusion.
If you have any questions - write in the comments, I will try to answer.
Source: https://habr.com/ru/post/323124/
All Articles