MontaVista Software has upgraded its community website for embedded Linux developers with a variety of new open source components. & Meld 2.0& features a new Meld.org URL, a redesigned interface, rich text editing in forums, improved file sharing, and a new OpenID login system, all running on the Drupal open source content management platform, says the company….
I’m excited to debut the Compliance Blog with a launch announcement of The Linux Foundation’s Open Compliance Program. The program was kicked off formally with Executive Director Jim Zemlin’s keynote at LinuxCon in Boston but has been gestating for months.
We’ve pulled together multiple services and products to ease the task of open source license compliance: training, white papers, tools, a self-assessment checklist, a community forum, a compliance data exchange standard, and a directory of corporate compliance contacts to enable rapid response to compliance inquiries. The end goal is to encourage even more adoption of open source by making compliance more efficient and less daunting to achieve.
In a nutshell, we’ll be offering the following resources:
Some of these services and products will be made available immediately, such as the tools and the Compliance Directory. The training classes will be offered starting September 1, the Self-Assessment Checklist during Q4. Please consult our Compliance website for forthcoming announcements and, of course, stay tuned to this blog for word about availability.
As Director of the Open Compliance Program, I’ll be blogging here about compliance topics of common interest: the role of the Open Source Review Board; diligence to require of third party suppliers to back up their open source disclosures; what methods of sharing software trigger license obligations; and so on. I hope that the readers will weigh in with their opinions and expertise. There’s a basic paradox we can overcome collectively: Compliance officers could benefit greatly by exchanging perspectives and approaches, but their companies often squelch any discussion of compliance standards or hint of compliance problems. The Open Compliance Program will serve as a neutral and trusted resource to aggregate data about compliance approaches and issues, and share information in a manner that preserves company confidentiality.
I welcome your input on ways to make the Open Compliance Program useful and hope you’ll help build a compliance community that benefits our common enterprise.
Last month we tested out Intel’s new GLSL compiler for Mesa when running the ATI Radeon classic Mesa and Gallium3D drivers to see how this GL Shading Language compiler designed by Intel employee’s for their hardware and open-source driver work for the other open-source drivers, since all of the Mesa drivers will be affected once this “GLSL2” compiler is merged into the Mesa code-base by month’s end. The experience using Intel’s new shader compiler with the ATI Radeon graphics driver worked fine except for Warsow where serious regressions were visible, but in the other games that are capable of running off Mesa, the experience was fine. What we have been curious to test since then with this new OpenGL shader compiler has been the LLVMpipe driver — a Gallium3D driver we have been very excited about as it finally provides a better software rasterizer for Linux by leveraging Gallium3D and the Low-Level Virtual Machine (LLVM) compiler infrastructure for accelerating the Mesa state tracker atop a modern multi-core CPU that supports SSE4 instructions. We have now finished running tests of the Intel’s GLSL2 branch with the most recent LLVMpipe driver code.
The idea of creating a free (as in beer) and open cinema camera based on an Elphel 333 started in spring 2006 in the mind of a member of the DVinfo forum, who in March 2006 started a new thread called “High Definition with Elphel model 333 camera.” A lot of people got involved, and the project grew and developed.
Couchio has announced an early developer preview of its implementation of CouchDB on Android
We’ve always been fans of the odd form factor espoused by Motorola’s longstanding Ming series of devices in China — a form factor seen only briefly in the US with Verizon’s Krave — and now that Moto’s made the leap to Android across its global smartphone lineup, it makes sense to move the MING from custom-cooked Linux to Android, too. The A1680 has been floating around in the wild since back in April of this year, but Motorola’s MOTDEV site for developers has now spilled the beans on all the crucial specs. Strangely, there are some basics missing like proximity and ambient light sensors — usually must-haves for touchscreen devices — and the 624MHz PXA935 core should doom it to the lower end of the performance spectrum, but at least it can scale up to 32GB of add-on storage and you’ve got a WVGA display at your disposal. Hey, Moto, if you’re listening: we still think this kind of design is pretty cool, in the odd chance you’re game to give Westerners another shot at it.
In a presentation at LinuxCon, Brad Spengler said his efforts to expose weaknesses in Linux has helped make the software more secure.
A LinuxCon session led by Red Hat’s Matthew Garrett discussed the lessons learned from Google’s ongoing attempts to include power-management code in the mainline Linux kernel… and revealed there’s still some emotions running high in the debate.
If there was any doubt that feelings are still running high regarding Android code’s inclusion into the mainline Linux kernel, those doubts were quickly dispelled when Red Hat developer Matthew Garrett asked an audience member to leave the room as an argument began brewing between that audience member and another during the Q&A session of Garrett’s talk at the 2010 LinuxCon in Boston today.
Garrett’s talk “Android/Linux Kernel: Lessons Learned,” outlined the 18-month saga surrounding the attempted inclusion of Android power-management code into the Linux kernel–a saga that to date still has the code outside the kernel proper.
Garrett, whose field of expertise is power management at Red Hat, nonetheless admitted that when he first saw the patch submitted by Android, he didn’t even know what the patch was trying to fix and what specific functions were being called in the patch. New undefined terms, such as “wakelock” and “earlysuspend,” were intermixed in the original January 2009 patch submittal to the mainline kernel, making the patch very hard to understand.
It wasn’t just technical problems with Google’s submittal, Garrett explained. There were questions about the very motivation of the patch: with the undefined terms, kernel developers were unsure what problem was being addressed and if the problem would even apply to the Linux kernel as a whole.
Faced with these obstacles, the patch was resubmitted twice more in February 2009, with changes that answered some of the initial questions about the patch, but not all.
A bulk of Garrett’s talk centered around the technical aspects of the patch itself, namely the aforementioned wakelock and earlysuspend functions.
Wakelock, in a nutshell, is a solution used by Android to avoid a possible race condition (which can derail the scheduling of internal software/hardware events in a device) due to conflicting events around power management. The problem stems, Garrett said, from the fact that the Android platform’s application development is so open, which has the advantage of attracting many more app developers, but (at times) the disadvantage of getting apps on devices that might be less than optimal.
From the power management perspective, the Android approach is to assume that apps are not to be trusted and controls are put in place to stop the processes of any app that runs out of control with CPU resources and thus overly drains the battery. But having the system ultimately have control of power management can lead to those race conditions: what happens, for instance, when a phone call comes in just as the system decides to suspend itself?
According to Garrett, as that point, a wakelock can intervene and let the device take phone call, and then upon the user hanging up, release the system so it can go back to sleep. earlysuspend, he added, is a similar way to keep a system properly “awake” even if the screen is shut down for battery conservation.
The problem with this approach, from the Linux kernel developers’ point of view, was that such an inclusion into the Linux kernel would require modification of any driver that generates wakeup function calls, and the wakelock patch would not benefit any platforms that weren’t wakelock aware. Also, many kernel developers perceive this kind of power-management issue as being something for userspace to take care of, and thus were resistant to having the kernel solving what they thought was an application issue.
After over a year of sometimes heated discussion on the kernel mailing lists, the Android and Linux kernel teams agreed to meet at the most recent Linux Collaboration Summit in April 2010, which in turn led to another patch submitted in May.
Garrett outlined the lessons that should be learned by both sides of the argument.
For contributors, it’s important that patches are submitted with a clear understanding of that the patch is supposed to do or fix. Terms within the patch should be well-defined and documented. Also, patches with multiple functions mixed within should be avoided. Single patch, single function is preferred.
Garrett also recommended that getting complex patches such as this accepted is a lot easier when there’s a recognized name associated with the patch. If there are questions, major patches coming from relative unknowns can be misperceived as someone’s error rather than being taken seriously.
Taking these lessons to heart, Garrett said, is a constructive way to build upon even perceived misfires such as this.
As for Android’s patch, a minimal solution has been introduced to the mainline, but their proposed changes are still pending.
One of the most novel and differentiating features of a UNIX system is its command line. With just a few keystrokes, including a bit of “glue”, you can use the command line to combine the finite set of UNIX utilities into innumerable, impromptu data transforms. These articles will teach you the basics of the UNIX shell and discover how you can use the command line:
(1) Command the power of the command line
(2) Do everything right from the command line
While complying with FOSS licenses is not overly difficult, it can be complex and many companies have asked for help ensuring that they don’t run afoul of license requirements. Today the requests have been answered.
More than 30 companies have joined with The Linux Foundation today to launch the Open Compliance Program (OCP), an initiative to help companies ensure that their products comply with the requirements of FOSS licenses. The program comprises a set of open source tools to enable compliance efforts, a self-assessment checklist, training and consulting services, and a directory of compliance officers at participating companies.
As Linux and FOSS use has increased in the commercial market, a few commercial programs have sprung up to help companies deal with license compliance issues. However, there’s been no industry standard for compliance issues or tools for companies that wish to handle compliance issues in-house. The Linux Foundation, with companies like IBM, AMD, Intel, Nokia, Google, and with the Software Freedom Law Center, has put together a tool-set and community to help deal with the common industry challenge of FOSS license compliance.
One of the most interesting features of the program is the compliance tools. Offered under the MIT license, the tools include a dependency checker, code janitor, and Bill of Material Difference Tool (BoM Diff). The dependency checker makes it possible to examine a project and provide an alert based on rules about a combination of licenses and linkage methods. The code janitor scans code for comments and provides a way for companies to ensure that the comments released with open source code don’t divulge product plans or other information that shouldn’t leave company walls.
The BoM tool is still scheduled for development beginning later in 2010. This will be a project that reports differences in bills of materials between versions to help companies with reporting and compliance between releases.
The Linux Foundation also points to several other tools developed prior to the launch of the OCP, including binary analysis tools to examine components that went into a product and FOSSology. FOSSology analyzes every file in a project for license information, which can be very useful for organizations including open source projects in their products or deploying them internally.
Finally, the OCP includes a self-assessment checklist so companies have a set of best practices for complying with FOSS license requirements.
The compliance program is being guided by the FOSSBazaar workgroup, which is developing a Software Package Data Exchange (SPDX) specification for organizations and projects to share information about licensing and copyrights associated with a project. The site for SPDX is available now and includes th specification and list of licenses for the tool, as well as usage guidelines.
Finding the right party at a company to discuss compliance issues can be a hassle for open source developers. Often it’s non-obvious inside a company, much less outside, who is responsible for dealing with open source licensing issues for a given company. As part of the OCP, The Linux Foundation is providing a compliance directory and rapid alert system so developers can quickly reach out to compliance officers. Signups for the directory are open, so any company can add its compliance officer or other responsible person to the directory.
All of the tools in the world, of course, are of limited value without the capacity to use them. While some companies are adept at working in the open source community, others are still getting their bearings. For companies that need help with the tools and practices, The Linux Foundation is offering training and consulting for organizations that want to learn how to ensure their efforts meet the requirements of FOSS licenses.
Companies interested in compliance and other issues around open source are also encouraged to join the FOSSBazaar community. FOSSBazaar is a community of practice for accelerating adoption of FOSS in the enterprise.
Complying with open source licenses is not difficult, but it does require some effort and the right tools. With the Open Compliance Program, the Linux Foundation and FOSSBazaar are ensuring that organizations have the tools they need.
