Leading items

Sam Ramji: On the CodePlex Foundation and more

A few weeks back, we looked at the newly announced CodePlex Foundation. At the time, there were a few questions about the foundation and its plans. We asked Sam Ramji, interim president of the foundation—and, previously, Microsoft's senior director of platform strategy—to fill in some of the gaps. Below are his answers to our questions, ranging from the foundation's governance and plans, to his thoughts on Microsoft's open source strategy going forward, as well as information about his new company and its relationship to open source software.

LWN: I'd like to start by discussing the CodePlex Foundation, can you give us your high-level overview of the foundation and its mission? Is it meant to serve the open source community, software companies, or both?

LWN: As interim president, you, the board of directors, and advisory board are tasked with finding an executive director and permanent members for both boards. What time frame do you have for putting that all together? Will the adoption of a charter for the foundation be done in a similar time frame, or is that something that will be done by the new boards once they are in place? Will you be staying on as president after that or will that role fall to the new executive director?

LWN: There has been criticism of the make up of the initial boards, notably from Andy Updegrove (and follow-up), because they are Microsoft dominated. His contention that the appearance, at least, is that this is a Microsoft-focused foundation with little or no room for outside voices, and more importantly, the ability to act independently of Microsoft's wishes. Does that seem accurate to you? If not, why? What gives it the ability to act independently?

LWN: What are the criteria for finding new members for the board of directors and advisory board? Is one of the goals of the search process to increase the diversity (i.e. fewer Microsoft employees and/or voices from outside of the Microsoft sphere of influence) of those boards? If so, how might that be accomplished, or, if not, why?

LWN: Will the foundation be sponsoring particular projects, something like what the Apache Foundation does? What criteria will be used to decide which projects make sense to sponsor? What benefits would a project gain by becoming a part of the CodePlex Foundation?

LWN: Up until recently, you were the open source "point man" for Microsoft. Over your tenure there, large strides were clearly made, what are your thoughts about Microsoft's open source initiatives (separate from the foundation) going forward? Where do you see the company headed in terms of open source participation? [PULL QUOTE: In a 91,000 person company that is hiring engineers constantly, it's impossible to hire engineers under 30 years old who have no open source experience; I think of it as a generational shift that's inescapable. Their collective views create pressure within the company to find ways to adopt and work with open source. END QUOTE]

LWN: Many Linux developers are concerned about Microsoft's patent attack against TomTom and its attempted sale of 22 patents to non-practicing companies. What would you say to those developers to convince them that Microsoft's motives are benign and that cooperating with Microsoft (either through the foundation or in other ways) is a safe and appropriate thing to do?

LWN: What can you tell us about your new job? It is said to be at a "cloud computing" startup, is that right? Is that company using (or planning to use) open source technologies? If so, how?

LWN: Is there anything else you would like to tell our readers?

[ We would like to thank Sam for taking the time to answer our questions. ]

Comments (14 posted)

Open source hardware for telephony

Applying open source principles to hardware, specifically hardware for telephony, can lead to lower-cost telephone service, which may well be a boon to those in developing countries. Several projects are working on devices and software that can dramatically reduce the cost of providing phone service, particularly in rural areas or those with less infrastructure to support it. In addition, those projects can also potentially bring service to places where telephone service is currently unavailable.

The precepts of open source hardware (OSH) are very similar to those of open source software (OSS). The ideas that make up an object, whether they be schematics for a circuit board or CAD files for a clock enclosure, are available to view, copy and modify. As such, many OSH projects have adopted some of same licenses traditionally used by OSS projects, such as the GPL and MIT licenses. Some have even adopted Open Hardware specific licenses, such as the TAPR Open Hardware License.

One person, in particular, has created an OSH project that could change the face of telephony. David Rowe, an engineer hailing from Adelaide, South Australia wants to make the ability to make a phone call a right, and not a privilege, for every person in the world. And he has designed the hardware (running Linux, of course) to do just that.

The Free Telephony Project was started by Mr. Rowe in 2005. Like many OSS developers he had an itch to scratch, and the process of scratching that itch led him to develop the IP04 PBX: "a low cost phone system that can switch phone calls from analog phones or phone lines over the Internet using VoIP".

