Brother
Professional
- Messages
- 2,590
- Reaction score
- 533
- Points
- 113
James Bottomley of IBM Research, who maintains the SCSI and PA-RISC subsystems in the Linux kernel and previously chaired the Linux Foundation's technical committee, proposed a solution to the problem by potentially holding open source developers accountable for errors in the code or improper fixing of vulnerabilities.
The idea is to shift legal responsibility for errors in the source code from developers of open source projects to suppliers of final commercial products based on this code, i.e. shift responsibility from the one who develops the code to the one who makes money from this code. For example, if a company uses third-party open source code in its product and an error/vulnerability in this code led to damage to the user, then the manufacturer of the commercial software product transferred to the user, and not the developer of the open source library, should be responsible and compensate for the damage.
The transfer of responsibility is proposed to be implemented by attaching a clause to the license indicating an agreement to indemnify and protect development participants from any legal claims in the event of full or partial use of the source code provided under this license as a component or product in jurisdictions that impose additional obligations to maintain software products .
In current practice, to eliminate legal risks, it is enough to have the “AS IS” warning in the license, which states that the developer is not responsible for errors, does not give any guarantees for the functionality of the code and does not accept obligations to solve problems, and the consumer agrees to use code at your own risk. The lack of guarantees from developers stimulated the development of a business model based on paid technical support, which dominated the early development of the open source ecosystem.
As open source penetrated the industry and corporate interest in its use grew, the concept of influencing development through non-profit foundations began to develop - on the basis of a large project, a fund is created that receives funding for development from large companies, which in return are given the opportunity to join the supervisory technical council and participation in making collegial decisions on further development. The emergence of foundations transformed the attitude towards open source projects, which began to be perceived as a tool for the development of the technology industry, and not a chaotic haven for volunteers. The perception of responsibility for problems in open source has also changed - instead of protecting individual developers, the non-obligation clause began to be perceived as an opportunity to avoid responsibility for large companies creating open source products.
The disclaimer situation may change if the EU passes the Cyber Resilience Act, which imposes certain liability on software manufacturers who do not properly care about security and do not promptly eliminate vulnerabilities throughout the product life cycle. The bill affects commercial software manufacturers and, based on the work being done, will provide a special exception for software under open licenses, but there is no guarantee that a similar law without similar exceptions will not be passed somewhere in the future.
As an example of the risks associated with developer liability, a lawsuit initiated in the UK is also mentioned, during which the company Tulip Trading, which lost about $4 billion worth of bitcoins during a hack, requires the developers of the Bitcoin system to make changes to the blockchain code to recover the lost amounts. The lawsuit is filed against the developers of the toolkit code, not the Bitcoin network operators. The trial court rejected the claim based on the disclaimer clause in the license, but the review continued to the appellate court, which, apparently, will also dismiss the claim, but this time due to Tulip Trading's inability to prove ownership of the bitcoins claimed amount.
The idea is to shift legal responsibility for errors in the source code from developers of open source projects to suppliers of final commercial products based on this code, i.e. shift responsibility from the one who develops the code to the one who makes money from this code. For example, if a company uses third-party open source code in its product and an error/vulnerability in this code led to damage to the user, then the manufacturer of the commercial software product transferred to the user, and not the developer of the open source library, should be responsible and compensate for the damage.
The transfer of responsibility is proposed to be implemented by attaching a clause to the license indicating an agreement to indemnify and protect development participants from any legal claims in the event of full or partial use of the source code provided under this license as a component or product in jurisdictions that impose additional obligations to maintain software products .
In current practice, to eliminate legal risks, it is enough to have the “AS IS” warning in the license, which states that the developer is not responsible for errors, does not give any guarantees for the functionality of the code and does not accept obligations to solve problems, and the consumer agrees to use code at your own risk. The lack of guarantees from developers stimulated the development of a business model based on paid technical support, which dominated the early development of the open source ecosystem.
As open source penetrated the industry and corporate interest in its use grew, the concept of influencing development through non-profit foundations began to develop - on the basis of a large project, a fund is created that receives funding for development from large companies, which in return are given the opportunity to join the supervisory technical council and participation in making collegial decisions on further development. The emergence of foundations transformed the attitude towards open source projects, which began to be perceived as a tool for the development of the technology industry, and not a chaotic haven for volunteers. The perception of responsibility for problems in open source has also changed - instead of protecting individual developers, the non-obligation clause began to be perceived as an opportunity to avoid responsibility for large companies creating open source products.
The disclaimer situation may change if the EU passes the Cyber Resilience Act, which imposes certain liability on software manufacturers who do not properly care about security and do not promptly eliminate vulnerabilities throughout the product life cycle. The bill affects commercial software manufacturers and, based on the work being done, will provide a special exception for software under open licenses, but there is no guarantee that a similar law without similar exceptions will not be passed somewhere in the future.
As an example of the risks associated with developer liability, a lawsuit initiated in the UK is also mentioned, during which the company Tulip Trading, which lost about $4 billion worth of bitcoins during a hack, requires the developers of the Bitcoin system to make changes to the blockchain code to recover the lost amounts. The lawsuit is filed against the developers of the toolkit code, not the Bitcoin network operators. The trial court rejected the claim based on the disclaimer clause in the license, but the review continued to the appellate court, which, apparently, will also dismiss the claim, but this time due to Tulip Trading's inability to prove ownership of the bitcoins claimed amount.
