Bruce Perens, advocates a review of the concept of Open Source
Los endless problems with open source licenses and the constant complaints by developers about the abuse of those who use their developments for commercial projects, are two of the problems that most have begun to have an impact on the community from open source developers.
Here on the blog, We have already shared various news and opinions on these topics, just like the proposal of ttransfer responsibilities to projects about vulnerabilities that may arise in the code they use from other projects, as well as constant complaints about the little financial support, among others.
And now, in more recent news, recently Bruce Perens, one of the authors of the definition of "Open Source" and co-founder of the initiative, has rekindled the flame of “open source Post” and has called for a rethink of the idea of an evolution or revision of the open source software development paradigm.
According to Perens, current open source licenses do not offer enough protection and therefore today we see more and more open source developers airing their complaints, That is why it proposes a new model that includes contractual conditions to improve relations between developers and commercial companies.
"First of all, our licenses no longer work," he said. “We have had enough time for companies to have found all the loopholes and therefore we need to do something new. The GPL is not acting as it should have when a third of all paid Linux systems are sold with a GPL circumvention. That's RHEL.
Bruce Perens points out that the General Public License (GPL) was originally designed only as a license and not a contract, allowing companies to bypass its requirements and limit the redistribution of source code. Perens suggests a new model that incorporates contractual elements to address these legal loopholes and in this way ensure or force (basically) those who abuse it, to carry out the correct retroactive action for open source software developers.
«What comes after open source should be called something else. You should never try to pass yourself off as open source.” He is still searching for a more appropriate term than “post open.”
A clear example which illustrates a situation in which companies, when “using” projects and/or developments with open source software licenses, is that they abuse certain strategies to limit the redistribution of source code, despite the provisions of open licenses, such as the GNU General Public License (GPL).
In the case of Red Hat Enterprise Linux (RHEL), it is mentioned that customers sign agreements with Red Hat to receive support and updates. These agreements may include clauses limiting the redistribution of data, and mention the right to terminate the agreement if the installed and purchased copies of RHEL do not match. This creates a situation where customers are faced with a choice between the freedom to use the software and maintaining their status as a Red Hat customer.
Additionally, it is noted that the patches provided for RHEL that eliminate vulnerabilities apply to GPL code, giving users the right to distribute them according to the provisions of the license. However, this distribution may be perceived as a violation of the contract with Red Hat, which could lead to the termination of services provided by the company.
This example highlights how companies can use certain legal loopholes or contractual provisions to restrict the redistribution of source code, despite the freedoms provided by open source licenses. These types of practices can create tensions between the provisions of open source licenses and the specific contractual agreements that companies establish with software vendors.
In this new approach, it is proposed that companies pay for the benefits derived of commercial use of open source software, either participating in the development or paying royalties. The possibility of using an annual certification is being considered, after which companies would obtain rights to use the software. The transferred funds would stimulate development and allow developers to spend time creating applications convenient for end users.
Among the highlighted challenges is the need to establish an organization that studies contributions to development and distributes funds in a transparent and fair way for developers. Successful implementation of this Post-Open Source model would require careful consideration of these organizational and financial aspects.
Source: https://www.theregister.com