The IP04 is an embedded device powered by Analog Devices Blackfin processor and running Linux as the operating system with Asterisk software serving as a Private Branch Exchange (PBX). The IP04 is designed to bring the cost of deploying telephone systems down to the point where most anyone could deploy them in developing nations. The concept of such a device is not new, in fact Mr. Rowe had actually started and exited a company that provided hardware for telephony on Linux. What makes the IP04 different is the relatively low cost (starting at approximately $300 USD), low power requirements (the unit can be powered by solar power and/or batteries if need be), and the fact that the designs of the all the hardware and software are open source.

Mr. Rowe envisions possible deployments of the IP04 as seeds of entrepreneurship in developing areas. A budding local businessperson could set up a device and provide services to people in his or her local area; in essence becoming a small telephone company. Mr. Rowe believes that with the right help for the initial deployment, the IP04 presents an opportunity to find the right franchise model that would allow for "self-funded, viral growth of telephony in developing communities. Business is a much more powerful way to roll out a service than continual donations and first world support."

Mr. Rowe blogged his progress during the IP04 design phase, and his work caught the eye of Atcom, a Chinese manufacturer of telephony equipment. Atcom contacted Mr. Rowe to thank him for the open designs he had published and offered assistance if he ever needed anything to be manufactured. When the IP04 reached prototype stage, he took Atcom up on its offer. "Three weeks later DHL rang my doorbell and there were two assembled prototypes on my doorstep." Final production hardware started rolling off the line in July, 2007. It only took about 18 months to go from idea to a finished product.

The help from Atcom is but one example of how making the project open has helped the IP04's progress. Mr Rowe is quick to acknowledge everyone that has helped along the way, "I stand on the shoulders of giants. Thanks to all the people who have contributed and whose work I have built on. In no particular order: Atcom, Analog Devices Blackfin team, the Asterisk community, and the Astfin & BlackfinOne teams."

The IP04 has spawned other devices, such as the IP01, IP02 and IP08, differentiated mostly by the number of possible connections to either analog phones or analog lines in the absence of VOIP service. Atcom produces units for sale, and Mr. Rowe also sells the devices via his website (in addition to bare printed circuit boards for those adventurous enough to assemble a unit by hand). The IP04 has even been put through a gamut of certification testing, winning FCC certification in the U.S. and A-tick certification in Australia. There is an active forum where users can go for support, and many have helped extend the device either through software add-ons or by helping chase down bugs. One company has even started a successful business selling and supporting customers with a range of devices through the addition of custom firmware, as well as starting its own community forum.

The possibilities of low cost and open communication for the world are many. The IP0x series of devices seem to be but the first building block. This fact was recognized by Steve Song. As the Shuttleworth Foundation's Telecommunications Fellow, Mr. Song was involved with the creation of the Village Telco Project which had many of the same ideas that Mr. Rowe envisioned in his Free Telephony Project. Mr. Song invited Mr. Rowe and several other like-minded individuals to a workshop to come up with ideas for extending the concept of a low-cost telephone company toolkit.

Out of this first meeting, known as the First Village Telco Workshop and held in June 2008, the idea of the next generation of OSH telephony device came to life: The Mesh Potato. Essentially a WiFi router with a FXS (Foreign eXchange station, a connection for a traditional analog phone) port running a mesh network, the original concept was devised by colleague of Mr. Rowe's, Kristen Peterson during a conference in 2007.

The concept of the device is simple. A small unit the size of a standard WiFi router (running OpenWRT) that would cost approximately $50 USD and has a connection for a traditional cheap analog phone (the FXS port). This device would operate in a mesh network with other, similar devices, much in the same manner as the the OLPC's XO laptop, in essence creating an ad-hoc telephone network with no other infrastructure required. The devices can operate standalone, or could be connected upstream to a local provider. Mr. Rowe offers, "Many people in the developing world already spend a large proportions of their income on cell phones (up to 40%). They are getting ripped off by the sort of business models that cell phones seem to attract. We aim to introduce a little competition using service running on unlicensed spectrum."

Use in developing nations is not the only potential use for the Mesh Potato device. Mr. Song has envisioned uses in a crisis situation. After a major disaster occurs, if all cell communications and landline communications are shut down, a number of Mesh Potato devices could be deployed in a very short time. Though still a concept at this stage, Mr. Song has laid out a interesting scenario in one of the Village Telco blog posts.

The Mesh Potato has hit prototype status and the first devices are being readied to hand out to testers all over the world. When asked to define what would mark success for the Village Telco Project, Mr. Rowe answers, "Six months in operation in some township while making a profit for the Village Telco Entrepreneur. Making $ is the best way to prove the technology is working."

