Managing FOSS for Business Results

By Elizabeth Krumbach

Built on the Free/Open Source Software (FOSS) model for cluster deployments, LinuxForce staff has been hard at work over the past months developing and deploying LinuxForce Cluster Services built upon exclusively FOSS technologies and on December 15th we put out a press release:

Announcing LinuxForce Cluster Services

In September Laird Hariu wrote the article “File Servers – The Business Case for High Availability” where, in addition to building a case to use clusters, he also briefly outlined how Debian and other FOSS could be used to create a cluster for a file server. File servers are just the beginning, we have deployed clusters which host web, mail, DNS and more.

The core of this infrastructure uses Debian 6.0 (Squeeze) 64-bit and then depending upon the needs and budget of the customer, and whether they have a need for high availability, we use tools including Pacemaker, Corosync, rsync, drbd and KVM. Management of this infrastructure is handled remotely through the virtualization API libvirt using the virsh and Virtual Machine Manager.

The ability to use such high-quality tools directly from the repositories in the stable Debian distribution keeps our maintenance costs down, avoids vendor lock-in and gives companies like ours the ability offer these enterprise-level clustering solutions to small and medium size businesses for reasonable prices.

By Elizabeth Krumbach

On Saturday, May 7th, I’ll be taking a flight out to Budapest, Hungary to attend the week-long Ubuntu Developer Summit (UDS) as the kick-off event to the development of the next Ubuntu release, 11.10 (code name Oneiric Ocelot) coming out in October 2011.

The Ubuntu Developer Summit is the seminal Ubuntu event in which we define the focus and plans for our up-coming version of Ubuntu. The event pulls together Canonical engineers, community members, partners, ISVs, upstreams and more into an environment focused on discussion and planning.

My role at these summits as an Ubuntu Community Council member tends to be on community work, which includes recruitment and retention of volunteers to the Ubuntu community. I will also attend sessions related to upstream collaboration; most worthy of note are the collaboration sessions related to Debian as my primary development interest remains there. Debian is the parent distribution of Ubuntu, which LinuxForce almost exclusively deploys to our customers.

This will be my third time attending a UDS. I’m excited to see what I will learn, from the possibilities for the next release to the new ideas I will be able to apply in my day-to-day work. So much comes from such in-person collaborations with fellow contributors.

By CJ Fearnley

Recently, I was looking for resources to help explain the implications of integrating FOSS (Free and Open Source Software) with proprietary software. This question is important for any organization who might want to build an “embedded” or “dedicated” system or product which might include either their own proprietary software or third party applications. I discovered that most of the information available about FOSS licensing addresses this issue rather obliquely. This post will cover the basics so that such organizations can see how straightforward it would be to include FOSS in their projects. Standard disclaimers about my not being a lawyer apply.

Use of any software system requires understanding the software licensing involved. There are many dozens of FOSS licenses that could apply in your situation, so understanding the details is necessary to assess compatibility. In broad terms, these can be effectively summarized by the Debian Free Software Guidelines and The Open Source Definition. Any software that complies with those specifications will freely (in both the “freedom” and money senses of the word) permit running proprietary and FOSS applications on the same system. This is easier said than done. Since Debian has analyzed most common FOSS and quasi-FOSS licenses, their archive and their license page can be used to assess how the license might work in your situation (for example, anything in “main” would be OK for co-distribution and running in mixed environments). So we always start with Debian’s meticulous and well-documented analysis to assess any license.

From a high-level perspective, the requirements that FOSS licensing will impose on an organization wanting to include it with proprietary software will primarily be in the form of providing appropriate attribution (acknowledgement) and providing the source code for any FOSS software (including any modifications) shipped as part of an integrated system. Typically the attribution requirement can be satisfied by simply referencing the source code of the FOSS components. The source code requirement can be met by providing the source code for all of the FOSS distributed as part of the integrated system, for example, by placing it on a documented ftp site.

There are some subtle issues that may arise during the software development process if proprietary and FOSS code are “linked” together. In such cases it is necessary to ensure that code over which one wants to assert proprietary control is only combined with FOSS code that explicitly supports such commingling. So it is necessary for a company wanting to keep its code proprietary to keep it “separate” from the FOSS code used in the integrated system. The use of the words “linked” and “separate” is intentionally vague because the terms of each FOSS license will need to be examined by legal counsel to understand the precise requirements. In these situations, there are license compliance management systems that can be adopted to help ensure that this separation is maintained.

Those are the basic issues. The references below describe these and related issues involved with Linux & FOSS licensing in much more depth:

• FOSS Licensing Wikibook
• Guide to FOSS licensing
• Free and Open Source Software Compliance: The Basics You Must Know (registration required)
• Establishing Free and Open Source Software Compliance Programs: Challenges and Solutions (registration required)
• Shareware Redistribution of FOSS Software
• A Practical Guide to GPL Compliance
• CC HowTo #1: How to Attribute a Creative Commons licensed work
• International Free and Open Source Software Law Review

By Elizabeth Krumbach

Last weekend I had the pleasure of presenting at the Central Pennsylvania Open Source Conference on the topic of Contributing to FOSS (slides available here).

In the talk I explored the many ways individuals can get involved in FOSS (Free and Open Source Software), briefly covering everything from programming to artwork to documentation. As diverse as these contributions are, the common thread is close collaboration with the project itself. In particular, following the procedures in place for contributing to the project is essential. The talk also reviewed some of the benefits of contributing to FOSS, which include career advancement and the ability to expand your professional network.

Although my presentation focused on individual contributions, these lessons also apply to how businesses benefit by contributing to FOSS. When a business approaches a project they should attempt to build a symbiotic relationship with the community. Such a relationship involves following the established community procedures so that your contributions can be easily adopted by the project. Useful scripts and code developments made within the company that can be useful to the greater public should be contributed back and packaging of popular software within the company can be submitted for inclusion and use by the greater community. Testing and bug reporting based on experience using FOSS on their production (or development) systems can provide important information for FOSS developers about the health and status of their projects.

Benefits for businesses that we at LinuxForce have seen first hand are referrals for projects based on documentation work completed on popular community websites (such as Debian-Administration.org) and feedback on our approach leading to improved best practices and building a reputation as experts. By sharing code with projects, others can build upon it to produce more functionality than your team could muster on its own, creating better software for everyone. Additionally, our involvement has allowed us to foster development of Debian packages for software that is used by our clients by, for instance, improving automatic database configuration support and making sure up to date packages are included in releases.

In conclusion, when a business contributes to FOSS they can help drum up business by building a reputation and doing real work within the community, and they help their customers by being on the forefront of development direction and discussions for software that is vital for their own organizations. Contributing to FOSS is good for business, good for your customers, good for the community, and good for the FOSS ecosystem in general.