Open source and intellectual property
Author: Ilya Stechkin
We noticed that perhaps the most popular publication on our blog was material on patent wars (4,800 views), but a detailed story about how to write plugins for Fuel, to our surprise, caused much less interest (1000 views the first part and a little more than 2000 - the second).
Just in case, we inform you that since this month Fuel has officially become a means of deploying all of OpenStack .
')
But since the legal issues of the existence of open source take you more than the code itself, then we went to meet the wishes of the workers and decided to tell you about how copyright and patent law get along with open source.
Indeed, how can you avoid direct competition and do one thing in common not only for individual contributors, but for entire corporations involved in the open source development process? The answer should be sought in those “rules of the game” that guide all members of the community without exception. These “rules” are described not only by the internal policies of a project, but also by the license under which the final product is issued. For obvious reasons, in this article we will focus on issues that are directly related to OpenStack. For example, OpenStack (including Mirantis OpenStack ) is licensed under the Apache 2.0 license . What does it mean? Why did you choose this particular license? How to live with it?
Intellectual property refers to the result of creative work: be it an art book, a report or a program.
Speaking about intellectual property, it is necessary to consider three models of legal regulation: copyright, patent law and know-how. Why is copyright alone not enough? Because it regulates only the possibilities of owning, distributing and making changes to the code itself (and its accompanying documents, such as technical specifications, manuals, etc.) - source or object .
But after all, an idea that is implemented by means of a specific programming language may be more important than its implementation. How to protect, for example, the algorithm that underlies the program? For this there is a patent right.
There is still such a thing - “know-how”, but with the open code it gets on badly, so we will not dwell on this mode of protecting intellectual property. We only clarify that the “know-how” has value as long as “third parties” do not know about it. Moreover, the legal protection of “know-how” is possible only if the owner of the intellectual property took all possible measures (including introducing a trade secret regime in relation to the relevant objects of intellectual property) to prevent the “leakage”. But even in this case, domestic law enforcement practice does not guarantee success when trying to resolve in court a dispute with an employee who violated the relevant regime.
Copyright arises on its own. You do not need to take any steps to protect the result of creative work. As soon as you wrote something, the copyright came into force. Even subscribing is not required. True, without a signature to prove your authorship will be more difficult - may require various expertise. They will take money and time, and the result is not guaranteed. Meanwhile, authorship is the only thing that unconditionally belongs to you, the creator of the work. At least in Russia. In the United States, for example, copyright may belong to the corporation in which you work. In Russia, an employer, with a properly executed contract, receives only a set of so-called “related” rights, such as the right to copy, distribute, process, etc. In other words, the employer gets everything that allows you to earn money on the results of your creativity (and we, of course, consider engineering activity to be creative). But the “birthright”, the right to put your name under the work remains with you. The copyright is based on the Berne Convention , which declares the basic principles of its operation. European legislation (in particular Directive 2009/24 / EC of the European Parliament and of the Council of April 23, 2009 on the legal protection of computer programs ) ensures that technical progress continues, and therefore, for example, “the person having the right to use a computer program does not may be limited to conducting the necessary studies, research and testing of the functioning of the program, provided that such actions do not violate the copyright of the program. ” In the Russian legislation, similar norms are introduced by article 1280 of the Civil Code .
For an open source culture, copyright is the most important concept. The culture of engineering “hostel” is based on respect for the “right to name”: it does not matter whether it belongs to a company or a specific person - a code contributor. We will return to this issue below, when we talk about licenses.
As you already know (from the very article that inspired us on this opus ), patents can be used as an instrument of pressure from proprietary software manufacturers on open source communities. The fact is that patents protect algorithms, interfaces and devices. In relation to software, in accordance with Russian legislation, mechanisms of protection of inventions can be involved (in this case, an algorithm or a hardware-software complex can be considered as an invention) and industrial designs (an interface, for example, can act as an industrial design “appearance” programs).
Unlike copyright, patent law arises only after the complicated and expensive process of registering an invention or industrial design has been completed. That is why big companies invest time and big money in obtaining patents. For example, Apple, according to the US Patent Collection (database query: AN / apple), has more than 11 thousand (!) Patents. Small companies do not have such capabilities. Therefore, they can only rely on license protection and common sense.
Licenses are exclusive and non-exclusive. All “free licenses” are non-exclusive. Also licenses can be paid and free of charge. All “free licenses” are gratuitous. Another license classification option is permissive, weakly restrictive and severely restrictive.
The Apache 2.0 license with which we started the conversation is of the first type. Under this license, the user is allowed to use the software without any restrictions, reproduce it, create his own software products based on the code licensed in this way, and distribute both the source code and the derived software. Commercial use of a licensed product is permitted - this in principle makes possible a business related to OpenStack.
What is more important for a business is permission to provide its own additional guarantees regarding the program upon further distribution. This item allows you to create “added value” to our Mirantis OpenStack distribution kit (remove the bugs that are found in the “vanilla” release, increase security, stability, scalability), and also creates the legal basis for the work of our support service.
In this case, the user is prohibited to require guarantees from the licensor and to use the licensor’s trademarks (the licensor is the company that provides the product under license). In other words, if you have taken a product and use it to solve the tasks set before you, then do it at your own peril and risk. This circumstance allows you to sell those same guarantees that can not be required under license.
OpenStack - technology is free, but requires certain competencies to work effectively with it. Enterprises have a choice: to train their own IT specialists or to contact a company with expertise in OpenStack. In the first case, responsibility for the correct functioning of the solution created on the basis of OpenStack remains within the company, in the second - transferred to the contractor. The contractor, in turn, can ensure that the development created for the customer is included in the OpenStack ecosystem. This process is called contribution to upstream. The solution created on the basis of OpenStack, but not added to the upstream, in our company is called “Frankenstek”, emphasizing its unreliability and even danger. It was about the dangers of such decisions we talked about in the last post .
The user, within the framework of this license, also undertakes some obligations: to preserve copyright, trademark, patent notices; include a copy of the license in the product (a .LICENSE file is added to the root directory with the text, the template of which is available on the Apache Software Foundation website - see at the bottom of the page, accessible by reference); mark significant code changes (this is done in order to protect the reputation of contributors) and, of course, disclose the code - otherwise it would not be an open license.
So, OpenStack gets along comfortably with copyright, because the Apache 2.0 license allows each of the participants in the software creation process to declare themselves and, at the same time, protects the reputation of each contributor.
Patents, in principle, do not harm OpenStack. Moreover, if one of the contributing companies wants to introduce the patented technology into the project, the patent license comes into effect: the provision on the investor providing a simple non-exclusive license for the patented algorithms and technologies that he has included in the project. On Prakik, this means that if a contributor contributes his own proprietary algorithms to a program, he automatically provides all other project participants and subsequent participants with a simple non-exclusive license for these proprietary algorithms. A patent license is provided under the Apache 2.0 license.
The Apache 2.0 license, under which development related to OpenStack is carried out, is free and provides many unique business opportunities.
We noticed that perhaps the most popular publication on our blog was material on patent wars (4,800 views), but a detailed story about how to write plugins for Fuel, to our surprise, caused much less interest (1000 views the first part and a little more than 2000 - the second).
Just in case, we inform you that since this month Fuel has officially become a means of deploying all of OpenStack .
')
But since the legal issues of the existence of open source take you more than the code itself, then we went to meet the wishes of the workers and decided to tell you about how copyright and patent law get along with open source.
Indeed, how can you avoid direct competition and do one thing in common not only for individual contributors, but for entire corporations involved in the open source development process? The answer should be sought in those “rules of the game” that guide all members of the community without exception. These “rules” are described not only by the internal policies of a project, but also by the license under which the final product is issued. For obvious reasons, in this article we will focus on issues that are directly related to OpenStack. For example, OpenStack (including Mirantis OpenStack ) is licensed under the Apache 2.0 license . What does it mean? Why did you choose this particular license? How to live with it?
Intellectual property: what is it?
Intellectual property refers to the result of creative work: be it an art book, a report or a program.
Speaking about intellectual property, it is necessary to consider three models of legal regulation: copyright, patent law and know-how. Why is copyright alone not enough? Because it regulates only the possibilities of owning, distributing and making changes to the code itself (and its accompanying documents, such as technical specifications, manuals, etc.) - source or object .
But after all, an idea that is implemented by means of a specific programming language may be more important than its implementation. How to protect, for example, the algorithm that underlies the program? For this there is a patent right.
There is still such a thing - “know-how”, but with the open code it gets on badly, so we will not dwell on this mode of protecting intellectual property. We only clarify that the “know-how” has value as long as “third parties” do not know about it. Moreover, the legal protection of “know-how” is possible only if the owner of the intellectual property took all possible measures (including introducing a trade secret regime in relation to the relevant objects of intellectual property) to prevent the “leakage”. But even in this case, domestic law enforcement practice does not guarantee success when trying to resolve in court a dispute with an employee who violated the relevant regime.
Copyright
Copyright arises on its own. You do not need to take any steps to protect the result of creative work. As soon as you wrote something, the copyright came into force. Even subscribing is not required. True, without a signature to prove your authorship will be more difficult - may require various expertise. They will take money and time, and the result is not guaranteed. Meanwhile, authorship is the only thing that unconditionally belongs to you, the creator of the work. At least in Russia. In the United States, for example, copyright may belong to the corporation in which you work. In Russia, an employer, with a properly executed contract, receives only a set of so-called “related” rights, such as the right to copy, distribute, process, etc. In other words, the employer gets everything that allows you to earn money on the results of your creativity (and we, of course, consider engineering activity to be creative). But the “birthright”, the right to put your name under the work remains with you. The copyright is based on the Berne Convention , which declares the basic principles of its operation. European legislation (in particular Directive 2009/24 / EC of the European Parliament and of the Council of April 23, 2009 on the legal protection of computer programs ) ensures that technical progress continues, and therefore, for example, “the person having the right to use a computer program does not may be limited to conducting the necessary studies, research and testing of the functioning of the program, provided that such actions do not violate the copyright of the program. ” In the Russian legislation, similar norms are introduced by article 1280 of the Civil Code .
For an open source culture, copyright is the most important concept. The culture of engineering “hostel” is based on respect for the “right to name”: it does not matter whether it belongs to a company or a specific person - a code contributor. We will return to this issue below, when we talk about licenses.
Patent law
As you already know (from the very article that inspired us on this opus ), patents can be used as an instrument of pressure from proprietary software manufacturers on open source communities. The fact is that patents protect algorithms, interfaces and devices. In relation to software, in accordance with Russian legislation, mechanisms of protection of inventions can be involved (in this case, an algorithm or a hardware-software complex can be considered as an invention) and industrial designs (an interface, for example, can act as an industrial design “appearance” programs).
Unlike copyright, patent law arises only after the complicated and expensive process of registering an invention or industrial design has been completed. That is why big companies invest time and big money in obtaining patents. For example, Apple, according to the US Patent Collection (database query: AN / apple), has more than 11 thousand (!) Patents. Small companies do not have such capabilities. Therefore, they can only rely on license protection and common sense.
Licenses
Licenses are exclusive and non-exclusive. All “free licenses” are non-exclusive. Also licenses can be paid and free of charge. All “free licenses” are gratuitous. Another license classification option is permissive, weakly restrictive and severely restrictive.
The Apache 2.0 license with which we started the conversation is of the first type. Under this license, the user is allowed to use the software without any restrictions, reproduce it, create his own software products based on the code licensed in this way, and distribute both the source code and the derived software. Commercial use of a licensed product is permitted - this in principle makes possible a business related to OpenStack.
What is more important for a business is permission to provide its own additional guarantees regarding the program upon further distribution. This item allows you to create “added value” to our Mirantis OpenStack distribution kit (remove the bugs that are found in the “vanilla” release, increase security, stability, scalability), and also creates the legal basis for the work of our support service.
In this case, the user is prohibited to require guarantees from the licensor and to use the licensor’s trademarks (the licensor is the company that provides the product under license). In other words, if you have taken a product and use it to solve the tasks set before you, then do it at your own peril and risk. This circumstance allows you to sell those same guarantees that can not be required under license.
OpenStack - technology is free, but requires certain competencies to work effectively with it. Enterprises have a choice: to train their own IT specialists or to contact a company with expertise in OpenStack. In the first case, responsibility for the correct functioning of the solution created on the basis of OpenStack remains within the company, in the second - transferred to the contractor. The contractor, in turn, can ensure that the development created for the customer is included in the OpenStack ecosystem. This process is called contribution to upstream. The solution created on the basis of OpenStack, but not added to the upstream, in our company is called “Frankenstek”, emphasizing its unreliability and even danger. It was about the dangers of such decisions we talked about in the last post .
The user, within the framework of this license, also undertakes some obligations: to preserve copyright, trademark, patent notices; include a copy of the license in the product (a .LICENSE file is added to the root directory with the text, the template of which is available on the Apache Software Foundation website - see at the bottom of the page, accessible by reference); mark significant code changes (this is done in order to protect the reputation of contributors) and, of course, disclose the code - otherwise it would not be an open license.
findings
So, OpenStack gets along comfortably with copyright, because the Apache 2.0 license allows each of the participants in the software creation process to declare themselves and, at the same time, protects the reputation of each contributor.
Patents, in principle, do not harm OpenStack. Moreover, if one of the contributing companies wants to introduce the patented technology into the project, the patent license comes into effect: the provision on the investor providing a simple non-exclusive license for the patented algorithms and technologies that he has included in the project. On Prakik, this means that if a contributor contributes his own proprietary algorithms to a program, he automatically provides all other project participants and subsequent participants with a simple non-exclusive license for these proprietary algorithms. A patent license is provided under the Apache 2.0 license.
The Apache 2.0 license, under which development related to OpenStack is carried out, is free and provides many unique business opportunities.
Source: https://habr.com/ru/post/272405/
All Articles