The OSH telephony innovations don't stop with Mr. Rowe or the Village Telco Project. The Astfin project, a uClinux Asterisk distribution, not only supports the IP0x series of devices, but they have also produced hardware that offer different connection options such as ISDN's basic and primary rate interfaces (BRI/PRI).

Of course, the community has pushed the envelope even farther. The OpenBTS project is a "an open-source Unix application that uses the Universal Software Radio Peripheral (USRP) to present a GSM air interface ("Um") to standard GSM handset and uses the Asterisk software PBX to connect calls. The combination of the ubiquitous GSM air interface with VoIP backhaul could form the basis of a new type of cellular network that could be deployed and operated at substantially lower cost than existing technologies in greenfields in the developing world." In essence, they have taken an OSH device (the USRP) combined it with some OSS, and provided a means to create a wireless network compatible with many mobile phones throughout the world. They recently put the system to the test at the Burning Man Festival and have detailed blog postings about what worked and what did not.

Whether the Open Telephony Project, Village Telco Project, or the OpenBTS Project are successful remains to be seen, but in all three instances, the decision to make the not only the software but hardware open has already paid dividends in terms of time to market and fostering of the community. No one project would have a chance to succeed if other open software or open hardware projects did not already exist. Just as the world has benefited from OSS, the future of OSH seems to hold many possibilities for the future.

Comments (5 posted)

Embedded Linux Conference Europe 2009

The 2009 edition of the Embedded Linux Conference Europe (ELCE) was held recently in Grenoble, France. This event, sponsored by the CE Linux Forum (CELF), brought together developers and companies interested in embedded Linux, from throughout Europe and from around the world. Last year's edition was held in the Netherlands, but the conference moves around, and this year the event was held in France. The city of Grenoble is in an impressive setting, surrounded by tall mountains, and is a hub of technical development (locally called the "scientific polygon").

This report describes a few of the talks this year. It's impossible to describe all the different talks at the event in a short summary, but the presentations are being gathered on the CELF wiki. There were presentations on a range of topics, including distributions and build systems, kernel subsystems, features and tools, licensing, power management, bootup time, and many more. Most presentations are already available on the wiki, and the few stragglers should show up within a week or two. I should mention that I'm one of the conference organizers, so you can expect some bias about the event, but overall I think the conference turned out very well.

Jon Masters, a developer at RedHat, started off the conference with a talk about porting Linux to different architectures and platforms. He spoke about the technical challenges involved, and the surprising addition of 2 new architectures to the mainline kernel source tree just this year. He reported that Arnd Bergmann is in the process of writing a new set of asm-generic include files, and trying to rework and clean up a lot of existing architecture code in the kernel (the source files of which have often been copied for new architectures from pre-existing architectures, sometimes correctly and sometimes with bugs.) This work has the potential to make it much easier and less error prone to add new architecture support to the kernel going forward.

Matt Porter, who has been in the embedded Linux domain for many years, gave a very interesting talk about Android. (In fact, his talk was voted by attendees as the best one at the conference.) He titled his talk "Mythbusters: Android", and Matt said he intended to show some of the realities about the system that developers may not expect. He described a lot of the difficulties that he and his team of developers at Mentor Graphics had in porting Android to other processors, and also in supporting existing Linux applications. Android replaces many parts of the system with its own, newly-written software. Things like the init system, the Dalvik virtual machine, and many class libraries are new, and appear to have been written hastily to get the phone products out the door. Also, there are numerous examples of ARM-specific and endian-specific code in the system that were painful to find and fix. Matt said Google needs to do a much better job of interacting with the rest of the open source community.

The next session was another on Android by Nina Wilner of IBM. She works for Power.org, and her talk was on porting Android to PowerPC. She started, however, by talking about the possible upsides of Android, helping to explain why this platform has raised people's expectations. Among other things, she observed that Android might just be to Linux, what Linux was to Unix. In the embedded space, Linux distributions are horribly fragmented, so a strongly supported platform might create a rallying point to unite around and be used to compete against other commercial embedded offerings.

Nina remarked that when Linux arrived on the Unix scene, many people looked at the relatively immature system and asked "why make a new OS?" Although Android may be a bit rough around the edges right now, it is possible that things like marketing clout may overcome its coding quality, and create a common Linux platform that can be used in a variety of embedded products. We'll have to wait to see if that's how things play out in the market or not.

