The GPL v3 Watch List is intended to give you a snapshot of the GPLv3/LGPLv3 adoption for October 18th to October 24th 2008.
Black Thursday, this day in 1929.
FOSS users are becoming increasingly apathetic regarding the proactive management of software obtained for nominal cost. The recent Debian example comes to mind, where for an extended period of time, OpenSSL within it had been modified with a code checking tool. Such modification removed a programmatic element important to the generation of the key, such that the total possible key combinations were effectively reduced to a fraction of the total unbroken possibilities. This problem existed for nearly two years, with countless users depending on the code, using vendor solutions to test for the same things, and yet this went undetected.
Our government is embracing FOSS publicly, yet I have heard horror stories. They do not understand the management requirements of software delivered without a vendor, yet they have the same expectations.
Without a defined and active process for the ongoing and diligent public management of software, our government could be stepping into FOSS unprepared. If their motivation is cost, they will under staff the management resources that should be diligently testing all software. While I hope that they are going to staff for increased management requirements in the use of FOSS, there is no assurance either way. What makes the situation even more difficult is that there is no clear process or method for the government to implement that will offer a high degree of quality in FOSS investments.
What is lacking is not the desire to check. The responsibilities tied to the development of a FOSS project no longer ends when the project is compiled. Quality assurance and validation steps are so critical to the ongoing build process that the community needs to be part of it. Commercial vendors do not release code until it has survived a series of tests. Commercial vendors have liabilities to protect their investment, and do so through structured testing and processes, since their money is better spent in quality assurance than in remediation and legal actions afterwards.
FOSS needs a repeatable, measurable, verifiable and public checklist of testing and processes performed by the community in a "trusted" manner to safeguard the code that we all depend on. A public forum allows all of us to check an application, see which tests have been performed and which have not, allows us to contribute to the process, and qualify the contributions of others.
While the code is transparent, who has the skills and ability to look at it with the depth and creativity required these days? We need to make the management and ongoing qualification of open source software a community effort. By having the community actively involved in all pieces of quality assurance, we will have a greater understanding for the complexity in certifying code for distribution, and we will be able to verify that such work has been done.
The answer is not just to engage professional services, or use open source software that is financially backed by a large vendor. Since we lack transparency into the detailed, complex and ever changing process for testing software components, we are better to choose commercial solutions with contracts that put liability on the vendor. Additionally, mitigating the unknown risk of the use of FOSS with service contracts undermines some of the core principles of FOSS. If our only solution is to engage services, our freedoms in the use of FOSS are being undermined due to our inability to use the community to grasp, understand, constrain and manage the problem.
NIST sponsors http://cwe.mitre.org, the Common Weakness Enumeration. It is a database for identifying and describing in a common language, programmatic and architectural weaknesses within software, hardware and operating systems. It provides a reasonable starting point from which to build processes upon.
If we use a public and transparent process for the certification of FOSS, continuing in the spirit of how the code was developed, the strength of the community can actively participate in the management of unknown risk in software. We as a community can impose basic qualitative requirements on software packages. This community involvement in the validation of the code is a natural progression of the popularity and ubiquitous nature of FOSS in our computing lives.
In conclusion, the solution for software quality assurance is in the control of the user community. We need a public process to define, manage and implement validation processes, as well as a community effort to invite an ongoing process to post those results. If our professional services suppliers are worthy of their role of managing open source usage, they should be actively posting their tests, their reviews, their reports. If they do not have the requisite skills to help us manage this problem, we need a better process, and better providers, to help us manage this challenge and it is not going to get any easier soon. We owe this to ourselves, the success and health of our financially strained businesses worldwide, and our national and international security to get this right.
If you are willing to copy and tranlate the content weekly, please let me know - you will receive the content as soon as it is available, and you site will be listed as a translation. I can send you a bit of tracking code so that you get credit for your contribution to the readership of this site
Post your link on the bottom of the blog page.
Send me a note at firstname.lastname@example.org that you are using some or all of the content
I will make sure that we host links to your sites, and we will be able to use your content within this site as well.
The Research Group actively takes submissions from visitors on updates on new GPL v3/LGPL 3 projects. We are amazed at the number of submissions we have gotten to date, but even more so, we are incredibly grateful to over 100 core contributors who have devoted their time and resources at helping us provide up-to-date information.
For more information, go to https://safeview.com/wp431/.
To stop receiving these weekly mailings, please send a message to email@example.com with the subject "unsubscribe:gpl3".
To start receiving these weekly mailings, please send a message to firstname.lastname@example.org with the subject "subscribe:gpl3".
Our Sponsor, Palamida, Inc.
The GPL3 project, sponsored by Palamida, Inc (http://palamida.com/ ), is an effort to make reliable publicly available information regarding GPLv3 license usage and adoption in new projects.
The opinions expressed within the GPL3 Information Blog are exlusively those of Ernest Park, the subjects interviewed and the contributing authors, and are not intended to reflect the positions of Palamida, Inc and its employees.
This work is licensed under a Creative Commons Attribution-Noncommercial-
Palamida was launched in 2003 after its founders learned first-hand what happens when companies don't have full visibility into the code base of their software applications based on Open Source Software. Their experiences inspired them to create a solution to streamline the process of identifying, tracking and managing the mix of unknown and undocumented Open Source that comprises a growing percentage of today's software applications. Palamida is the industry's first application security solution targeting today's widespread use of Open Source Software. It uses component-level analysis to quickly identify and track undocumented code and associated security vulnerabilities as well as intellectual property and compliance issues and allows development organizations to cost-effectively manage and secure mission critical applications and products.
Please mention the GPL3 site when you reach out to Palamida.
The Research Group (email@example.com)