On Thursday evening, there was a social event at the "Bastille", an 18th century fort in the mountains above Grenoble, that now has a cable car, restaurants, and other touristy stuff. The trip in the cable cars was quite interesting, as they consist of "bubbles", which are clear on all sides. This, combined with the steepness of the ascent, was a little more thrilling than most cable car rides. See Wikipedia for more information.

On Friday, the keynote was offered by Philip Gerum, who is the lead maintainer for the Xenomai (realtime framework for Linux) project. He gave a thorough talk about the current state of Xenomai, and realtime support in Linux in general.

Another talk on Friday that I found quite interesting was by Vitaly Wool about recent work on adding "device tree" support for the ARM architecture. The device tree is a structure used to describe platform hardware to the kernel, which can be integrated into a compiled kernel or passed by the bootloader. It was developed for the PowerPC architecture, but has since been used in other architectures as well. There may be some value in pushing it throughout the different kernel architectures in order to simplify device drivers and unify the methods of passing data between firmware and the kernel on bootup. He reported on the different discussions that were held on the kernel mailing list, and the points made by different developers in favor or against adopting this for the ARM architecture.

The conference closed with a game designed to show the "Butterfly Effect of CELF". It was really an excuse for the primary sponsor to talk a little about itself, and a way to hand out prizes to attendees. The game consisted of a physics engine where, in some levels, you added objects and removed obstacles to allow a butterfly to reach its goal. Some humorous moments developed when contestants figured out that the controls allowed manipulating pre-existing level elements (including deleting the obstacles directly). The game is open source, and is still under development, but it is currently available for download at SourceForge.

Free Electrons videotaped all the sessions, and will make them available shortly — once they have time to do some video processing. This is a really nice service to the embedded Linux community. The videos from this event should be available in 4 to 6 weeks, and will be announced when they are ready.

Overall the conference provided a good opportunity for embedded Linux developers in Europe to convene and connect with each other. CELF is planning a similar conference for Europe next year (in addition to its "regular" Embedded Linux Conference which is usually held in the spring in the US.)

Comments (1 posted)

FOSS license compliance for companies

Getting started

Free and Open Source Software (FOSS) allows all stakeholders to use, study, share and improve code for commercial or non-commercial reasons. However, engagement can still appear daunting to companies. They are monetizing other people's creations, and, with the high economic value of FOSS, making a mistake is less easily forgiven than it might be in non-commercial circumstances.

Fortunately, there is a substantial body of documentation available to help commercial stakeholders learn how FOSS licenses work, how to communicate effectively to resolve issues, and how to understand what expectations might exist beyond simple legal requirements. There are also several organizations acting as neutral educators dedicated to licensing, development, and governance issues.

Complying with FOSS licenses

FOSS licenses use copyright law as a legal framework for applying their terms and conditions. In using copyright law the licenses are similar to proprietary software. However, FOSS licenses differ in the types of terms and have a different conceptual framework from proprietary licenses. Therefore FOSS licensing must be examined in its own context and without prior assumptions to ensure compliance.

There are four basic types of FOSS license: permissive, weak Copyleft, strong Copyleft and network protective. These can be placed on a sliding scale from licenses that do not have a perpetual grant to use, study, share and improve code through to licenses that perpetuate these freedoms through both traditional distribution and on the Internet. The fewest terms tend to be in permissive licenses and the most terms tend to be in strong Copyleft or network protective licenses. David Wheeler has created a graphic to visualize the relationship between various popular FOSS licenses using this scale.

Key examples of FOSS license terms can be found by reading the GNU GPLv2. This is the most popular license in the ecosystem, contains strong Copyleft provisions, and requires (among other things) attribution, access to source code, and for a copy of the license to be included with any code distributed in binary or source form. Many other FOSS licenses are broadly similar though they differ on details.

The different ways FOSS licenses express their various grants and terms has consequences for license use and compliance. These are legal documents and wording differences can make them incompatible with each other. It also means that there is no single approach to shipping code that satisfies all possible licensing requirements, which is an important consideration given that forgetting a license term can result in legal action.

A good process for FOSS compliance will deal with multiple licenses and terms by determining what code is included in a product and then checking which licenses apply. It will include provisions for understanding whether the various licenses are compatible with each other and for making sure they are not mixed incorrectly through code combination or linking. It will also include a review of included license terms and include a check for adherence in the product before distribution. To allow issues undetected in the process to be solved without undue escalation, it is also sensible to provide a contact address for people to report concerns.

Communicating to resolve problems

Being a good citizen in the FOSS community means pro-actively solving problems and maintaining a positive relationship with the projects producing source code used in products. These concerns center around the principle of share-alike, and rely on an understanding of how various parties are expected to act in this field.

The key expectations in FOSS are that everyone will follow the licenses and will contribute code improvements back to source (or "upstream") projects. The former is a legal requirement and the latter is a social expectation. Fulfilling both can greatly assist in maximizing a company's return from FOSS. Failing to do so can have negative consequences, ranging from legal action over licensing issues through to negative press because of a lack of cooperation with the community.

Dealing with these expectations requires community-oriented communication and quite a different approach to that used in traditional proprietary markets. Whereas proprietary code is about monetizing licenses, FOSS is about how shared technology is developed. FOSS licensing mistakes and other problems are usually resolved in an equitable manner. Parties in this field are rarely, if ever, interested in exploiting the value of the code to penalize infringing parties unduly.

Some best practice techniques have emerged around the gpl-violations.org project for resolving legal issues. The first step when receiving notice of a possible violation is to confirm to the reporter that the matter is being investigated. Then the discussion is moved to a private space where information can be shared without disruptive interjections. The party with the potential issue, now fully informed by the reporter, checks the problem against their internal compliance process. The final stage of communication is to update the reporter and issue a correction if a license violation has been identified.

Communicating with projects is equally straightforward. Current best practice is to establish a relationship between a designated company representative and a designated project spokesperson. This allows companies to keep projects informed of expected code use and contributions, and makes it possible to investigate any issues before public escalation. Regardless of whether an issue is about legal requirements or code contribution to the ecosystem, having a chance explain the corporate position clearly to the project helps defuse problems in a mutually acceptable manner.

Getting information

There is quite a lot information available to address the most popular licensing choices or combinations in the FOSS ecosystem. Most of this material centers around the GNU GPL because of its popularity in developer circles and because the majority of commercial activity is focused on the Linux kernel. Given this, an essential reading list for FOSS compliance includes:

• How to use GPL licenses for your own software
• A legal issues primer for Open Source and Free Software projects
• Practical guide to GPL compliance
• Useful GPLv2 compliance tips for vendors
• Quick guide to GPLv3
• GPLv3 summary for managers
• A list of popular FOSS licenses and their compatibility with GPLv2 or v3
• Reporting and fixing violations

Additionally, people focused on code development will find "The Touchier Points of Determining the License of an Open Source Project" and "Maintaining Permissive-Licensed Files in a GPL-Licensed Project: Guidelines for Developers" useful. People dealing with multiple versions of GPL code will find the compatibility matrix published by FSF helpful. People seeking to allocate exposure in supplier/purchaser relationships will benefit from examining the recently released Risk Grid [PDF] and its accompanying explanatory article.

More specialized information is also available, ranging from license agreements that reduce exposure to software patents through to manuals showing how gpl-violations.org discovers license violations in embedded products [PDF]. When it comes to finding such niche information the most productive approach is to establish relationships with knowledge providers in this field.

Finding knowledge providers

There are numerous parties offering opinions in FOSS. Finding reliable providers for commercial interaction requires a focus on parties with an established reputation and an understanding of ICT business imperatives.

Two relatively recent initiatives with substantial reach and non-partisan membership are the European Legal Network, which has over 200 members across 27 countries and 4 continents, and the International Free and Open Source Software Law Review, which provides a neutral platform for detailed and industry relevant discussions.

It is worth building relationships with organizations like FSFE's Freedom Task Force, FSF's Free Software Licensing and Compliance Lab, Linux Foundation, gpl-violations.org, Software Freedom Law Center, Open Bar, ifrOSS and FOSSBazaar. They all provide various services related to direct licensing assistance, explanatory documentation, case law examples, and fostering professional cooperation between FOSS stakeholders.

Conclusion

FOSS offers tremendous value in the development of shared platforms. Harnessing this requires the establishment of on-going relationships between diverse stakeholders, and for a combination of adherence to license terms and respect towards code creators' wishes.

Comments (none posted)

Page editor: Jonathan Corbet
Next page: Security>>