We’ve come up with five points to consider when selecting a FOSS operating system:

1. Intended use
2. Commercial support
3. Hardware compatibility
4. Software compatibility
5. Community

Intended Use

How you plan to use a FOSS operating system is a key point to take into account when making your selection. Many of the systems are quite flexible and can be used for different purposes, but it still pays to consider their relative strengths and weaknesses.

We’ve come up with three broad categories with which to categorize most FOSS operating systems: desktop, server, and special purpose.

Desktop Operating Systems
If you expect desktop functionality from your FOSS operating system, you’ll want to find one that’s been designed for that purpose. Desktop operating systems tend toward friendlier installation and greater use of graphical user interfaces. In addition, they usually sport newer versions of popular desktop software like browsers and mail clients.

Sample desktop FOSS operating systems include:

• Mandriva
• openSUSE
• PC BSD
• Ubuntu

Server Operating Systems
Server operating systems may favor stability over the latest versions of software applications. With some server operating systems, the installation of the operating system and programs is done with less graphical (and often less friendly) tools than you’ll find in desktop operating systems. The software in server operating systems tends to be somewhat behind “right out of the box”, but can be fairly easy to update using the software management tools provided. However, care should be taken to make sure that your updates will work, especially if the software you’re installing includes dependencies on other packages – in which case you’ll need to update those, too.

Sample server FOSS operating systems include:

• CentOS
• FreeBSD
• Red Hat

Special Purpose Operating Systems
There are a number of special purpose FOSS operating systems that offer bundles of pre-configured applications with graphical installer and management tools. Some of the most common special purpose operating systems are for file serving, firewalls, and rescue CDs. They’re usually based on an existing general purpose desktop or server operating system, but with the installation modified in such a way that a certain set of software is installed. Management in special purpose operating systems is usually very specific and tends to emphasize the system’s particular function.  Many areas of management are not readily accessible through the default management interface. On the bright side, special purpose FOSS operating systems may provide a quick and easy way to fulfill a specific need – if you can find one that accomplishes what you require.

Sample special purpose FOSS operating systems include:

• Knoppix Rescue CD
• FreeNas Free NAS file server
• Smoothwall Firewall

Commercial Support

The number of FOSS operating systems with commercial support is relatively small. Luckily, there are lots of free resources out there: mailing lists, forums, wikis, and IRC (internet relay chat) channels, to name a few. The support available through these free resources is comparable to, and sometimes even better than, traditional commercial support.

If you’re selecting a FOSS operating system for an organization, there may be requirements stating that you can only use software backed by commercial support. If that’s the case, you might consider the often-overlooked option of contracting with a company that provides third-party support. One advantage of some third party support organizations is their ability to offer commercial support for both your operating system as well as for some (or all) of the programs you’ll be running with it. Having one go-to source for all your support needs may be better than contracting with one company to support the operating system and other companies to provide service for the other components.  Also keep in mind that many FOSS operating systems are similar enough that a third party organization may be able to help you even if they have not worked with the exact system that you choose.

If you’re planning to use a FOSS operating system on a machine deployed for a critical role, it’s especially important to research the available support options before deploying the operating system. This step is even more crucial if you or your organization have no previous experience with the operating system in question.

Hardware Compatibility

Hardware compatibility is another crucial factor when choosing a FOSS operating system. The system has to be capable of supporting your computer’s parts and the types of devices in use. If you have a critically important computer part or device, it’s often simplest just to check with the hardware maker for advice about which FOSS operating systems are supported. Of course, you could simply download a copy of a particular operating system to try with your hardware – if it’s FOSS, it won’t cost you anything but time. Even some of the commercial versions of FOSS operating systems have free counterparts, which are similar enough that you can test on the free version and have a good idea of how the commercial version will behave. Take CentOS and Red Hat Enterprise Linux, for example. CentOS is free, and for the most part very close to Red Hat Enterprise Linux. If you were to choose Red Hat Enterprise Linux, you could test your hardware with CentOS before purchasing licenses from Red Hat.

Another hardware-related point to consider is whether your computer vendor supports only specific operating systems, and whether that’s important to you. If you buy your computers from a local vendor or a smaller seller, chances are that you’re on your own when it comes to operating system support. If, on the other hand, you buy from larger companies (such as Dell, HP, or IBM) you could check which FOSS operating systems they support. Even if they don’t officially support the FOSS operating system you choose, you probably want to find out if you’ll run into any problems when trying to get support from the vendor after the installation is complete. The larger vendors in particular may have hardware management tools that are required as part of their warranty service. Not having access to those tools may impact the support you receive from them.

Software Compatibility

Software compatibility will likely be an important issue if you plan to use commercial software. As a general rule, most FOSS software will work with most FOSS operating systems. If there are particular programs you know in advance you’ll need, then you should verify that they’ll work with the operating system of your choice. One issue that may be overlooked is which version of any particular software application is installed on the operating system “out of the box”. Server FOSS operating systems tend to come with older versions of applications, so if you prefer a more recent version of a particular application you might first have to uninstall the older version.

A good resource to find out what software comes with a particular FOSS operating system is DistroWatch.com. This site allows you to select a FOSS operating system, and then see what packages are supported by the system’s various versions. The example below shows the software supported in recent versions of OpenSuse, compared to the latest available version.

FOSS operating systems usually have software management tools that facilitate the installation of software. It’s worth verifying if the versions you need of selected programs can be easily obtained through the software management tools. Alternatively, you could check if the software you need already has binaries that would easily install in the operating system. Many FOSS packages build binaries to facilitate installation on FOSS operating systems.

One very important point to keep in mind concerns libraries – particularly if you’re evaluating Linux distributions. Be sure to pay attention to Glibc and related libraries. If you plan to use FOSS software that requires a specific Glibc or some other library, then you’ll want to make sure that the FOSS operating system under consideration already has the version you need.

Community

The community behind your chosen FOSS operating system is where you’ll most often go for support, news, advice, and tips. Exploring the various online resources as you evaluate a FOSS operating system is really important. Whatever operating system you choose, you’ll want to make sure that you know where to go for help – as well as what sites to go to for related tutorials, tips, and tricks. You’ll use these to shorten your learning curve and make using the operating system easier. The value of these online communities may not always be obvious to a newcomer, but they’re really hard to beat when it comes to making the operating system you choose work better for your needs.

Mailing lists and forums are two of the most commonly available online help resources. Ubuntu’s online forums are a great example.

One often overlooked source of help may be sitting right next to you. Employees, friends, and co-workers may already have experience with one or more FOSS operating systems. If you or your organization are new to the implementation of a FOSS operating system, it definitely pays to find out if anyone you know already has experience. If you can find someone who has already dealt with FOSS operating systems, you may also find that they have valuable information to help you choose the best operating system for you.

Conclusion

FOSS operating systems are free to download, but the time it takes to learn about them can be costly. Because the management of FOSS operating systems varies widely, it’s best to do as much research as possible prior to settling on any particular one of them. Run tests, and start small. Using a FOSS operating system as a backup (or in a minor role) is a great way to gain experience and learn about an operating system with little risk to your infrastructure.

If you’re hoping to convince your employer to deploy a FOSS operating system that you’ve used personally, pay close attention to the support, hardware, and software requirements of the business. The larger the business, the more likely it is that there will be constraints on what sort of system can be used – and the more likely it is that there will be issues that, as a single user, you’ve never considered.

Usage, support, compatibility, and community: consider all these factors carefully and you’ll be in position to choose the FOSS operating system best suited to your needs.

Angel investor Larry Augustin said “Europe and most of the rest of the world is ahead of the US in Open Source adoption” in an often cited Weblog entry, and a report from Forrester Research showed that France and Germany lead in open source adoption.

Illustration 1: Adoption statistics for FL/OSS in the EU

Given that open source offers companies and organizations a highly cost-effective route into international markets, Europe is a land of milk and honey due to its high adoption of open source software. This article outlines the differences between the US and Europe in order to help open source software vendors develop strategies to bridge the gap and begin testing and developing new markets and communities within Europe. The main focus of this article is on providing facts and sharing experiences that allow one to understand the European IT market. We’ll outline the implications for marketing, communications, and community building within Europe in another article. Entrepreneurial and legal aspects are covered only as they provide valuable background information that can help one understand the implications for the primary topic of interest. In detail, this article concentrates on:

1. Comparing the economies and open source software adoption rates in the EU and US
2. Understanding societies in the EU and the role open source software plays

The information covered in this article applies to member states of the European Union as well as closely associated states such as Norway and Switzerland. En passant, we’ll also take a quick look at Eastern European states.

European Union, the Largest Market In the World

Europe is the largest market in the world. Taken as a whole, the European Union has a GDP of over $18 trillion USD, $4 trillion more than the US. The EU’s GDP accounts for 30% of world production, and the population of about 500 million people is over 60% larger than the US.

Illustration 2: GDP of EU and USA

Adoption of Open Source Software in Europe

RedHat published an open source activity map that indicates the hot spots of global open source software development. Europe is one of the most active regions, as are the US, Brazil, China, Australia, Japan, and South Africa.

Illustration 3: RedHat’s Open Source Activity Map

The breakdown of market share by country for Firefox also helps illustrate how Europe compares to the US in terms of open source software adoption. Firefox serves as a good benchmark because its actual distribution can be measured quite reliably by tracking access to web sites through Firefox. Contrast this with OpenOffice, where the number of downloads does not directly translate into the number of installations because one could download OpenOffice once and install it on many desktops.

As shown in the chart below, Firefox usage is clearly higher in France and Germany than the US, although all three countries are above the worldwide adoption average.

Illustration 4: Average Firefox market share Nov 08 to Mar 09

Looking at the worldwide distribution of contributors and users to open source projects on Ohloh, one gets the impression that there are in general more of them in Europe compared to the US. For example, the activity map for Debian shows significantly more contributors in Europe.

Illustration 5: Debian contributors

However, we have to be careful about interpreting data on these maps, as they display only a fraction of only the contributors registered on Ohloh. Nevertheless, they indicate rough trends.

Illustration 6: TYPO3 vs. Drupal users

Comparing the distribution of TYPO3 and Drupal users on Ohloh, it’s clear that TYPO3 has a stronger adoption in Europe than Drupal. On the other hand, Drupal has equally strong adoption rates in the US and Europe, while TYPO3 lacks adoption in the US. It would be out of the scope of this article to discuss the reasons for the diverging uptake, but vendors should note that when an abundance of open source alternatives has emerged (as is the case in the CMS market) regional preferences can develop, with certain regions favoring one open source system over the other.

To get a more complete picture of open source software adoption in Europe, we assembled the following map based on reports, news coverage, Matt Aslett’s tour of Europe, and the experience of the InitMarketing team. It is far from scientifically correct, but it nonetheless serves as a good start.

Illustration 7: Open source software adoption in Europe

Note that European countries with lower GDP (mostly those in Eastern Europe) tend to have lower open source software adoption rates, although one of the major political arguments in favor of open source software is that it can help build a strong local IT economy with less initial investment. Some of the likely reasons for this disparity include:

• Markets in countries with lower GDP might be too small to attract or generate medium to large open source system integrators, instead supporting only a few small ones. These markets may benefit from affirmative laws or declarations endorsing open source software. For example, the Spanish province Extremadura created a flourishing market for small system integrators when it announced plans to use more open source.
• Municipalities and governmental organizations are often highly independent. This can decrease open source software adoption because regulations favoring open source are unlikely to be effective when pushed top-down by state ministries.
• The circulation of illegal copies of proprietary software is higher in such countries, which most likely contributes to lower open source software adoption rates.

Primary Reason For Open Source Adoption in Europe

In the above-mentioned Weblog post, Larry Augustin cites avoiding vendor lock-in as the primary reason behind open source software adoption in Europe. However, a study conducted in Germany by the major IT publisher Heise actually found that users adopt free and open source software (FOSS) to lower licensing costs, and less so to avoid vendor lock-in. Similarly, a Spanish report indicates that saving on software licenses is the main advantage of open source usage by Spanish public administrations.

Given the lack of similar reports (or at least the difficulty in finding them) for other European countries, Larry’s assumption might still be valid for most European countries excluding Germany and Spain. On the other hand, Germany and Spain are at the forefront of open source software adoption in Europe, and saving on software licenses might also be (or soon become) the primary reason driving open source usage in all other European countries.

It’s worth noting here the German study revealed that saving on licensing costs is more important to those adopting open source software for the first time. The longer someone uses FOSS, the more important the “freedom” aspects become — namely open standards, vendor independence, and the free and open source software philosophy. Hence, open source vendors need to approach potential customers in Europe differently depending on how open source savvy these potentials are.

Understanding European Societies

The title of this section says it all: there is no single European society, but rather many different European societies, cultures, and languages, all united in diversity. A classic cartoon entitled The Perfect European summarizes the diversity in a humorous and ironic way, with much truth.

Illustration 8: Cartoon, The Perfect European

Especially direct sales efforts in Europe must take into account important differences in communication. For example, German business persons typically like to do the work first and have fun later, while French business persons enjoy sharing a nice conversation before the work starts. However, the proximity of these diverse cultures adds yet another dimension. Most people in the European software business have traveled abroad for business trips or during university, and these experiences allow them to reflect upon their own culture’s communication style and take into account the subtle differences.

This is where things get complicated, yet funny. A French business person might suggest to a German that they complete the work before engaging in small talk in order to conform to the German’s cultural expectations. That might confuse the German, who expected the Frenchman to want to schmooze first.

Language Barriers Fracture the European IT Market

Cultural and geographic differences significantly shape the IT market in the EU, so understanding local language and culture is often a prerequisite to doing business with local firms. However, this is complicated by the fact that there are over 20 languages spoken across the EU, and in some cases there are language differences between regions in the same country.

Comparing the Information and Communication Technology (ICT) output in 2008 to the distribution of “mother tongue” languages in the EU, we can see that the European ICT market is actually quite fractured. For example, the most widespread mother tongue is German, which is the primary language spoken by 18% of EU inhabitants (spread amongst Germany, Austria, Switzerland, and a few small regions). However, the countries and regions where German is the mother tongue account for roughly 25% of ICT output.

Illustration 9: ICT output in EU per language in 2008

The good news for US-based vendors and communities is that English is the most widely-spoken language throughout much of Europe. 51% of EU inhabitants can carry on a conversation in English, either as their mother tongue, a second language, or a foreign language. Next in line are German and French, which are spoken in some capacity by 32% and 26% of the EU population, respectively.

However, it would be false to assume that communicating in English, German and perhaps French will enable Americans to cover the entire European market. Some regions have a strong bias against particular languages, such as the Flemish community in Belgium where people speak Dutch and might not be amused if you tried to sell software in French. Similarly, some people in France will call you names if you speak in German. Luckily, most of these resentments are only a problem with older generations.

The simple truth for open source vendors trying to get a foothold in the European market is that English should be fine as long as the focus is only on building an initial developer community and partner network. Once you decide to build a growing business in Europe, contracts written in English will be a show-stopper in countries where English is not the mother tongue — especially so to small and mid-sized enterprises.

Type of engagements in Europe

The cultural diversity of Europe also impacts the type of business and community engagements you can find in various regions. In short, Europe is not a single market for open source. Open source adoption seems to be driven by commercial engagements in Northern Europe, while Southern and Eastern Europe is characterized by community-driven engagements.

Concerning the sales channel, Northern Europe seems to prefer direct sales — especially the UK. There, customers want to buy the product and less so services. At least in Germany, SMEs are fine with having system integrators implement projects, but large enterprises want to include the open source vendor in negotiations and have the vendor guarantee the success of the project, recommend system integrators, and perhaps even lead the project. In Italy and Spain, economic buyers might outright reject vendors and commercial editions of products because open source software is supposed to be available at no cost. There, the market prefers to buy services from system integrators.

For open source software vendors, this means that commercial whole-product offerings and direct sales tactics could well work in Northern European countries, while in Southern and Eastern Europe they should leverage community development tactics and build a partner network. There is also the mushy middle of Mid Europe, such as Germany, where the appropriate sales or marketing approach depends on the project volume and type of customer.

Illustration 10: Types of engagements in Europe

The aforementioned Heise study on open source software adoption in Germany found that the main drivers are CIOs and CEOs. Although open source can still be introduced “through the back door” by developers and system administrators, it appears that, at least in Germany, open source software has won the hearts and minds of executives and become a strategic element of the corporate IT landscape.

Illustration 11: Open source is highly relevant in Germany…

It is hard to say if this is true for other EU countries as well because the data is missing. Our best educated guess is that the companies with highest open source software adoption in the EU are also those where executives increasingly regard open source as a strategic tool.

Conclusion

Europe is a gold mine for open source software vendors, but the gold is often deeply hidden in culturally diverse ground. The united market of the European Union is actually a fractured market that needs to be approached accordingly. Otherwise, community building efforts will run dry, marketing communications will make your company look outlandish, and sales will bounce off cultural barriers.

Although Europe is a fractured market, there are regional similarities that make the market less daunting to US-based businesses and communities seeking to gain a foothold in the EU. Two of these similarities will ultimately have to be addressed in any go-to-market strategy employed by US-based open source vendors casting an eye towards Europe:

• Major languages equal major ICT markets – As we’ve seen, English, German, and French are widely spoken within the EU as mother tongues, second languages, and foreign languages. Roughly speaking, these three languages also correlate with the most prosperous ICT regions within the EU.
• Two types of engagements – While Northern Europe prefers direct sales, the South prefers the partner channel. Customers in the center of the EU want to be able to either work directly with the vendor, with partners, or both.

In an upcoming article we’ll take a look at how to test and develop new markets in Europe with effective outreach through marketing, community development, PR, and more, thus showcasing how open source offers companies and organizations a highly cost-effective route into international markets.

Another classic bumper sticker you’ve probably seen — “Wherever You Go, There You Are” — would fit in nicely on the back of the Mozilla bus. Seems to us that when it comes to scalability, it’s less about being where you are and more about getting where you want to be. Which is, at least in Mozilla’s case, everywhere. The problem remains, though, that even if you succeed in getting everywhere, what does it take to really be there?

Ask the Mozilla team. For them, being where they are (which is nearly everywhere, don’t forget) means being there in many, many different languages — very few of which are spoken by Mozilla’s engineers. By building participatory local communities they’ve gained access to those languages as they are used by native speakers, and nurturing those communities has paid off in many unexpected ways as well. If we could boil all their experience down into one simple yet profound slogan, we’d just go out and print a bumper sticker. Since we can’t, we continue our occasional series on open source community building with a case study by Seth Bindernagel about the localization process at Mozilla. What follows are some lessons in scalability from the people who have made it possible for users all over the world to gain access to a state-of-the-art, free and open source web browser that works in their own native language.

Meet the L10n-Drivers: A Case Study in Building Participatory Communities

Between the release of Firefox 3 and the upcoming release of Firefox 3.5, Mozilla will add 25 new localizations to the browser’s list of official versions. As a point of reference, the most recent release cycle lasted one year, starting officially after the release of Firefox 3 in June of 2008. When we started the localization process for Firefox 3.5, we had 48 localizations. It’s likely that we will ship with 73. This represents tremendous growth in both our localization community as well as coverage of new languages spoken by the world’s Internet population. By our rough estimate the Firefox browser now covers over 97% of the world’s Internet population with a fully-localized user interface that includes translation, localized preferences settings, and a user’s native language option.  So what does it take to increase community contributions and locale count by over 56%? It may not be a new science for some readers, but we think that some of the lessons we’ve learned about scaling are worth sharing.

Lowering Barriers for Participation

In case you’ve heard elsewhere, it’s true that the Mozilla localization process is not perfect. We use a fairly unique file setup to highlight the strings needing localization, and that has had an impact on our ability to scale. With some introduction it’s probably not too difficult to understand, but because we have historically chosen a framework that uses “DTD” (Document Type Definition) and “property” files, it has required localizers to learn our system, which has caused a higher barrier to entry than most other projects.

So how exactly do we lower the barrier for participation for those passionate about localization? One simple step has been to support and promote tool development for translation work that reduces the level of technical background needed. By providing tools for contribution, and helping tool authors refine and improve their software, we have started to scale with more ease. New localizers with less software development skills have become regular contributors responsible for their locale’s translation.

But tools are really not the only answer. Building the proper team has also been crucial. A small group of Mozilla employees focuses on localization. We call ourselves the “L10n-drivers” and provide as much technical assistance as possible when localizers need help. When a project has substantial localization needs — like Mozilla, with its multiple products and websites — the work flow can be overbearing at times, so it’s helpful to have a response team to assist the volunteer community and shepherd projects along to completion.

At the same time, it helps if the volunteer localizers have some technical background so they can work with us and all of our tools to make localization possible. This may sound like a contradiction to my previous point, but it’s not. We walk a fine line between trying to make localization accessible to everyone who has translation interest and asking volunteers to learn a bit about our technical process, like how to check in code changes to their locale repository. Localizers also need to know how to do things like read HTML and execute limited tasks from the command line. It’s far from perfect, but finding individuals with the dedication to stick with us and the curiosity to learn our process has led to a more sustainable community.

Transparency and Communication Create a Sense of Community

There’s another critical piece that we take seriously at Mozilla: full transparency. The Mozilla L10n-drivers team never does anything that we cannot immediately share with our community. In fact, most everything we do directly involves our community every day. We created a public dashboard where all localization teams can see the status of their work as well as the work of other teams. In addition, several of our community members write active blogs that are syndicated to the Mozilla community through our Planet Mozilla service.

Communication is another factor that has helped us scale. Consistent and open communication is critical to our success because it provides channels for both newcomers and long-time localizers to ask questions, learn, and help each other. With other centralized communication channels like Bugzilla, Mozilla mailing lists, and IRC (Internet Relay Chat) rooms, we are in constant communication with the community, available nearly ’round the clock to share information and answer questions. The L10n-drivers team is located in several different time zones across the globe, so we are able to provide fairly regular coverage if something arises. A true sense of community exists on our #l10n channel on the Mozilla IRC server, where conversations are always happening. Providing open lines of communication and making sure that everyone understands that no questions are out of bounds helps us build trust and reliable relationships with our global team.

Within these platforms of communication, many roles and relationships develop naturally and exist because there is a clear set of tasks to undertake if someone wants to localize Mozilla. This leads to another great reason for building and scaling a successful community. We try our hardest to outline the specific tasks that anyone can take if they choose to localize Mozilla in their native language. Without a clear outline, a localizer may begin to wonder what his or her role is. But when we define those tasks clearly, there’s no room for confusion.

If a particular localization has a long-established community of contributors, newcomers are often set to new, untouched tasks that need a team leader. We let our teams know that there is *always* something more that can be translated, so there’s no need to worry about not finding work. Successful L10n teams in the Mozilla community have mapped out specific roles and tasks for their team members, while the L10n-drivers work hard to provide direction on where to focus. With this combination of efforts, our 100% volunteer community takes shape and participates in understandable and digestible tasks.

Sharing the Results of Community Efforts

A few other simple but specific factors add to our success. We try hard to document everything that is critical for localization. Those documents are updated regularly and shared with the community so that people can see what needs to be done and how to do it. Of course, questions are always directed back to one of the channels mentioned above. Also — and this is a specific technical piece that is crucial for our community — we provide regularly updated builds to our community so they can see the fruit of their labors and begin testing. Since our community is fully volunteer, we have to provide them something that can be reviewed and tested on a regular basis. We generate nightly versions of Firefox so that they can see and test their work.

Summary

It’s taken us awhile. Years of experiments, mistakes, and improvements along the way have shaped the strategy. But what now exists is a remarkable achievement by this community. The latest version of Mozilla’s Firefox browser will be shipped simultaneously to 73 locales across three platforms: Mac, Windows, and Linux. Because of this effort, nearly 300 million people across the globe are using a free and open source web browser in a language familiar to them, making their experience on the web the same as any other locale where we ship Firefox.

But for every person or institution out there too intimidated by change, too suspicious of anything that’s labeled “free”, too brainwashed by advertising, or just too busy to think about doing anything different — for each of those there’s another person who’s not only FOSS-fluent, but also enthusiastic, dedicated, and just a trifle selfless. What follows is a story about FOSS migration and volunteerism, which takes place in an environment of a complexity virtually unknown anywhere else. Home to brilliant minds and extraordinary levels of determination, guts and know-how, dedicated to all the highest aims of our free society; this institution is at the same time often mired in budgetary shortfall, bureaucratic delay and, perhaps most pervasive, crushing fatigue. We’re talking about a place where too few of us, once liberated, ever dare venture again — let alone actually enter and try to change anything. That’s right; we’re talking about the Public School System.

In the first of an occasional series of articles on open source community building and advocacy, we present a case study by Christian Einfeldt about how dedicated volunteers can create new open source allies one student and one school at a time. Read on to discover how all the tired cliches about schools mired in inefficiency can be proven wrong, and how seemingly hostile conditions (like underfunding) can in fact make the migration to open source easier.

Hands-On Advocacy: A Case Study in Migrating One School to Open Source

Working with schools can be difficult. Teachers are usually over-worked and under-paid. Principals have limited budgets and are similarly over-worked. Ironically, these factors are exactly why schools make great incubators for FOSS community outreach, because the FOSS community benefits much more from growth in this area than does Microsoft and its business partners. The cost structures carried by Microsoft and its business partners preclude them from targeting schools in ways that make sense for GNU-Linux supporters and their commercial partners.

This article looks at the experiences of a local Linux users group in migrating one public charter school in San Francisco to FOSS, and draws some broader conclusions from those experiences about how the FOSS community can benefit by focusing migration efforts on under-funded institutions like schools.

Desktop Computers as One of the Seats of Culture

The desktop matters. It’s the last link in the “last mile” to the Internet, and it’s the place where retail computer consumer expectations are formed and solidified. Simply put, the desktop is one of the seats of culture in much of the world. Merely by placing FOSS desktops in front of mass audiences, we, the FOSS community, can score big in demonstrating to voters and consumers the commercial logic and democratic imperative of sharing code.

Studies show that brand consciousness and brand loyalty are established at a young age. Kids will stick with brands as they grow up. If we can familiarize kids with GNU-Linux package managers, they will tend to return to those package managers for new software applications as they grow up, and the cycle of dependence on non-FOSS product distribution chains can be broken.

How We Set One School Free — Almost

As I was walking to my bus stop on the way to work one day, I noticed an A-frame billboard announcing a new public charter middle school in the neighborhood. At that time, the school was comprised of about 230 students in grades five through seven (ages 10 through 12). I called the number on the board and left a message offering to provide the school with a few free computers for a pilot project for the school.

The school’s principal soon called back and we scheduled an appointment to meet. I told her that I had been privately scavenging discarded desktop computers for some time, and I knew that I could acquire enough machines to meet her needs through the volunteer efforts of our local Linux user group, SF-LUG. I thought that she would likely start small to test a few machines before springing into something larger.

To my surprise, the principal said that she was interested in starting more than just one small pilot project, and that she was willing to spend some money to obtain such a lab if it wasn’t too expensive. She wondered what it would take to outfit a classroom with enough computers for one entire class. I told her that it would be possible to obtain inexpensive machines and network them together. I contacted a vendor who offered to build a LTSP for a mere $6,000 USD. Over the summer, the vendor and I built the Fedora LTSP lab in an afternoon, and over the next couple of weeks, I was able to place about 10 additional machines in various classrooms throughout the school.

I was pleased with the fairly rapid, positive attitude that the principal, teachers, and students showed toward the lab. There was almost no need for training of the teachers or the students. Both groups took to the new Fedora GNOME interface easily.

In fact, the principal made it clear that she did not want me to spend much time speaking with the teachers about the new technology. She liked the lab, but she was very clear that the emphasis of this school was to focus on providing these inner-city students with an excellent foundation in basic reading, writing, and arithmetic. The computers were nice, but they were seen as a supplement to the core mission of the school. The principal had founded the school just two years earlier with the goal of bringing under-performing kids up to grade-level performance. She also felt that the skills required to make meaningful use of the lab were beyond those of the fifth and sixth-graders, and so only the seventh graders were brought into the lab. The school has since expanded to include 8^th graders and now has a population of about 330. The upper two grades use the GNU-Linux lab.

Basic Internet uses

The GNU-Linux machines at the school are used for basic tasks such as e-mailing, writing essays, watching educationally relevant Internet video, learning basic touch typing, and conducting Internet research. The Xubuntu lab features 30 LDAP clients, each with Pentium 4 chips running at about 2 Ghz with 512 MB of RAM. We chose the XFCE desktop to reduce lag time, as compared with the somewhat more bulky GNOME and KDE GUIs. We moved from an LTSP server to an LDAP server because the LTSP server was lagging, so we shifted some of the load-handling from the server to the clients. We also moved from Fedora to Ubuntu simply because we were more familiar with Ubuntu, although I’m sure Fedora would have been just  fine. In an interesting little wrinkle, the LDAP server was obtained via funding provided by Microsoft through California’s settlement of an anti-trust lawsuit against Microsoft!

As previously mentioned, we have also distributed about 10 similar stand-alone clients (P4, 512 MB RAM) to a few classrooms, where they are used occasionally for writing essays and basic Internet research and emailing.

I have approached the principal and several teachers on more than one occasion with an offer to demonstrate the educational applications that are readily available for use with GNU-Linux, but the staff has consistently taken the position that they are best able to fulfill the school’s mission of giving the students an excellent foundational education with books, pencils, and paper.

Just recently, during one such meeting with teachers, I was able to get one teacher interested in meeting over the summer to explore the possible integration of educational applications into his curriculum. Maybe. We’ll see. I am cautiously optimistic.

No Linux for the teachers

The principal felt (and still feels) that the mission-critical computer needs of the school, namely, the teachers’ needs, would be restricted only to Microsoft Windows machines, unless the teachers had Mac notebooks that they wanted to use and were able to administer themselves. The principal did not rule out the possibility that a teacher, of his or her own accord, might choose a GNU-Linux machine for their own personal needs, but she did not want to me to evangelize to the teachers.

Nor were the teachers interested in adopting GNU-Linux. With the exception of a few Mac users, the teachers all preferred Microsoft Windows machines, for all the usual reasons: they were familiar with Windows; some of their mission-critical applications were Windows-based; and they viewed Microsoft Windows as the standard, and wanted to use what everyone else was using.

And, equally important, these teachers spent long hours at the school every day, and they were too over-worked and tired to take on yet another task that would extend their 13-hour work days. This school has a formal, written agreement with each and every parent and child that the students will be in their seats working by 7:30 in the morning, and that they’ll stay at school until 4:50 each afternoon. Furthermore, the teachers were (and still are) expected to give out their cell phone numbers to each student, and students were expected to call the teacher with any questions, until as late as 8:00 p.m., seven days a week. The idea is that there should be no excuse for any student to come to school with incomplete homework, and the super-long teacher work days were intended to ensure that it was so. But, as a result, this meant that the teachers were not about to add yet another task to their already-long days.

Marketing, Marketing, Marketing

Never underestimate the power of marketing to shape expectations, particularly in North America and most of Europe. I am convinced that the principals and teachers like Microsoft and Apple products because marketing has persuaded them that “you get what you pay for” and that there is “no free lunch.”

Contrast that attitude with attitudes of end users in so-called “developing countries.” In developing regions of the world, which I have visited in the process of taping a documentary movie about how FOSS is changing global culture, people are more willing to give GNU-Linux a shot. The notion that software should be “free as in free speech” seems to resonate more with people in these countries.

But the appeal of digital freedom is generally weaker in North America and Europe, and that was certainly the case in this school. I was actually surprised at the tenacity of brand identification and product loyalty among the very liberal teachers of this school, many of whom were educated at some of the finest universities in the country. Yet these same teachers have a very pragmatic approach to computing, for the reasons previously given.

The principal is also a staunch advocate of education as a leveler of class and an equalizer of race, yet she’s an adamant Microsoft Windows fan. She made it clear that she likes Microsoft Windows and Microsoft Outlook, and she has said that she would never consider using a GNU-Linux computer for her own purposes.

She’s an enthusiastic supporter of GNU-Linux for the kids because it permits her to stretch budget dollars, and she likes the high quality, free technical support she gets from the local Linux user group. In addition, she feels that the computing skills that the kids get in using GNU-Linux will be transferable to the Mac or Microsoft Windows machines the kids will likely encounter in high school. However, the principal and the other teachers have some real reservations about the suitability of GNU-Linux to deliver the performance that they demand for their busy lives.

The teachers rely on just one or two Microsoft Windows-based applications they feel they need to meet their computing needs — both individually and in their work as teachers. But even after I spent time speaking with each of the teachers to determine their precise functional requirements for computers, none of them would consider switching, nor do they want to spend much time discussing why they are not open to switching. They have chosen their computing environment, and they are sticking with it. Plain and simple.

A stable equilibrium

A stable equilibrium has been reached in this, the end of the fifth full year of our LUG’s advocacy work at the school. The principal and the teachers are firmly committed to the Xubuntu lab and the GNU-Linux machines (of varying distros, but mostly Xubuntu) that reside in various classrooms. The teachers routinely and repeatedly express gratitude to the members of SF-LUG who visit the school to do one type or another of maintenance work there, and that gratitude is plainly heart-felt. Several of the teachers have told colleagues in other schools about the lab, and they believe it’s an asset to the school. In addition, elected officials have toured the school and visited the lab, and have received generally positive reviews.

And yet, all of the teachers continue to use only Microsoft Windows or Mac machines for their own purposes…

One Daring Pioneer

…except one. The seventh and eighth grade science teacher dual boots his notebook with Intrepid Ubuntu. The other partition runs a copy of Microsoft Windows XP that was given to him by Adobe two years ago when he attended a summer seminar sponsored by Adobe. Adobe paid him and another teacher $1,000 for one week’s attendance at a seminar, which amounted to a paid infomercial for Adobe products. In addition to the $1,000 payment for attending the seminar, each teacher received a decent notebook computer, and the school received free copies of Adobe video software, along with a check for $5,000 for the school to spend on any cameras or software that it wished to purchase for the purpose of doing media work in the school.

In early December of 2008, the science teacher’s Adobe-sponsored Microsoft Windows XP notebook was hit with a crippling virus, which bricked the machine. He said that he had previously taken the machine to friends of his who were skilled in administering XP machines, but they were unable to fix it. After concluding that the XP notebook was hosed, he asked us to help. Our SF-LUG members used a GNU-Linux live CD to pull his data off of the drive, and then installed Intrepid Ubuntu.

This teacher clearly understands the civil rights aspect of free software, and it’s apparent to him that there are inherent dangers in using software whose source code is locked up in a black box for only the vendor to see. He also sees the importance of having community access to source code, because he (and most of the other staff members) understand that our SF-LUG members have customized software in certain ways to make the lab run smoothly — although they don’t understand the nature of the changes, nor do they really care to learn the details.

And yet it is telling that it was only after consulting with XP-savvy friends and finding that his XP partition was hosed that he relented to have his data removed, his hard-drive wiped, and a clean (legal) copy of XP installed along with the Ubuntu Intrepid partition. Despite having used Xubuntu in the lab for two years, he was still hesitant to install GNU-Linux on a “mission-critical” machine until it was clear to him that viruses had irredeemably crippled XP.

Now this teacher uses the Ubuntu (GNOME) partition as his primary environment. Every day, this teacher stands in front of his class and delivers presentations from his Ubuntu partition. Each day, 120 seventh and eighth grade students are exposed to OpenOffice.org and Firefox during his class lectures. Every day, this teacher and his students become more familiar and comfortable with GNU-Linux. The same can be said for the roughly 120 students who come through the Xubuntu lab every week. That is progress.

Machines In Students’ Homes

From the beginning, it has been my personal goal to see that every student who wants a GNU-Linux machine will be able to have one in his or her home. That goal has proven to be difficult to achieve for several reasons, which I will briefly summarize here. First, there’s a good deal of administrative work that goes into determining which students merit a machine. Second, there’s another good bit of administrative work that goes into obtaining permission to enter the homes of students who receive machines, since the parents almost always need some assistance in connecting the GNU-Linux machines to the Internet. Third, the work in students’ homes is, in itself, time-intensive and a real challenge to carry off on a volunteer basis.

But the promise for further developments in this area is underway. We are creating a non-profit service to seek funding to carry out many of the time-consuming tasks at the school and in students’ homes — tasks that are very much beyond the scope of an all-volunteer effort.

Lessons learned

There are a few basic lessons to be learned from my involvement with helping one public charter middle school migrate to FOSS:

1. Help yourself by helping the underdog. Harvard Business School professor Clayton Christensen advises that disruptive innovations such as GNU-Linux will take root among “over-shot” customers, meaning customers who are either unwilling or unable to pay for the goods and services offered by the market leader. In this particular case, the school would have purchased Microsoft products if they had the money, but their limited budget forced them to keep an open mind and adapt to the idea that FOSS was perfectly suitable for their needs. They didn’t turn up their noses at FOSS or say that it was not good enough for their kids. They prided themselves on being creative and inviting our Linux user group into the school to see what FOSS could do to help them deliver a high quality technology experience on a budget. Their creativity and gumption in this regard became a point of pride for them.
2. Respect the power of marketing. Microsoft and Apple have plowed billions of dollars into creating and managing customer expectations. It will take years for you to mitigate that mindset, unless you happen to come across a staffer who “gets” how powerful FOSS can be. Don’t trash-talk the non-FOSS vendors. During my initial interview with the principal, she asked if I was a “Microsoft hater.” I truthfully said no, I have used Microsoft products for many years and I understand that Microsoft products are the correct choice for some people. I emphasized that I intended just to offer a different set of solutions that might work better for some users. I could tell that question was an acid test. If I had said that I hated Microsoft, the principal probably would have concluded the interview and shown me the door.
3. Take it one step at a time. This is a corollary of the second item. Don’t think that you will change attitudes overnight. Due to the massive marketing prowess of Microsoft and Apple, consumer attitudes are firmly ingrained. Give yourself several years to make progress against those expectations by providing intensive, real-world experience with the power of FOSS.
4. Be willing to accept a heterogeneous environment. This is also a corollary of the second item. I don’t work on Microsoft Windows or Apple machines, but I also don’t bad mouth them. Be prepared to smile and nod when someone praises non-FOSS technology. No one likes a grouch.
5. Keep the principal happy. This item almost goes without saying. The principal is the captain of the ship. Make sure to engage with the principal on his or her terms. Consult with the principal as appropriate. Take the time to cultivate a relationship and make sure that you understand what makes that individual tick. He or she sets the culture and the terms for the entire school. Few teachers will cross the principal or risk alienating him or her.
6. Gain allies among the teachers. Many principals will delegate significant responsibility to teachers, particularly as regards the conduct of their classes and the structure of their classrooms. Seek out one or two or three teachers who will go to bat for you in crucial meetings at which you are not present. Remember that in their eyes, you will always be an outsider, not someone who bears the strain of managing a classroom of wiggly students day in and day out. Acknowledge your status as an outsider, and show deference to their sacrifices.
7. Get to know the community. Teachers and principals, for the most part, do their work out of love for young minds. Get to know them, and try to share their passions and pains to the extent that you, as an outsider, can.
8. Learn the rules, and follow them assiduously. This is another item that almost goes without saying. Parents and teachers are fervently protective of students, and rightly so. Check in with the principal and teachers frequently. Take nothing for granted. Get permission for every single thing that you do, particularly if it involves speaking with a student.
9. Let the code teach freedom, and don’t preach too often. Most people view computers as toasters, and many teachers are technophobes who expect computers to work perfectly every time. Don’t spend too much time extolling the (considerable) virtues of Richard Stallman’s Four Freedoms. Let the code demonstrate those freedoms. Stallman’s Four Freedoms are like red hot chili peppers — a little bit goes a long way.

Conclusion: Set One School Free

In the response to the current economic climate, President Barack Obama has issued a call for volunteerism. Now is a good time for “penguinistas” and “GNUsters” to heed that call and volunteer to be part of a team focused on moving just one institution such as a school to FOSS. It is often difficult work, but that difficulty can be an advantage for the FOSS community.

Malcolm Gladwell tells a story that is illustrative here. This story is about a girls’ basketball team that managed to win despite being comprised of short girls who were new to basketball and couldn’t shoot all that well — especially three-point shots.

But this girls’ team was a winner. Their success was due to simple hard work, not talent. Unlike almost all other teams, this team from Redwood City, California, played a full-court press all game long. Running a full-court press is mentally and physically exhausting for the girls and even for the coach, so most coaches just have their players concede the back court and wait for the offense to come dribbling over the mid-court line.

In fact, most teams that the Redwood City girls’ team opposed were not ready for a full-court press for the full game, not even otherwise really good teams. The opposing coaches and players were shocked and even offended that the Redwood City coach was introducing such keen competitiveness into children’s team sports. So the game-long full-court press was, according to Gladwell, both physically exhausting and “socially horrifying,” although completely within the written rules of the game. But hard work and the guts to do something different meant that the Redwood City girls team both had a winning season, and, more important, learned to re-frame the game so as to play to the strengths they had (determination and hard training) rather than their weaknesses (poor shooting ability).

The lesson that Gladwell draws from this story is that underdogs can win when they work hard and focus on their strengths. Microsoft is a wealthy corporation that sits smack in the middle of an extensive network of committed businesses whose earnings are dependent on the continuation of the Microsoft dominance. But Microsoft and its business partners lack a few things that the FOSS community has going for it: free code that is legal to share and a passion for freedom in cyberspace. Also, there is an inadequate margin for them in servicing schools, although the margin can be adequate for FOSS vendors who typically have smaller cost structures.

To conclude, I would like to encourage each reader to adopt one school or one non-profit, or some other kind of underdog, and commit to giving some amount of time or money to support a successful migration at that institution. It will be hard and inconvenient and maybe even “socially horrifying,” as it might call you to sacrifice time with a loved one or cause other hardships that will cause you and others to occasionally question the wisdom of your actions. But the future of digital freedom is worth it! If we keep that fire alive, we can restore balance, competition, and basic freedom to the consumer desktop market.

But let’s put the business of proprietary software and increased revenues aside for a second and consider: what will happen to all of the open source software (OSS) components of Sun — especially MySQL, which is a competitor of the Oracle database? After all, this is the question most people in the open source community are asking themselves right now. Sun is currently the firm with the largest contributions (lines of code, total dollars, and ongoing dollars) to core projects released under open source licenses. Just to name a few, they’re the backers of Java, MySQL, OpenOffice, Open Solaris, and NetBeans.

Considering the number of projects and amount of money that Sun contributes to open source, they have the power to influence the entire open source market — power which may now lie in the hands of Oracle. It’s clear that Oracle is purchasing Sun primarily to increase revenues, but what is not clear is if Sun’s open source projects were profitable themselves. It’s hard to calculate the marketing value that open source projects brought to Sun, but either way Oracle will gain the customer base that Sun built. This leaves a potentially undesirable outcome for Sun’s open source projects and the open source community as a whole.

It’s possible that Oracle will scrap many of Sun’s OSS projects to reduce their costs and cut out any unnecessary departments in order to simplify the merger and increase profits. As of 2006 Sun had contributed approximately $390 million to OSS. These are costs Oracle may not want to take this on as they are trying to make the acquisition profitable as quickly as possible.

Why should you care?

Sun has been responsible for the single largest corporate investment in open source software to date. In addition, Sun’s actively-funded and well-supported OSS projects are at the core of the open source community.

A short list (seriously) of some of the open source projects to which Sun contributes includes:

• GlassFish
• GNOME
• Grid Engine
• JavaDB
• java.net
• Jini Network Technology
• JXTA Technology
• Linux
• Mobile & Embedded
• Mozilla
• MySQL
• NetBeans
• OpenDS
• Open ESB
• OpenJDK
• OpenCDS
• Open Media Commons
• Open MPI
• Open HA Cluster
• OpenPrinting
• OpenPTK
• OpenOffice.org
• OpenSPARC
• OpenSSO
• OpenSolaris
• OpenxVM
• Portal
• PostgreSQL
• Project Darkstar
• Project Fortress
• Project LookingGlass
• Project Woodstock
• Roller
• VirtualBox
• X.Org

The Players

Sun Microsystems

Sun has been an advocate and champion of open innovation driving networked computing. Their recent direction seems to clarify who they are . . .

• Green Computing
• Open Source Software (of course)
• Security
• Open Standards
• Open Storage

And let’s not forget . . .

• Java
• The network is the computer
• The dot in dot com

Oracle

Oracle built its business around proprietary software licensing. It is a company not known for its sponsorship of the open source community. Oracle is more focused on very tactical investments in open source.

Oracle and MySQL

MySQL itself poses many problems for Oracle.

1. It costs lots money to maintain a project with limited license revenues.
2. MySQL is an actual competitor with the Oracle database.

So what is Oracle going to do with MySQL, “the world’s most popular open source database” and one of the top five databases in use? With a significant portion of the market, Oracle can’t just throw MySQL to the side once they get the chance. If they don’t control where the extra market share will go, competitors like Microsoft SQL Server — Oracle’s largest proprietary competitor — will benefit from the dismantling of MySQL.

Oracle might want to transition the MySQL user base over to the Oracle database. One way this could play out is Oracle offering MySQL as a “light” database, which would still be open source, and give customers the option to upgrade to the paid premium Oracle database. The transfer of database would be only one way so that customers filter into the paid Oracle database.

Oracle and OSS

Another way to analyze this situation (as opposed to profitability) is to look at the background and core values of each company. It is clear that Sun has a much larger stake in OSS than Oracle, as they are the largest commercial contributor to OSS, but Oracle has also had their hands in open source development. Oracle’s open source stance, as stated on their website is that:

Oracle is committed to developing, supporting, and promoting Open Source. Oracle has been, and continues to be, committed to offering choice, flexibility, and a lower cost of computing for end users. By investing significant resources in developing, testing, optimizing and supporting open source technologies such as Linux, PHP, Apache, Eclipse, Berkeley DB, and InnoDB, Oracle is clearly embracing and offering open source solutions as a viable choice for development and deployment. Today, many customers are using Oracle and supported open source technologies in mission-critical environments and are reaping the benefits of lower costs, easier manageability, higher availability, and reliability along with performance and scalability advantages.

Now is a great opportunity for Oracle to show their support by taking on Sun’s larger commitments to open source software. Oracle has a choice to either cut out down Sun’s open source developments to increase profitability or harden their open source values.

Oracle and Commercial Open Source Software

Scott McNealy said in 2005, “Open source is free like a puppy is free.” According to Scott, Sun has a growing and dominant business taking care of puppies — all those enterprises with applications built on open source software and running on Sun hardware.

There is of course the third possibility that Oracle will increase their support of open source because it’s actually profitable. However, this remains an ongoing test for open source. Sun believes that open source support can be profitable, but does Oracle?

As Larry Augustin stated on his blog, it was rumored that Oracle was willing to pay $850 million for MySQL last year, before Sun ended up buying the company for $1 billion. It’s a bit ironic that Oracle could now get MySQL pretty much for free, but Oracle did once — and potentially still does — see value in MySQL and the open source model. OpenOffice also has the potential to battle Microsoft Office, with a little tweaking here and there. If Oracle can fit open source into their business model and make it a profitable venture, OpenOffice could be a contender in a market monopolized by the Microsoft suite, which would make it the real sleeper in this acquisition.

Hindsight

Looking back at other large mergers, we can see how this play by Oracle might end up.

Sun/Netscape, Who?

One case we can look at actually involves one of the parties currently involved, Sun. Back in the 90’s when Sun merged with Netscape, the merger was called the Sun-Netscape Alliance. A striking feature of this merger that you may notice is that the “Netscape” part of the deal disappeared along with the 90’s. Sun effectively bought Netscape’s software and discarded the brand name, which had value in itself and was later sold to AOL. Applying that model to the current situation generates a few interesting questions:

• Will we see Oracle dismantling Sun for only the parts that are explicitly valuable?
• Will they dismantle the hardware and open source departments and focus in on Java and Solaris?
• Could Oracle focus on taking out Microsoft with OpenOffice and disregard all of Sun’s good work in security, open source, green computing, and more?

The open source community should hope that this is not the scenario that the merger will follow. One of Sun’s core values is open source software, and as this merger takes place Sun may defend their open source departments if they are called into question.

The Time Warner Tail Wagged the AOL Dog

On the flip side, a merger that turned out quite differently was AOL-Time Warner, in which AOL bought the much larger Time Warner for $164 billion. In this case the business model of AOL turned out to be flawed, and it was Time Warner’s core values that ended up on the better side of the merger. Over the following years AOL-Time Warner reported large losses in the tens of billions, and in the end it was the buyer’s name that was dropped, leaving Time Warner as the company left standing.

This scenario may come to fruition if two things are true. First, Oracle would have to believe that open source is not worth capital investment. Second, open source would need to prove that it is indeed the business model of the future for tech companies. A misjudgment of the market such as this could lead to a decline in Oracle’s power while Sun’s power rises. If Sun’s core values ultimately lead the new company, it could be a large boost to open source software and Sun could rise again.

Summary

We may be getting far ahead of ourselves, seeing as the acquisition is far from complete. They still have to finalize the deal and go through the review process from the U.S. Justice Department and Federal Trade Commission. This is, however, an important development to the open source community. The result will depend on the truthfulness behind Oracle’s statement of support for open source. Many companies believe it still poses a risk too high to take on, but this could be due to excessive FUD (fear, uncertainty, and doubt).

There are plenty of upsides to Oracle strengthening its stance on open source. Oracle could better contend with competitors like Microsoft and may usher in a new business model for the next generation of computing. Open source has great potential to add value to a company, and this may be Oracle’s chance to explore the business possibilities.

References

• http://ab-at-sun.blogspot.com/2008/01/sun-is-largest-enterprise-contributor.html
• http://blogs.zdnet.com/BTL/?p=16598
• http://gigaom.com/2009/04/20/oracle-to-buy-sun-for-74-billion/
• http://blogs.zdnet.com/Gardner/?p=2903
• http://marketing.openoffice.org/planet/
• http://news.cnet.com/8301-13505_3-10223090-16.html
• http://lmaugustin.typepad.com/lma/2009/04/oracle-buys-java-and-mysql-for-free.html
• http://www.oracle.com/technology/tech/opensource/oracle-open-source-faq.html
• https://fossbazaar.org/content/free-puppies

But when open source fans try to use open source software at work they often find that their manager, or their manager’s manager, has a lot of concerns. After trying to battle them, they usually end up bringing in an outside expert to talk their manager into it; or they simply abandon their plan altogether.  It’s just too much work to convince management that it’s okay to use open source.

Now, we don’t want to point any fingers, but you know what often happens next. Authority is questioned, quiet revolutions happen and the next thing you know, open source software is being used — discreetly, unofficially — just to prove that it works! There’s got to be a better way. Well, fortunately there is. In this article we’ll outline some strategies you can use to convince your manager to use open source software, along with tips on how to make those strategies effective.

• Make sure you understand how proprietary software is acquired.
• Find out what your manager thinks about open source.
• Address all of management’s questions and concerns … preferably in advance.
• Bust the prevailing myths about open source software use.
• Create infrastructure.
• Take a shortcut or two (at your own risk!).
• Build your plan.

Make Sure You Understand How Proprietary Software is Acquired

Often, developers don’t really know how their company acquires software. They need something; so they tell their manager and a piece of software somehow gets purchased and shows up on their desk. (Or, probably more likely, they are told what software they need to use and they just download it from a central repository.) At most large companies, there’s a whole software procurement process. Many have tried simply adding open source software to the existing process.  Although open source doesn’t usually fit the existing  process perfectly, it’s best to try to use as much of that process as you can — while simply adding steps to address the issues that are unique to open source software.  So, while it’s unlikely that you’ll be able to fit open source software into your procurement process without making any changes at all, being able to discuss how you’ve addressed all the issues your company cares about concerning the procurement of software will certainly help your case. Examples of things that a procurement process normally covers are:

• Price. Both up front and on-going costs are at issue. This includes the price of acquiring the software, installing and integrating it, and providing maintenance and support. It’s best to address each of these potential costs, even if your company’s particular use of open source software may not involve them all.
• Source Code Escrow. The procurement process usually addresses what will happen if the software company goes out of business. Often there’s a clause stating that the customer will get a copy of the source code, along with the right to continue using the product. While this isn’t usually an issue for open source software, it is worth pointing out what you’ll do if your contract with a provider of open source software ends or if the company goes out of business.
• Support. Who is going to support this software? With the proprietary software procurement model, it’s often obvious who is responsible for support; which means this issue is really more about the terms of support: 24×7, work hours, numbers to call, etc.

Find Out What Your Manager Thinks about Open Source

Don’t assume that you know how your manager feels about open source software. There’s a chance they know all about open source software and use it all the time at home. There’s also a chance that they’ve fallen for every myth. Your manager:

• may be a big open source fan. In which case the problem may be your manager’s manager.
• may not know anything about open source software and be afraid to admit it. In this case, provide lots of information in a non-threatening way.
• may think open source is bad or threatening. Right or wrong, your manager may have already decided open source software is bad. If you can, try to figure out why they’ve reached this conclusion. Maybe someone they know has had a bad experience or maybe they read an article with misinformation.
• may believe every myth you’ve ever heard, and some you haven’t, about open source software. Be sure to address all the myths, not just the ones that are anti-open source. Addressing all of them, even the ones that would help your cause, makes you look knowledgeable (and impartial) about open source software — which will ultimately help your cause.

Outside sources can also be helpful in addressing management’s  concerns about using open source software. Depending on your manager’s learning style, you might point them to online resources like Wazi or to books like the Cathedral and the Bazaar (you can find a list of books here) or to conferences like OSBC.  You could even pull in an outside expert to speak to them — perhaps on the phone to start with.

Address Management’s Questions and Concerns… Preferably In Advance

If your manager (or their manager) is not familiar with open source software, they’re going to have a lot of questions. Be sure to anticipate and answer them before you make your proposal. Note that open source software is generally considered more secure than proprietary software for a number of reasons, including: many, many more people reviewing the code, many people testing and submitting bugs and more frequent releases to address any issues.

Here are some questions and concerns that managers often have about open source software.

Why Are These People Doing This for Free?

One of the things that often baffles management is why these people (i.e., developers) are working on open source software for free. They aren’t necessarily worried that you get what you pay for. They are more suspicious that developers may have ulterior motives and, without understanding those motives, they can’t evaluate whether or not open source software is free.

Open source software developers write open source software:

• to “scratch an itch”. The most common reason people start writing open source software is because they want something. For example, they want their screen to flash instead of beeping when they get new mail because they can’t hear or they spend lots of time in meetings. They want the weather to show up on their desktop. They want to be able to share their files with their friends.
• to fix a problem they’ve had or a problem they’ve seen. This is an extension of scratching your own itch. Once people discover they can solve their own problems and they release their software, they discover that others find the software useful as well, and will submit bug fixes and ideas for features.
• for recognition. One of the most powerful forces behind open source software is one that is often not recognized. Open source software is a meritocracy and individuals are recognized for the strength of their code. Being known as someone who writes good code and maintaining your reputation is a strong motivator.
• because they enjoy writing software. You may want to leave this reason out, as it’s really hard to convince people that don’t write software that it is true. People who write code really enjoy writing code. Coding is often not only fun but very addictive.

Where Does It Come From?

This is closely related to the “why do they write it” question, but with a slightly different spin. When a manager asks this, it’s like they’re saying: who are these people? The answer is, they are software developers. They’re professionals who write software for pay during the day, and write open source software during their free time or for their employer (see addiction & itch-scratching, above). You can find several studies with more information on the web, but here are some rough stats:

• 40% of open source software developers are paid to work on open source software. The rest are volunteers.
• It’s easy to tell if an open source software project relies mainly on the work of one company.
• Most open source software developers are men (less than 2% are women).
• Most have families and full time jobs.
• Most are employed as full time software developers.
• Open source developers are a very international group. (Red Hat recently created an open source activity map that shows where open source software developers live worldwide.)

There’s No Support

Support in the open source software world looks a little different than support in the world of  proprietary software. Naturally, this often leads people to conclude that there is no support for open source software. It’s not true! There are often even more support options for open source software than there are for proprietary— at least for the more popular projects. In the proprietary software world, it’s obvious that if you buy AIX from IBM, you are going to buy your support from IBM. In the open source software world, you may get Linux from a random website and then purchase support from any number of vendors.

It’s a Security Risk

Because open source software is written by individuals spread out across the world instead of by large companies, and because all of the source code is visible, people often initially assume that it’s a security risk. The open source community has successfully shown this isn’t true. Today open source software is viewed as at least as secure as proprietary software.

It’s a Legal Risk

There’s been a lot of fear created around open source software and legal risks. The truth is that any business action carries some legal risks. The legal risks of open source software are just different from the risks of using traditional proprietary software. A good policy can help address and mitigate the legal complications your company might face. See Best Practices for Creating an Open Source Policy for more information.

You’ll Give Away Our IP

Many people are very fearful of the copyleft nature of the GNU General Public License (GPL) under which a lot of open source is released. They are afraid that if they use GPL-licensed software, they will have to give away all of their software. Often they allow the use of open source software, with the exception of any licensed under the  GPL.  Clearly, if you want to make sure your company doesn’t prohibit software licensed under the GPL, you should address tis one early. There are many ways to make sure you don’t accidentally copyleft your software. They range from not copying any GPL-licensed software into your code base, to not linking to any GPL software from your code, to not distributing any GPL-licensed software (or anything derived from it.)

Bust Prevailing Myths

Here are some of the more common myths concerning open source software. Address both the “good” myths and the “bad” myths. It will help in the long run if your management really understands open source software.

• If you don’t modify the code, you’re good. Many companies believe that as long as they don’t modify the source code, they don’t have to worry about which license open source software has. Some even create a policy that prohibits the modification of open source code because then, they think, they are risk free. While modifying open source software may cause support problems, modifying code isn’t usually what triggers anything in the license.  For example, the GPL says that if you make modifications to the software, you have to distribute those modified source code files with your binaries.  But it’s the distribution that triggers that clause, not the modification.  So if you distributed the binaries unmodified, you’d have to distribute the source code.  And if you linked statically to those GPL-ed binaries, you’d have to distribute your source code as well — but only if you distributed your product.  If you’re just using it within your company, it really doesn’t matter whether you modified it or not — except from a support perspective.
• If you modify GPL code, you have to give the modifications back to the project. While it is smart to contribute your modifications upstream (i.e., back to the project), it’s not a requirement.  Under the GPL, you only have to give the modified source code to anyone to whom you distribute the binaries.  It’s smart to contribute your modifications back upstream because then you are using the standard product, not a special, forked version. If there are any problems, it’s much more likely someone else will also encounter them and a fix will be made quickly. It also makes upgrading to the next version much easier, and open source software projects typically release new versions often.
• Distributing GPL code under a non-disclosure agreement (NDA) doesn’t really count as distribution. Many attorneys believe that distributing GPL code under a NDA doesn’t really count as distribution.  Further, they think that the recipient can give that GPL product to anyone they want to — under the terms of the NDA — regardless of what the NDA actually says. Unless you’re comfortable releasing your software under the GPL license, don’t release code linked with GPL code under non-disclosure.
• If you are only using open source software internally, you don’t have to worry. Actually, you probably do need to worry a little. First, you should remember that software rarely stays internal. It’s almost always shared with a partner or vendor, or a company is acquired or sold.  Second, many licenses have clauses that are triggered by something other than distribution.  Sometimes they’re simple, and sometimes they aren’t.  For example, one license says that you have to buy a copy of the developer’s book for every developer on your team, regardless of whether you redistribute or not. Another license says you have to buy the developer a beer if you see him at a conference. These may seem like trivial clauses to you, but company attorneys are paid to worry about things like whether or not every employee will even recognize the developer at a conference, let alone buy him a beer.
• Anybody can sue me for the misuse of open source software. Only the person who owns the copyright for a piece of software can sue you for violating the license.  Typically, the person who owns the copyright is also the person who wrote the code.  They can, however, give that copyright away.  They can even give it away and keep it for themselves — so now two people hold the copyright.  The copyright holder is also the only person who can change the license on a piece of software.  This is why SCO lost their lawsuit.  (SCO sued IBM for allegedly contributing SCO intellectual property to Linux, but in the end the court ruled that SCO didn’t hold the Unix copyright, so it couldn’t have been their intellectual property.)
• There is no support for open source. First off, lots and lots of products are open source.  The support options vary widely, from the do-it-yourself variety to multiple companies competing for your business.  (OpenLogic supports hundreds of open source software products.) The challenge is that you sometimes have to do a lot of research — a product’s name doesn’t necessarily give you a direct clue to the company that supports it; or you might come up with more than one name and have to compare several companies.  Regardless, there are lots of companies and individuals out there supporting open source software.
• Freeware and shareware are open source. Freeware and shareware are not open source.  All things free are not open source.  Just because it’s free, doesn’t mean it’s open source. (There, we’ve said it three times now, in three different ways.) The freeware and shareware licenses are very different, and they do not meet any of the traditional open source guidelines around things like providing source code, allowing modification, and redistribution.

Create Infrastructure

Many companies decide they need an open source policy and an open source governance process before they use open source software, but then stall in the process of deciding how to create that infrastructure. It may help you to have a preliminary draft of an open source software policy and governance process that is specific to your company’s needs. The danger is that if you make it available, your project may be stalled until the policy and process are approved. On the other hand, showing that you’ve not only thought about the policy but have created a draft based on research might help show that you understand the risks and benefits of open source software. It could be a relief to your management.

If you do decide to create a policy and governance process, check out these guides to writing an open source software policy and creating an open source governance process.

Useful Shortcuts

1. Bring in an outside expert. Often it’s just easier to trust an outside expert. Remember when you were a kid and your mom wouldn’t believe you, but she believed the neighbor? It’s the same here. If you do bring in an outside consultant, make sure you work with them closely and help them understand your company’s internal situation as well as what you are trying to accomplish.
2. Just do it. Ask for forgiveness instead of permission. Do this one at your own risk! Sometimes it works to just use open source software and then show that it’s been working for a while, saving you time and money, and nothing disastrous has happened. Be sure you can show that you’ve considered all the risks, addressed all the issues, created an informal policy, etc.
3. Have a fire. There’s nothing like creating change in an organization like finding a problem that can only be fixed in time … with open source!

The Plan

As promised, here’s a plan you can use to convince your management that it’s in your company’s best interest to use open source software. You’ll have to do quite a bit of preparation work, but in the end it’ll be worth it because of the time and money your company will save by using the open source software solutions you’ve found in a way that minimizes the risks.

1. Know what software you want to use.
2. Make sure it works well. Know it.
3. Figure out how to address all the points that your company normally would in acquisition.
4. Know where your management is concerning their knowledge of, and beliefs about, open source; and know how to address all of their concerns and perceived risks.
5. Put together a document that:
   1. States the problem you are trying to solve.
   2. Describes the software you want to use.
   3. States plan for transition, support, etc.
   4. Addresses risks.

Conclusion

If your manager is already an open source fan, then convincing her to use open source software might be really easy, and the two of you will be able to focus on building the plan and creating the infrastructure to use open source software effectively. If your manager is not familiar with open source software or has an active fear of the risks associated with it, it might take you a little longer. But you’re not alone! Many open source fans have successfully used the strategies in this article to bring open source software into their companies in a way that saved their companies time and money — improving their businesses. If you are one of those people, please share any additional tips or suggestions you have in the comments!

Best of luck to all you open source fans!

Creating an open source policy manual is the first step companies typically take to help manage the use and adoption of FOSS, and this is usually followed by setting up the right governance processes to help implement the policies. Companies often struggle with several questions they need to answer in establishing these processes. This article will help you identify some of the common questions and factors to consider when setting up an open source governance process. We’ll also provide practical tips on some of these areas based on what organizations have done in the real world.

Please note that this article builds heavily on Stormy Peters’ excellent guide: Best Practices for Creating an Open Source Policy. If you haven’t already done so, be sure to read that article before proceeding any further.

Why do you need an open source governance process?

There’s hardly a company today that does not interact with FOSS to some degree. These interactions range anywhere from using FOSS as part of their internal IT infrastructure, to distributing it as part of a product they sell. Some of these interactions may even be unintentional. For example, a company may buy third-party software that incorporates FOSS components.

FOSS can enter a company through many channels, most (if not all) of which may not be set up to track its flow through the organization. While many consider this non-traditional fluidity one of the key benefits of FOSS, it does pose certain challenges in today’s world of corporate accountability. In fact, tracking FOSS in your company usually goes beyond the well understood need for audits and compliance. Information collected as part of FOSS governance can be an invaluable tool in making strategic decisions and is often used as a competitive advantage.

A well designed open source governance process can help your company:

• Track the various FOSS projects (and associated licenses) that are currently being used in your organization.
• Identify all the areas that have a key relationship with FOSS and the nature of that relationship (consumer, participant, maintainer, etc.)
• Establish a direct communication channel to all of the key stakeholders for any timely updates related to FOSS (e.g., upcoming license change of a FOSS package you depend on).
• Integrate FOSS reviews into your regular corporate work flow so nothing falls through the cracks.
• Cultivate mutually beneficial relationships with FOSS projects and communities that are important to your company.
• Relax. While an open source governance process won’t pay for your vacation, it will certainly help provide the peace of mind that comes with knowing your organization is well equipped to maximize FOSS benefits while minimizing risk.

It is also key to understand that there are a lot of variables that will influence your choices in each of the sections outlined below. These variables include:

Organizational maturity: Whether your company is a 20 person start-up or a 200,000 person enterprise will have a strong impact on all aspects of your FOSS governance process.

Primary business: FOSS, in the context of this discussion, is a key part of your technology arsenal. If your primary business is in the technology space, FOSS could have an undeniable role in your strategy. On the other hand, if your company relies on others to provide technology expertise, you may also need to procure FOSS expertise from similar external providers.

Existing processes (procurement, product/service releases, public relations, etc.): FOSS will affect all aspects of your organization. In some cases you may need to augment existing processes, while in others you may need completely new ones.

Organizational culture: Your FOSS governance process will need to fit in with your existing organizational culture in order for it to succeed. For example, this could mean deciding between a heavyweight process that is very structured and implemented top-down, a lightweight process that is more informal and driven organically from the bottom up, or some hybrid of the two. Organizational culture is intangible and can be difficult to incorporate in governance processes, but it can make the difference between a process that struggles for adoption and one that becomes a great success.

Keep these variables in mind as you read through the sections below, and while planning and designing your FOSS governance process.

Common factors to consider before implementing a governance process

Before you embark on creating an open source governance process, here are a few items you should already have lined up:

• An open source strategy and policy
• Sponsorship and organizational support
• Funding
• FOSS expertise, gaps, and dependencies identified
• Metrics and tracking

Let’s look at each one of these in a bit more detail.

An Open Source Strategy and Policy

An open source governance process puts your open source strategy and policy to work. It’s only natural that you need an open source policy in place before you start designing and implementing an open source governance process.

However, this is not a hard requirement. Organizations often start with a process and a loosely defined policy. It is not uncommon to find even large organizations where one person has been entrusted with the responsibility of figuring out an open source policy and process.

That said, starting from a policy gives you the benefit of knowing what your organization expects from its relationship with FOSS. With that knowledge, you can develop a process that complements and accelerates the implementation of that policy. It also ensures that the amount of time, money, personnel, and effort you invest is in tune with your company’s expectations with regard to FOSS.

Sponsorship and Organizational Support

Since FOSS interfaces with almost all aspects of an organization, your FOSS governance process should follow suit. In large organizations, this usually means you will need to navigate organizational charts and interact with people at various levels. Once the process is in place, you’ll need to convince some of these same people to use it.

Ensuring the governance process is sponsored at a sufficiently high level goes a long way towards opening doors. In organizations that take a strategic view of FOSS, the Chief Technology Officer (CTO) usually is the executive sponsor for FOSS strategy and its implementation.

Similarly, the personnel who will use the governance process on an ongoing basis should be involved in its design so as to give them a sense of ownership later on. This also gives them the opportunity to share insights about what will work and what won’t. To do this, you should identify the various touch points your organization has with FOSS. These may include:

• Procurement
• Information Technology (IT)
• Product Development
• Service Organizations
• Mergers and Acquisitions
• Alliances and Partnerships

Funding

Implementing an open source governance process is going to require some investment. Funding is typically necessary to cover a variety of expenses, including:

• Hiring one or more people to run and maintain the process.
• Training the various groups within your company who are going to actually use the process.
• Covering costs associated with developing or licensing any software that might help implement the process.
• Bringing in the occasional outside expert or consultant.

FOSS Expertise, Gaps, and Dependencies

Since your open source governance process is going to serve as the central, company-wide resource for FOSS expertise, you should identify sources of such expertise as well as any key gaps and dependencies. This could include legal experts with deep knowledge of various FOSS licenses, community experts who practice the fine art of FOSS community building, and training partners who offer both broad and deep sessions based on your needs. Note that it is highly likely that at least one or more of these experts may be outside your company.

Metrics and Tracking

The renowned psychologist George Miller once said: “The chance is negligible that you will measure the right things accidentally.” A well designed FOSS governance process is going to turn up several pieces of data that, if tracked and measured, can provide some astonishing insights into your company’s FOSS adoption.

Here are a few examples of such patterns that can be detected as well what you can do with the data:

• What are the top open source projects that your company depends on? How good is your relationship with these communities?
• Who are the developers that contribute most to open source projects? Is there a particular department that tends to adopt and contribute to FOSS significantly more (or less) than others?
• How long does a typical open source review take? Where are the bottlenecks?
• What are all the products/services that interact with Project X and/or License Y?

As you can see, by planning ahead you can ensure that you measure and track the key pieces of data that are important to your unique needs and goals.

By incorporating the above list into your planning, you will be well equipped to design and implement a FOSS governance process tailored to meet your company’s needs.

How to Develop and Maintain an Open Source Governance Process

Once you’ve had an opportunity to plan the key aspects of your open source governance process, you’re ready to develop and implement it.

As you begin designing the governance process based on your plans, you’re likely to face decisions around some common design factors, which we’ll describe below. One approach in developing your FOSS governance process is to view each of these factors as modules that must be properly integrated to create the right governance process for your company.

Centralized vs. Decentralized

This is a classic question that one faces when designing a process of moderate to high complexity. While there are numerous benefits to choosing one or the other, your FOSS governance process is probably going to be a mixture of the two. This is especially true for large companies that have separate departments or business units. Usually these departments operate with a lot of autonomy in almost all aspects of their business. In addition, they may each have defined their own processes for certain common areas.

In the case of a FOSS governance process, there is immense benefit to having a central data store that tracks FOSS usage and contribution across the entire company. In addition, operating a central review body such as the Open Source Review Board (OSRB) outlined in Stormy Peters’ article on policy creation adds value. The OSRB can provide an additional layer of checks and balances in addition to centralizing key tasks that may be performed redundantly across various departments.

However, such centralization can also easily turn into a bottleneck.

One way to balance this is to identify the minimal set of process artifacts that really need to be centralized as opposed to others that can be delegated to individual departments. For example, everybody across the company may be required to use a central database to store FOSS proposals and reviews, while individual departments may choose to enforce stricter requirements for compliance than those the central OSRB recommends.

Existing vs. New Process

This is another common question that comes up when designing a FOSS governance process. One school of thought suggests that FOSS should simply be treated as any other piece of third-party software and, as such, existing processes for third-party software should be leveraged for FOSS as well. The other approach insists that FOSS is different from third-party software and necessitates the creation of a separate FOSS governance process. The former may prove sufficient if your FOSS strategy is primarily centered around using FOSS to lower software costs. If you’re looking at FOSS in a much more nuanced manner, then the latter is probably the way to go.

Note that just because you have defined a separate governance process for FOSS does not mean you cannot reuse certain existing work flows. For example, an organization that uses Bugzilla to track defects in their software may decide to use the same tool to track FOSS usage and contributions as well.

Tools and Automation

A FOSS governance process can benefit greatly from the proper application of the right tools for help in automation. Fortunately, there are several ready-made options available. The following is a short list of these options. Descriptions of their functionality, pros and cons is a topic for a separate article.

FOSS options:

• FOSSology http://www.fossology.org/
• OSSDiscovery http://ossdiscovery.opensource.collab.net/
• Tiddly-Guv http://trac.tiddlywiki.org/browser/Trunk/contributors/MichaelMahemoff

Commercial options:

• BlackDuck http://www.blackducksoftware.com/
• Palamida http://www.palamida.com/
• Protecode http://www.protecode.com/

In many cases, you may find that some combination of the tools above will provide the solution that is most helpful to you.  Also, while it may be tempting to design your process around one or more of these tools, doing so could result in a sub-optimal FOSS governance process. This is why you should define your policy, develop your process, and only then choose the right tool(s) to help automate your process.

Web Presence

In addition to the tools that help you implement your FOSS governance process, you should consider setting up a FOSS portal. Depending on whether you will also be contributing to FOSS, you may actually need both an internal and an external facing portal.

The internal portal will help serve as the central resource for all things related to FOSS within your company. These are some of the common portions of an internal FOSS portal:

• Documentation on your company’s open source policies and strategy.
• A clear description of the FOSS governance process, its work flow, roles, and responsibilities.
• FAQs, project and license advisories, training guides, and other useful self-service resources.
• Any tools associated with the FOSS governance process and associated guides.
• A list of case studies of various FOSS reviews that have been approved (or denied) by your Open Source Review Board (OSRB).

An external portal usually includes sections such as:

• An overview section highlighting your company’s open source strategy.
• A detailed list and descriptions of the various FOSS projects your company is involved with and its role in these communities.
• Technical articles, white papers, developer interviews, etc. that provide greater insight on specific projects and people.
• A list of upcoming events where representatives of your company may be available to interact with customers and the FOSS community.

One common section that should be present on any portal is the “Contact Us” section. You should establish clear, easy lines of communication with the consumers of your FOSS governance process. This will be crucial to ensure there is a free flow of information both in and out of the FOSS governance process.

Launch and Roll-Out

Once you’ve developed your FOSS governance process and are ready to implement it, you should consider doing so in phases. A targeted pilot for a short period of time can help test all aspects of your process. In addition, it can provide valuable feedback on areas that need to be refined before proceeding with a more widespread roll-out.

After your FOSS governance process has been in place for a while, you may want to measure its effectiveness. Analyzing the data you’ve collected to see if it matches your expectations is one way to measure this. In addition, you may want to perform random audits across your company to test both coverage and adoption.

Keep in mind that just like your FOSS policy, your governance process is also going to require ongoing changes to keep up with the evolving needs of your company.

Critical factors that can help you implement a successful governance process

In addition to the items covered above, the following is a list of practical recommendations that can help you implement a successful FOSS governance process.

We Are Here to Help, We Are Not the Police

Design, develop, and run the process as a resource that’s available to help rather than yet another piece of bureaucracy that will result in roadblocks. There are several intricacies associated with FOSS adoption that people will be more than happy to not have to keep up with and instead rely on a trusted internal source that does the job for them. However, if employees start perceiving the process as a Big Brother, they may try working around it.

The Only Thing Constant is Change

FOSS moves at a rapid pace. As your organization matures in its usage of and contribution to FOSS, be prepared to evolve your open source governance process to keep up with the rate of progress.

There is No Such Thing as Over-Engineering

Well, actually there is. Try to keep the process and its various interfaces as simple as you can without compromising on its effectiveness. The last thing you want is to have a process so complex to understand that nobody uses it.

Communicate, Communicate, Communicate

This is especially key for large organizations where new processes can easily get lost in the labyrinth of corporate communications. You will need to market the governance process through emails, webinars, blogs, word of mouth, and any other media that’s effective in your company.

Engage Those Open Source Champions

All companies have people who are agents of change. These dynamic individuals are at the forefront of new ideas and innovation happening in the company. Find the people who champion FOSS adoption in your company, and cultivate a good relationship with them. Sometimes, you may need to identify them via external forums such as open source project mailing lists, blogs, and twitter. Our advice is to track them down, buy them a cup of coffee (or a beer), and enlist their aid as you design, perfect, and market your FOSS governance process.

Summary

Now that you’ve read this article, you should have a clear understanding of the benefits of having a formal FOSS governance process. You should also have a framework with which you can plan, develop, and implement a governance process. So go to it! With this information you should be able to create and implement a process that aligns with organizational culture, structure, and goals so that your company can successfully execute its FOSS strategy.

Mark Radcliffe and Dianne Brinson are the authors of The Internet Law and Business Handbook. (The book is currently out of print and undergoing revision, but you can reserve a copy of the next edition by sending an email to mradcliffe@sonic.net.) We’ve commissioned them to supply a series of articles to cover most of what you need to know about the legal issues you’ll encounter doing business on the Net. Among the detours into Internet Law they describe, you’ll find the answers to these (and other) burning questions:

• Does copyright protection apply to the work of Celestial Beings?
• How about my work? Beauty and artistic merit aside, does it qualify?
• How do I obtain a copyright?
• How original does “original thought” actually have to be?
• Trademark, copyright – what’s the difference, anyway?
• How secretive is a Trade Secret, and what have I got to do to keep mine securely under wraps?

Mark and Dianne cover a lot of ground here, so we’ll provide you with a quick summary. Sit up and pay attention, now. Internet users in the United States need to be aware of four major intellectual property laws:

• Copyright law
• Patent law
• Trademark law
• Trade secret law

If you’re to avoid ending up on the wrong side of the law, you’ve got to be able to define which category your work falls under, and you’ve got to know how to make the system work for you. Our first article in the series covered copyright law, defining the types of work that are covered, and the standards to which those works must adhere. The authors have come up with some great examples to brighten up the legalese, and they outline the procedures that must be followed in order to protect your own work.

Last month’s article on patent, trademark and trade secret law examined the basics of United States patent law as defined under the Patent Act. What’s covered? What are the standards? How do you protect your work? Read the article for answers to these questions, and you’ll discover the value of novelty, usefulness and (we love this term) non-obviousness, too. If you think you know it all already, go ahead and skip straight to the latest Security Issues, but we remind you that you ignore Internet Law at your peril.

This month’s article on ownership of copyrights is the last in the three-part series. Our legal experts will explain the Copyright Act, as well as touching on ownership regulations for patents, trademarks and trade secrets. If you acquire, make use of, or develop content for the Web, you really do need to understand this stuff. Some of the examples given hit closer to home than is comfortable; as in the story about the Marketing Director who was really pretty darn sure she had the permission she needed to use those photos on her company’s site, or the curious story of the Web Developer and the Shopping Cart.

We want the best for you, we really do. And we sincerely hope that all your Physical Fitness dreams come true—as a matter of fact, we recommend that you get up from your desk and stretch right now.

Better? Good.

Now all you need to do is read the article that follows and you’ll have kept at least one of your New Year’s resolutions. You’ll be thoroughly informed about issues of Internet Law, and that really is, well, big. You can always get back on that diet when you’re finished reading!

Ownership of Copyrights

This article covers the Copyright Act’s ownership rules, and, in less detail, the ownership rules for patents, trademarks, and trade secrets. Ownership rules discussed here apply only in the United States. Other countries have their own rules of intellectual property ownership.

The intellectual property ownership rules discussed in this article are default rules that apply if the parties—employer and employee, employer and independent contractor, Web developer and client—do not reach their own agreement, in writing, on ownership.

Introduction

You need to understand copyright’s ownership rules if you acquire, use, or develop Web content. Here’s why:

The types of material used for Web site content—music; graphics; text; and video, film, and television show clips—are protected by copyright, as are Web site designs and software. If you want to use copyrighted material belonging to a third party on your Web site, generally you need the permission of the copyright owner. Only the permission of the true owner will protect you from an infringement suit. Getting permission from someone who mistakenly believes he or she is the copyright owner will not protect you.

Example: Web Marketing Director saw some photographs she liked on Z Company’s Web site. Director contacted Z Company’s president and got permission to use the photographs on the Web site owned by Director’s company. The photographs were created for Z Company by a freelance photographer. If the copyrights in the photographs are owned by the photographer (likely) and Z Company does not have the right to sublicense the use of the photographs, Z Company cannot authorize Director to use the photographs. Only the photographer can. Getting permission to use the photographs from Z Company will not protect Director if the photographer sues Director for copyright infringement.

If you create Web content or commission freelancers (graphic designers, writers, or photographers, for example) to create Web content, you should give careful consideration to the question who will own the copyright in that content. The exclusive rights of copyright discussed in Internet Law Part I: Copyright Law belong to the copyright owner.

Example: Web Entrepreneur commissioned Graphic Designer to create graphics for a Web site. If Web Entrepreneur owns the copyright in the graphics, then Entrepreneur has the exclusive right to reproduce and modify the graphics for use on another Web site. If Graphic Designer owns the copyright, Entrepreneur needs Graphic Designer’s permission to reproduce and modify the graphics for use on another Web site.

If you are involved in Web site development, either as a developer or a client, you should give careful consideration to the question of who will own the copyright in Web site designs and program code, for the reason just discussed.

Example: Web Developer created a Web site for Client. The Web site includes a shopping cart program. Whether Web Developer can use the shopping cart program in projects for other clients depends on who owns the copyright in the program.

INITIAL OWNERSHIP

Ownership of copyright initially belongs to the author or authors of the work. 17 USC § 201(a).

Example: Sarah, a photographer, took a photograph of the Lincoln Memorial. Sarah is the author of the photograph and the initial owner of the copyright in the photograph.

The “author” is generally the individual who created the work, but there is an exception for “works made for hire.” This exception is discussed in the next section.

THE WORK MADE FOR HIRE RULE

The “author” of a work made for hire is the employer or hiring party for whom the work was prepared. This default ownership rule is known as the work made for hire rule. Unless the parties have agreed otherwise in a signed written document, the employer or hiring party owns the copyright of a work made for hire. 17 USC § 201(b).

There are actually two branches to the work made for hire rule: one covering works made by employees, and one covering specially commissioned works. 17 USC § 101. We discuss these in this section.

Works Made by Employees

A work created by an employee within the scope of his or her employment is a work made for hire. The employer for whom the work is made is the author of the work for copyright purposes and is the owner of the work’s copyright (unless the employee and employer have agreed otherwise).

Example: As part of his job, John, an employee of Big Company’s training division, created original interactive training materials on e-commerce for Big’s marketing staff. Even though John created the training materials, Big is the author for copyright purposes. Big owns the copyright in the training materials (unless John and Big have agreed in a signed contract that John owns the copyright).

The work made for hire rule does not give employers ownership of works made by employees outside the scope of their employment.

Example: Darryl, an engineer at Productions, Inc., does nature scene watercolors in his free time. The work made for hire rule does not apply to Darryl’s watercolors. If Productions wants ownership of the copyrights in the watercolors, it must get an assignment (discussed in “Assignments,” below) from Darryl.

Specially Commissioned Works

The second category of works made for hire is limited to nine types of specially ordered or commissioned works. These are works commissioned for use as:

• A contribution to a collective work.
• Part of a motion picture or other audiovisual work.
• A translation.
• A supplementary work.
• A compilation.
• An instructional text.
• A test or answer material for a test.
• An atlas.
• A sound recording.

For these types of works, if the hiring party and independent contractor creating the work agree in writing, before the contractor begins the project, to designate the work as a work made for hire, the work is a work made for hire. If the parties do not have an agreement to treat the independent contractor’s work as a work made for hire, it’s not a work made for hire.

Example: Game Company hired Don, a software developer, to design the software for Game Company’s new online game (an audiovisual work). Game Company and Don did not agree in writing to consider the software a work made for hire, so the software is not a work made for hire. Don owns the copyright in the software.

Even if the hiring party and independent contractor agree in writing to consider the independent contractor’s work a work made for hire, the work is not a work made for hire unless it falls into one of the nine special categories listed in the first paragraph of this subsection.

Example: Sarah commissioned John, a freelance painter, to do an oil painting of Sarah’s home. Although Sarah and John agreed in writing that the painting would be considered a work made for hire, the written agreement does not make the painting a work made for hire because the painting is not in one of the nine categories of works that can be specially commissioned works made for hire. If Sarah wants to own the copyright, she needs an assignment (discussed in “Assignments,” below) from John.

The rules governing ownership of copyrights in works created before January 1, 1978 (the effective date of the Copyright Act of 1976), were different from the rules described in this article. The 1909 Copyright Act did not distinguish between employees and independent contractors (works created by both independent contractors and employees were automatically owned by the employer or hiring party unless the parties agreed otherwise). In the case Community for Creative Nonviolence v. Reid, 490 US 730 (1989), the U.S. Supreme Court made it clear that the current Copyright Act does distinguish between employees and independent contractors.

The issue in Reid was who owned the copyright in a sculpture created by the artist Reid for the Community for Creative Nonviolence (CCNV). The Court concluded that the work made for hire rule did not apply for two reasons: Reid was not an employee of CCNV, and the sculpture was not one of the types of works that could be designated a work made for hire by written agreement of the parties.

Foreign Copyright Law

The work made for hire rule discussed in this article applies to copyrights in the United States. Other countries have different rules on copyright ownership. Although many countries have rules similar to the first branch of the Copyright Act’s rule (works made by employees), the second branch (specially commissioned works) of the U.S. rule does not exist in most countries.

To obtain international copyright ownership for works that fall within the second branch of the Copyright Act’s work made for hire rule, parties that commission works should obtain assignments of copyrights (see “Assignments,” below) from independent contractors.

JOINT AUTHORSHIP AND OWNERSHIP

According to the Copyright Act, the authors of a joint work jointly own the copyright in the work they create. 17 USC § 201(a). A joint work is defined in Section 101 of the Copyright Act as “a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole.”

Example: Ann and Bruce worked together to create an e-commerce site, with Ann developing the software and user interface and Bruce developing the content. The work is a joint work, and Ann and Bruce jointly own the copyright.

Of course, if Ann and Bruce worked as employees of an employer rather than as individuals, their employer would be the copyright owner, as discussed in “The Work Made for Hire Rule,” above.

You do not become the author of a joint work merely by contributing ideas or supervision to a work. You do so by contributing material that meets the standards for copyright protection (see “Standards,” in Internet Law Part I: Copyright Law).

Example: Susan suggested that John write a book on how to beat the stock market, and John did so. Susan is not a joint author of John’s book.

Joint Authorship or Not?

Corky Ballas, a competitive dancer, asked a music producer to create a compact disk of music appropriate for dance competitions. Ballas made suggestions about concepts and suggested songs for the recording. When Ballas and the producer parted company, Ballas claimed to be a joint author of the completed CD. The court held that the producer was the sole author, because Ballas had contributed only uncopyrightable ideas and concepts to the project. Ballas v. Tedesco and Ballroom Blitz Music Inc., 41 FSupp2d 531 (DNJ 1999).

When the copyright in a work is jointly owned, according to U.S. law, each joint owner can use or license the work (authorize others to use it) without the consent of the other owner, provided that the use does not destroy the value of the work and the parties do not have an agreement requiring the consent of each owner for use or licensing. A joint owner who licenses a work must share any royalties he or she receives with the other owners.

Many foreign countries (Germany and France, for example) require that all joint owners consent to the grant of a license. Generally, joint ownership is not recommended because of the complications it adds to licensing worldwide rights. In addition, it is unclear what effect the filing of bankruptcy by one joint owner would have on co-owners.

COMMUNITY PROPERTY

In nine states (Arizona, California, Idaho, Louisiana, Nevada, New Mexico, Texas, Washington, and Wisconsin), any property acquired during a marriage is jointly owned by the husband and wife. Whether a copyright in a work created by one spouse during marriage is community property is unclear. In Marriage of Worth, a California state court held that the copyrights in several books created by a man during his marriage were jointly owned by the man and his wife. 195 Ca3d 768 (1987). The court’s reasoning—that the copyrights were community property because they were the result of one spouse’s expenditure of time, effort, and skill during the marriage—could apply to patents, trademarks, and trade secrets as well. However, a federal court in Louisiana recently held that copyrights created by one spouse during a marriage are not community property because treating copyrights as community property would risk damaging the Copyright Act’s goals of predictability and certainty as to copyright ownership and national uniformity. Rodrigue v. Rodrigue, 55 FSupp2d 534 (ED La 1999).

ASSIGNMENTS

A transfer of the ownership of a copyright is known as an assignment. When a copyright is assigned, the assignee (individual or company to whom it is assigned) becomes the owner of the exclusive rights of copyright in the protected work. (These rights are discussed in “The Exclusive Rights,” in Internet Law Part I: Copyright Law.)

Example: Tom, an individual working on his own, created Web development tool software and then assigned the copyright in the software to Software Publisher. After the assignment, Software Publisher has the exclusive right to reproduce and publicly distribute the software. If Tom starts selling the software, he will be infringing the Software Publisher’s rights as copyright owner.

The ownership of copyright may be transferred in whole or in part. 17 USC § 201(d). Examples of partial transfers are an assignment of the copyright for a term of ten years (time limitation) and an assignment limited to California (geographic limitation). In addition, the individual exclusive rights (reproduction, modification, and so forth) can be transferred.

Assignments are common in many industries—for example, music composers often assign copyrights in their compositions to music publishers.

An assignment is not valid unless it is in writing and is signed by the owner of the rights conveyed or the owner’s authorized agent. 17 USC § 204(a).

Is an Email a Signed Writing?

So far, only one court has ruled on the question of whether an email satisfies the Copyright Act’s “signed writing” requirement. That court held that the email at issue in that case was not “signed.” Ballas v. Tedesco and Ballroom Blitz Music Inc., 41 FSupp2d 531 (DNJ 1999). Until this issue is clarified—either through amendment to the Copyright Act or through a general federal electronic records law—don’t rely on emails to satisfy the “signed writing” requirement. (A federal electronic records law is likely to be passed by late 2000.)

An assignment can be recorded in the Copyright Office to give others “constructive notice” of the assignment. Constructive notice is a legal term that means you are presumed to know a fact (because it is a matter of public record) even if you have no actual knowledge of the fact.

Recording an assignment in the Copyright Office to give constructive notice protects the assignee from future conflicting transfers. An assignment that is recorded properly within one month after its signing prevails over a later assignment. If the assignment is signed outside the U.S., the assignee has two months to record it. 17 USC § 205(d).

Example: Songwriter assigned the copyright in her song to Music Publishing Company in Boston on August 1, 1993. On August 15, 1993, Songwriter assigned the copyright in the same song to World Enterprises. So long as Music Publishing recorded its assignment properly in the Copyright Office by September 1, Music Publishing owns the copyright because its assignment prevails over Songwriter’s later assignment to World Enterprises.

A properly recorded assignment even prevails over an earlier assignment that was not recorded if the later assignment meets two criteria:

• The later assignment was taken in good faith and without notice of the earlier assignment.
• The assignee paid money or something of value for the assignment or made a promise to pay royalties.

Example: Author assigned the copyright in his novel to Publishing, Inc. on November 1, 1993. Publishing, Inc. did not record the assignment. On January 15, 1994, Author assigned the copyright in the same novel to Media, Inc. for $10,000. Media, Inc. recorded its assignment in the Copyright Office. So long as Media, Inc. acted in good faith and did not know or have reason to know about Author’s 1993 assignment to Publishing, Inc., Media, Inc. owns the copyright. The assignment to Media, Inc. prevails over Author’s earlier assignment to Publishing, Inc.

LICENSES

A license is a copyright owner’s grant of permission to use a copyrighted work in a way that would otherwise be copyright infringement. A copyright owner who grants a license is known as a licensor. A party receiving a license is known as a licensee.

Implied in every license is a promise by the licensor to refrain from suing the licensee for infringement based on activities within the scope of the license.

A copyright license can be exclusive or nonexclusive. An exclusive license is a license that cannot overlap another grant of rights.

Example: Author granted Publisher the exclusive right to sell Author’s novel in the United States. She granted Movie Developer the exclusive right to create and distribute a movie version of the novel. Both Publisher and Developer have exclusive licenses. There is no overlap between the two licenses.

Under copyright law, an exclusive license is considered a “transfer of copyright ownership.” 17 USC § 101. An exclusive license, like an assignment, is not valid unless it is in writing and signed by the owner of the rights conveyed. A nonexclusive license is valid even if it is not in writing.

No Writing, No Case

During the Cannes Film Festival, New World Entertainment orally agreed to grant Television Espanola the exclusive right to broadcast the television show Spiderman in Spain. Written documents were to be prepared by Television Espanola later. When Television Espanola delivered the documents to New World for signing, New World refused to sign, because by then it had granted the broadcast rights for Spain to another party. Television Espanola sued New World for breach of contract. Television Espanola lost the case because oral exclusive copyright licenses are unenforceable. Radio Television Espanola S.A. v. New World Entertainment, Ltd., 183 F3d 922 (9th Cir 1999).

An exclusive license, like an assignment, can be recorded in the Copyright Office to give constructive notice. Recording the exclusive license protects the license against unrecorded earlier transfers of copyright ownership and against later transfers. (See “Assignments,” above.)

TERMINATION RIGHT

The author of a work other than a work made for hire has the right to terminate any license or assignment granted on or after January 1, 1978 during a five-year period that starts thirty-five years after the grant was made. If the grant involves the right to distribute the work to the public, the termination period begins thirty-five years after distribution begins or forty years after the grant was made, whichever is earlier. 17 USC § 203.

For works published before January 1, 1978, a different rule applies to pre-1978 licenses and assignments: The five-year termination period begins fifty-six years after the work was published. 17 USC § 304(c). For older works in their renewal term in 1998 for which the termination right had expired before 1998, there is an additional five-year termination period beginning at the end of seventy-five years from the date the copyright was originally secured. 17 USC § 304(d).

The termination right cannot be waived in advance. If the author dies before the termination period begins, the termination right can be exercised by the author’s widow or widower, children, and grandchildren. If none of these people are alive at the time the termination right can be exercised, the right can be exercised by the author’s executor, administrator, personal representative, or trustee.

OWNING A COPY OF A WORK

Copyright law distinguishes the ownership of a copy of a protected work (a print of a photograph, a compact disc, a book, a diskette) from ownership of the intangible copyright rights. The transfer of a copy of a work does not transfer any rights in the copyright. Thus, purchasing a book (a copy of a literary work, in copyright terminology) does not give you permission to make copies of the book and sell those copies.

There are several exceptions to the principle that the transfer of a copy of a work does not transfer copyright rights. We’ll discuss the most important ones in the rest of this section.

Displaying a Copy

The owner of a lawfully made copy of a work has the right to display the copy publicly, “either directly or by the projection of no more than one image at a time, to viewers present at the place where the copy is located.” 17 USC § 109(c).

Making a Backup Copy

It is not infringement for the owner of a copy of a computer program to make another copy of the program if doing so is necessary to use the program or for archival purposes. 17 USC § 117(a).

“First Sale” Doctrine

The owner of a lawfully made copy of a work has the right to resell or otherwise dispose of possession of that copy. This exception to the distribution right is known as the “first sale doctrine.” 17 USC § 109(a).

Example: Don bought a copy of Publisher’s new book on Web design. Don can resell his copy of the book. The first sale doctrine gives him that right.

Sale or License?

The first sale doctrine is only triggered by a sale of a copy of a work, not by a license. Software and database products, whether delivered online or in tangible form, are generally licensed rather than sold. Licenses allow software suppliers to tailor products to specific markets. A multiuser site license, for example, provides different use rights and carries a different price from a single-user license. Software and database suppliers also use licenses to obtain protection for factual information and prohibit reverse engineering.

For mass-marketed software and databases delivered in tangible form (diskette or CD-ROM), licenses generally take the form of “shrink wrap” agreements contained on or in the product packaging. Some people maintain that shrink wrap agreements do not create binding contracts because they are “contracts of adhesion” (contracts based on “offers” that give the consumer no meaningful choice). They believe that the typical transaction wherein a consumer acquires a copy of mass-market software or database material is a sale, triggering the first sale doctrine.

Some courts agree with this analysis. The Court of Appeals for the Fifth Circuit held that an end-user software license prohibiting reverse engineering was a contract of adhesion. Vault Corp. v. Quaid Software Ltd., 847 F2d 255 (5th Cir 1988). The Court of Appeals for the Third Circuit also held shrink wrap licenses invalid. Step-Saver Data Systems, Inc. v. Wyse Technology, 939 F2d 91 (3d Cir 1991). However, more recently, the Seventh Circuit Court of Appeals held that shrink wrap licenses are enforceable unless their terms are objectionable on grounds applicable to contracts in general. ProCD, Inc. v. Zeidenberg, 86 F3d 1447 (7th Cir 1996). The court noted that even though the consumer in this case could not review the license terms before concluding the transaction, ProCD’s license gave the consumer the right to reject the product if the consumer found the license terms unsatisfactory.

Sale or License Transaction?

Sometimes the documents used in a transaction use “sale” terminology and “license” terminology, making it unclear whether the transaction is a sale triggering the first sale doctrine or not. In Adobe Systems Inc. v. One Stop Micro Inc., 84 FSupp2d 1086 (ND Cal 2000), Adobe sued a company that had acquired copies of “education versions” (stripped-down, less expensive versions) of Adobe products, removed the “education version” labels, and sold the products to consumers. The defendant claimed that it had a right to distribute the software because it had purchased the copies from educational resellers who had purchased the copies. The reseller agreement used the word “purchase.” Other language in the reseller agreement indicated that Adobe was only granting licenses to educational resellers. The court found that the reseller agreement was a license, so the first sale doctrine was not triggered between Adobe and the educational resellers. The court held that the defendant infringed Adobe’s copyrights by distributing the products without a license.

PATENTS, TRADEMARKS, AND TRADE SECRETS

Patent law does not have a work made for hire rule. Patentable inventions created by employees within the scope of their employment are owned by the employee. However, the employee may have a legal obligation to transfer ownership to the employer under the patent law’s “hired to invent” doctrine. This doctrine provides that when an employee is hired to perform research or solve a specific problem, the employer is entitled to get an assignment of a patent received by the employee on the results of the research. Generally, as a condition of employment, employers require employees to agree to assign their interests in patentable inventions to the employer. The Patent Act implicitly recognizes the validity of such agreements, providing that a patent may be granted to the assignee of the inventor.

A trademark is owned by the first party to use it in connection with goods or services or the first to apply to federally register it. A trademark can be owned by an individual, company, or any other legal entity.

An employer or hiring party generally owns trade secrets developed by employees and by independent contractors who are hired to invent.

Ownership of patents, trade secrets, and trademarks, like the ownership of copyrights, can be assigned. As with copyrights, owners of these types of intellectual property frequently grant licenses authorizing others to do things that would otherwise violate the owner’s exclusive rights.

We’ll start by examining Microsoft Publisher 2007 and Groove 2007, each of which can be replaced by open source equivalents that match or surpass their features and capabilities. For the final two products we’ll examine, Visio 2007 and Project 2007, the open source competitors are not as robust and don’t offer clear enterprise-grade equivalents.

Microsoft Publisher vs Scribus

Microsoft Publisher 2007 is designed for the casual user to create custom publications and marketing materials either from scratch or from one of the hundreds of built-in design templates. A single version license ranges from from $99.95 USD for an upgrade to $169.95 for the full version. It is also included as part of Office Small Business, Office Professional, and Office Ultimate, which range in price from $279.95 to $679.95. Publisher is only available for the Windows platform, and some features do not work on 64-bit systems.

Scribus is an open source DTP (desktop publishing) application designed for casual to professional users. It provides cross-platform support for users running Microsoft, Mac OSX, OS/2, Linux, and BSD operating systems. Support is available through the Scribus community, and the product is mature and very well documented in six languages. While no official import plugin is available, it is possible to import Publisher files into Scribus.

Both Publisher and Scribus can create PDFs, but Publisher first requires the installation of an add-in. The Scribus PDF generator is more flexible, allowing you to customize fonts, presentation effects, output optimization, security, and how the document is viewed. Scribus also allows for the creation of writable PDF email forms.

Publisher integrates tightly into the Microsoft Office Suite. It includes an E-mail Merge task pane, which walks you through a customized mail merge for Outlook 2007. While more complex to setup, it is also possible to create a catalog merge to Access or Excel in order to save graphics and other data sources for reuse. It is also easy to scale and resize graphics in Publisher. Scribus does not provide the ability to scale images, which requires the use of a third party program. The open source Gimp application, which is available for Windows, Mac OSX, Linux, and BSD, is well-suited for this purpose.

The biggest difference for users switching from Publisher to Scribus will be learning how to use the increased functionality, as Scribus delivers the layout and features of a professional-quality DTP application. Anyone expecting a simple office editor—or lacking previous experience with DTP applications—will immediately discover that applications like Scribus are different. These users should read the short and informative Scribus Basics and will also benefit from the other documentation links on the Scribus Basics page. In addition, Publisher users will be surprised at the lack of built-in templates, although additional Scribus templates are available from the project website.

Scribus Document Setup Screen

Microsoft Groove vs O3Spaces Workplace

Microsoft Groove 2007 is a collaboration platform that uses workspaces to provide file-sharing, discussions, meetings, and business forms with automatic synchronization. A single version license is $229 USD. Groove is also bundled with Office Ultimate, which costs $539.95 for the upgrade and $679.95 for the full version. Some Groove features require a Sharepoint server, which is only available through volume licensing, and other features require Infopath, which is bundled with Office Ultimate or available for $199 as a standalone product. Instant messaging requires Microsoft Messenger or Communicator. Groove is only available for the Windows platform, and some features are not available on 64-bit systems.

O3Spaces is a cross-platform collaboration tool for Microsoft Office, OpenOffice, and StarOffice. It supports OpenLDAP, Active Directory, Sun Directory Server, and Novell Directory Server groupware solutions. O3Spaces is available for Linux, Solaris, Windows, and Mac operating systems, and the community version is freely available for teams of up to 10 users. Professional, Enterprise, and On Demand editions are available by support subscription and are intended for production use. Subscription pricing starts at 49 Euro per person per year.

Groove and O3Spaces both provide the ability to work offline and offer real-time alerts on all relevant changes in your workspaces. Both products provide collaboration tools within the workspace, such as discussion forums and calendars to help keep tabs on team schedules. Groove also allows you to make phone calls or use instant messaging directly from a workspace. Through the purchase of individual language packs at $24.95 USD each, Groove provides localization for 28 languages. O3Spaces currently has built-in support for 9 languages. However, the localization API isn’t currently public, and new localizations require direct interaction with the O3Spaces developers.

O3Spaces provides some interesting features, which make it a useful product even for individual, non-collaborative use. For each of the supported office suites it adds plugins to provide automated document versioning, a secure document repository, and full text search of ODF, PDF and Microsoft Office documents. An assistant automates all necessary document retention and versioning activities, and an application embedder enables the integration of external web applications, such as wikis and websites, into the workplace environment. You can also store emails as related documents in the same workspace. Perhaps the most useful workspace features are the ability to drag-and-drop spacelets in order to reduce clutter and the ability to create multiple tabs within a workspace.

O3Spaces Workspace through Firefox

Microsoft Visio Alternatives

Microsoft Visio 2007 is a diagram creation tool that provides a wide range of templates for flowcharts, network diagrams, workflow diagrams, database models, and software diagrams. Pricing for the standalone product varies from $129.95 USD to $559.95. SharePoint Services is required for certain advanced collaboration functionality. Visual Reports requires the more expensive Visio Professional version as well as Microsoft Project, Excel, or SharePoint Services.

The 2007 version of Visio provides several new features, including auto-connect and auto-align, auto-refresh with resolve conflict capabilities, PivotDiagrams, and themes. It provides the ability to export to PowerPoint format and, with the PDF add-in installed, to convert to PDF format. Visio Viewer, a free download, is required to view Visio documents in a browser, but only Internet Explorer is supported.

Dia is often touted as the open source Visio equivalent, but it is targeted towards the casual, non-enterprise user. Dia is available for Linux, Irix, BSD, and Windows platforms. It provides the most built-in drawing objects of any open source Visio wannabes, and the Dia Manual is an excellent resource. However, Dia cannot import or open Visio files, and experienced Visio users will miss Visio’s slick auto features and built-in templates. Support is limited to the Dia community.

Dia Object Selection

KDE users may be interested in seeing if Kivio meets their needs, as it is bundled with the KOffice suite. Kivio comes with a good-sized collection of objects, which it refers to as stencils, including DIA objects. It also provides  an “Install Stencil Set” option so you can install your own objects. KOffice is stable for Linux and BSD and is available for Mac OSX, and a Windows version is under development. The Kivio Handbook describes its features and explains how to use them.

Add Stencil Set in Kivio

OpenOffice users may want to try using Draw. Draw provides glue for “smart connecting” objects, but you’ll have to scour the Internet for objects because very few are built-in. For example, you can download a zip file of Cisco’s network icons, unzip them to a directory, and insert each object as a file as needed. Once you have created your own library of icons, it’s fairly simple to create diagrams within the familiar editor interface. However, the lack of templates and objects, as well as the documentation on how to obtain them, can be frustrating.

Draw Toolbars and Shapes

Microsoft Project Alternatives

Microsoft Project 2007 is used to track the timelines, costs, and assignments associated with a project. It’s available as a standalone product priced between $349.95 USD and $999.95. The more expensive Professional version and Project Server 2007 are required for enterprise project and resource management capabilities, publishing projects, using Windows Workflow Foundation, and for the Project Tasks List. In turn, Project Server requires Windows Server 2003 and SQL Server 2000. Project is only available for the Windows platform, and some features are not available on 64-bit systems.

New features in the latest version of Project include automatic highlights of all items that shift as a result of the most recent change, and undo and redo functions that allow you to visualize what-if scenarios.

OpenProj is a cross-platform project management solution for Linux, Unix, BSD, Mac, and Windows. It can import from and export to Microsoft Project files. Support is available from OpenLogic and Serena Software, which also provides the Project-ON-Demand hosted SaaS solution as a monthly subscription. However, there is very little documentation for the open source edition. Eleven localizations are currently available, but further documentation and translation efforts require direct communication with Serena Software.

OpenProj Gantt Chart

Feature-wise, both Project and OpenProj support Gantt charts, PERT charts, WBS and RBS charts, and earned value costing. However, OpenProj does have some limitations. The ability to create PDFs is only available with the subscription version, and there’s no wizard for creating a project. The tools are all there, but you have to know ahead of time what and how you want to create the project. Projects can only be saved as XML or the proprietary Serena pod format.

Another open source alternative to Project is GanttProject, for which commercial support is not available but access to the associated open source community is easier. GanttProject offers some extensions as well as an introduction for developers, and the manual provided in the Help menu of the application is usable but far from complete. Feature-wise, GanttProject does offer some wizard-like functionality by asking a few questions when you create a new project, and it supports over 30 localizations. In addition, it can export to raster image, CSV file, HTML, PDF, or Microsoft Project. GanttProject is available for Linux, BSD, Mac OSX, and Windows.

GanttProject Create New Project Wizard

Conclusions

Due to its cross-platform support, cost, and advanced feature-set, Scribus makes an excellent open source replacement for Microsoft Publisher 2007. Users will have to spend some time learning its capabilities and creating their own customized templates, but that time will be well-spent and result in greater flexibility for document creation later on.

With its commercial support, cross-platform capabilities, and advanced feature-set, O3Spaces is a superior product to Microsoft Groove 2007. Both enterprise and casual users can benefit from the features it adds to the default Microsoft Office, OpenOffice, and StarOffice suites.

Enterprise users who need the ability to easily create complex diagrams should probably stick with Microsoft Visio 2007. Casual users who need only the occasional diagram or have time to search for diagram objects can save the price of a Visio license by trying one of the open source alternatives.

Enterprise users should do their own research into OpenProj and GanttProject to see if either provides all of the project management features they require. If features are missing, users should consider the long term costs of getting those features implemented into the open source version versus the cost of Microsoft Project 2007 licensing. Users should also be aware of the fine print regarding which Microsoft products are required to get all of the needed Microsoft Project features.

Why do you need an open source software policy?

At first many companies question the need for an open source software policy—primarily because they think it will be too difficult to create. Policy creation does require a lot of work and cooperation, but by following this guide you should be able to create and roll out an open source software policy in less than a month.

Some of the main benefits to having an open source software policy include:

• Ensuring the company is in agreement about how to use open source software. Companies often start drafting an open source policy when somebody in management realizes they don’t know how much their IT department or software products depend on open source software. A clearly-stated policy can help ensure that everyone in the company is on board with your open source strategy and that employees feel like they’re empowered to use open source software where appropriate.
• Maximizing the benefit of open source software. By creating a policy, you will put processes in place that will enable employees to use open source software effectively as well as share knowledge and workload between teams. For example, three different teams won’t independently figure out how to get support for the same project, and different employees won’t independently evaluate the same upgrade. Having an open source software policy and sharing information across the enterprise will enable your company to maximize the benefits of the open source software it uses.
• Minimizing the legal, technical, and business risks of using open source software. Executive management and attorneys are often very concerned about being sued for using open source software, getting caught without sufficient technical support, or receiving bad publicity related to how open source software is used. An open source software policy can not only minimize those risks but also show concerned employees how the company is addressing those needs.

The process of writing an open source policy

The key to writing an open source software policy is just to get started! Companies typically either write, approve, and adopt an open source software policy within a month, or else they spend months working on a policy and yet fail to gain company-wide approval on the finished product. By following these steps you can ensure your company has an approved and adopted policy within a few weeks:

• Identify key stakeholders
• Get stakeholders to buy into the concept of a policy
• Figure out your company’s strategy
• Create the first draft of the policy
• Get widespread review and acceptance, starting with your stakeholders
• Repeat last two steps as necessary

Stakeholders

Your first step—the one important to making sure that your policy is adopted—is to identify the stakeholders in your policy. There are several types, ranging from those who care desperately because you might change their ability to do their job (like developers) to those who care desperately because they think a bad policy might get them fired (like CIOs and those who report to them.) Be sure to include people who you think will disagree with your policy—better to address their disagreements upfront than to have them fight the policy because they don’t like one part of it.

While you’ll have to use whatever strategies work best in your organization, getting all of the stakeholders involved as soon as possible will help your policy get widely adopted more quickly. The more your stakeholders feel like it’s their policy, the better. The best case scenario is if they can say they reviewed it and feel comfortable with you (or whoever is writing the policy) taking care of the details.

As you put together your list of stakeholders you should consider:

• Developers—the people who will have to follow the policy
• IT staff, as they probably download and use open source software
• Managers of teams that use open source software
• Attorneys
• CIO and staff
• Technical architects; many companies have architectural committees, and they should be involved

You’ll probably have two groups of stakeholders: the key stakeholders who will need to approve the policy, and the people who will be affected by the policy.

Strategy

An open source software policy is meant to help your company’s strategy—both its general strategy and its open source strategy.

For example, you might see open source software as a way to reduce your IT costs. In this case your strategy should not be to “use as much open source software as possible,” but rather to “reduce IT costs by using open source software.” This will enable all of your employees to make the right decision when it comes to choosing between open source and proprietary solutions. The policy will then help your company reduce IT costs—not just by encouraging the use of open source software that has no licensing fees associated with it, but by also leveraging the preexisting open source knowledge of your IT staff.

On the other hand, you might want to build an online community around your company’s product. In this case your strategy might be to use open source software in order to encourage outside developers to help build out features that enable your community to grow. Your interest is in the community, not in making money through software sales, so you might even want to open source your own software and grow a community around it.

Identifying your open source strategy upfront will not only help you figure out your policy, but it will also help you explain to others why it’s the right policy for your company.

Here’s an example of what an open source strategy statement might look like:

Background Statement

Many open source software policies start by talking about the problem they’re trying to solve. Whether or not you need this section probably depends on your company. You may need this section if:

• Management doesn’t know how much open source software the company uses or depends on.
• There are widely varying opinions on how much open source software is used.
• There’s an open source software rule or policy that conflicts with reality (e.g., “No open source allowed,” but your IT infrastructure is built upon open source software).
• There are big disagreements on how the company should use open source software.

If you decide you need a background statement, make it brief. Some key things to include in the background statement (if you know them) are:

• How much open source software the company currently uses.
• How much open source software has or will save you—not just monetary savings, but also consider reductions in development time, consulting time, learning curves, and so on.
• Any risks to be aware of—for example, your 24×7 website depends on an open source software package for which there is currently no defined support process.

A background statement in an open source policy might look like this:

Scope

Your company may have many policies, and it may be obvious who they cover. However, with open source software policies it is often necessary to define not only who is covered but what is covered.

Who’s Covered

Most companies with an open source software policy adopt the policy company-wide. However, for many organizations it makes more sense to have a very brief company policy that simply states the strategy and provides some general guidelines for how to use open source software. Then, each division is allowed to elaborate and expand on the policy to meet its needs. In other cases, a particular division creates a policy and later tries to get the company as a whole to adopt it.

Don’t forget to specify subsidiaries and agents in this definition. You might want to consult with an attorney about whether giving open source software to the company’s agents or subsidiaries is considered distribution, as distribution triggers clauses in some open source software licenses.

Also, you might want to specify whether or not the open source software policy applies to everyone or just to employees in certain jobs or roles. For example, you may not care how your IT staff uses open source software in the internal IT environment, but you want to ensure that all software developers working on applications that are distributed to others are aware of the open source software policy.

Whatever you decide, make sure it’s clearly stated and that you have the right people review and approve the policy. The example below illustrates one approach to defining who’s covered by a policy:

What’s Covered

There’s a lot of misunderstanding and disagreement about what exactly qualifies as “open source software.” One common misconception is that freeware, free to use, and free for personal use only licenses are open source software licenses.

Companies typically decide that any software released under a license approved by the Open Source Initiative (OSI) is considered open source software.

You need to define what is covered and what is not covered by your company’s open source software policy. Many companies have different standards for open source software used in IT, development, and production environments.

You’ll also need to think about what qualifies as open source software and what usage cases need to be covered.

• Does the policy apply to using software inside the company?
• Does it apply to shipping software?
• To freeware? People often assume anything that doesn’t cost money is open source software—that’s not true, and you need to explicitly include or exclude that type of software.

An open source policy might address the issue of what qualifies as open source with language like this:

Ownership

Your open source software policy will be a living document. As business conditions change, your company becomes more comfortable using open source software, and new open source software packages and licenses become available, you’ll want to adapt the policy to the new situations. In addition, an individual or team needs to be available to answer questions, provide training, and approve any exceptions.

Although an individual usually writes the open source software policy, a committee or open source review board should own the policy. A review board is most effective when it represents the main divisions in the company. If every group feels like they’re adequately represented, you’ll get better buy-in and compliance later on.

When to Make Exceptions and Who’s Allowed to Make Them

Only a couple of people should be allowed to make exceptions to the open source software policy: the owners of the policy, and the business group or manager who’s allowed to decide that the business benefit outweighs the risk of breaking from the policy.

Approval Process

While it’s easier create an open source software policy before establishing an approval process, in reality the opposite usually occurs. Someone is responsible for making open source decisions, and he or she ends up pulling together a group of people to create an informal approval process. Once established, even informal approval processes can become quite elaborate and efficient.

If you don’t have an approval process, you’ll want to sent one up. If you have one, you’ll need to review it with your open source policy in mind.

Who’s Part of the Open Source Review Process?

You may want to establish a cross-divisional open source review board. This is usually the same team that owns the open source software policy. It should definitely include an attorney or work closely with one.

You’ll also want the review board to include any teams that will use approved open source software, as it’s important that they agree with the policy as well as the process. They can give you feedback to make sure the process integrates smoothly with their work flow so that reviews happen quickly and issues are resolved smoothly.

What Information Should Be Reviewed?

Decide what information should be included in the review process. At a minimum you’ll want each open source usage request to include:

1. Name of the employee submitting the request.
2. Name and version number of the requested open source software package.
3. Source of the software (website from which it was downloaded).
4. List of the licenses associated with the software and any bundled components.
5. Business reason for the request.
6. Platform on which the software will be installed.
7. Plan for integrating the open source software into other software currently being used or produced.
8. Whether or not there are plans to modify the source code (Y/N). If yes, explain the reason for modification.
9. Whether or not there are plans to distribute the open source software, either modified or not (Y/N). If yes, explain the reason for distribution.
10. Plan for supporting the software, monitoring for security updates, and performing upgrades.

Next, decide on the process for reviewing requests. You’ll probably save a lot of unnecessary reviews by asking local management and attorneys to review requests before they’re escalated to the corporate open source review board.

Best practices for open source approval processes include:

• Ensure quick turn-around on all requests. If the approval process takes weeks, developers will skip it because they need to download open source software and get their job done. Your approval process should take one or two weeks at most.
• Ensure all review board members are committed to the process. You should be prepared to replace people as the original members move onto other interests or discover they don’t have enough time anymore.
• Have a really good “pre-approved open source list”. You can pre-approved by license, package name, and/or usage models.
• Get lots of attorneys involved. While there may be an attorney on the review board, it will help if you have attorneys close to the team involved. They will best be able to understand how the open source software will be used, and they can help field questions. Educate these attorneys over time.
• Create an exception process, but do your best to set it up in a way that minimizes the use of exceptions.
• Make public within your organization all open source requests as well as the review board results. If people can see what has been requested and why certain packages were approved or denied they can tailor their requests appropriately, saving you a lot of time.
• Define some standard business reasons for your organization. Depending on your open source strategy these could vary from “saving time by using existing technology” to “saving money by eliminating licensing fees” to “getting buy-in from technical adopters by enabling them to see how product is developed.”

Audits

Although your policy can require all open source software be reviewed and approved through a defined process, it’s impossible to enforce by brute force—open source software can easily and freely be downloaded from the Internet. In order to make sure your approval process is effective and that employees are following it, you’ll need to define an audit process.

The flowchart below illustrates a typical open source audit process:

Sourcing

Your policy should explicitly state the websites and methods through which employees are allowed to obtain open source software (sourcing) and how to decide whether a particular open source package is the right piece of software for the job (selection). Who can download software? Where can they go to download it? Do they need permission before downloading? Before using? Before distributing?

Many companies allow developers to download software and try it before going through the approval process. Attorneys are often uncomfortable with this because employees can use the software before the license is reviewed. However, businesses typically balance this concern with the fact that the risk is relatively small while the developer is just evaluating the software.

Most companies end up adopting a free-for-all open source download and maintenance program—every team that needs an open source software package is permitted to download it and figure out their own support options. This is highly inefficient and often leads to the situation where a company is using many different versions of the same software package as well as duplicating evaluation and upgrade processes every time a new version is released.

Other companies have adopted the idea of an open source repository in which approved open source packages are stored. Employees who need to use open source software are required to download it from the repository instead of the Internet. While an excellent idea, this approach often leads to failure because it’s difficult for a single company that’s not in the open source software business to create and maintain a comprehensive open source repository. The repository often ends up outdated and missing many useful open source software packages. If you go with this approach, you’ll need a very good process for handling requests to add new open source packages or versions to the repository. Alternatively, you can use an open source repository provided by a third-party, like OpenLogic Exchange (OLEX) from OpenLogic.

A policy that defines how and where employees can obtain open source software might look like this:

Alternatively, your policy can allow employees to make a judgment call when it comes to sourcing:

Note that while many attorneys recommend that no software be downloaded until the license is reviewed and approved, this is rarely followed. Your policy needs to take into account the legal risk of downloading software for testing or trial purposes before attorneys have a chance to review it. Adding a clause like this can help mitigate the risk:

Selection

Selection is the process of deciding whether or not a particular software package meets your needs and quality standards. In addition to any testing and standards processes already have in place, you might want to consider additional aspects for reviewing open source software such as:

• Support: There are many support options for open source software, but which options are available and which you should choose may vary from package to package.
• Community: Is there an active open source community for the package? Are bugs fixed quickly?
• Quality: Is the software package reliable? How does it compare to similar open source packages?

For a list of other factors to consider around open source package selection, see the OpenLogic Certification Process white paper.

A policy might approach the issue of open source selection with language like this:

Your policy may also outline what to do in case an open source project “ends” or forks. For example, the policy might define a timeframe in which the team has to find a different open source package to replace the original package:

Mergers and Acquisitions

Don’t forget to include a section in your policy about mergers and acquisitions. Enterprises often fail to investigate open source usage or policy until after a target company has been acquired. It makes much more sense to check beforehand. You’ll need to make sure your company’s mergers and acquisitions team is aware of the internal open source policy as well as the need to investigate open source policy and usage at target companies prior to completing any acquisitions. Open source tools such as FOSSology and OSSDiscovery can be run to identify the open source software deployed within a target organization.

A policy might approach the issue of mergers and acquisitions with language like this:

Support

Technical support in the open source world has a bad reputation. While many people think there’s no support available for open source software, the real problem is that there are too many choices for open source software support—and few of them resemble what people are used to in the proprietary world.

Options vary from do-it-yourself (by following mailing lists and even fixing critical bugs yourself) to paying a third party for a complete support and maintenance contract. The table below shows some of the common options:

An open source policy might address the issue of technical support with language like this:

Maintenance

Once the decision to use open source has been made, the process of downloading it and getting it to work is often challenging and satisfying. However, it can be frustrating to track the project for security updates, solve problems, and figure out when to upgrade to a new version.

Your open source policy should provide guidance on maintenance concerns by addressing the following issues:

• Security updates: Who’s going to be responsible for staying abreast of security updates? This often requires subscribing to a mailing list.
• New versions: Who’s going to figure out when you should upgrade to a new version? Deciding when to upgrade can be hard because open source software projects release new versions often. While some projects are very good about specifying what’s new, what’s changed, and what’s gone, others are not. Someone will have to evaluate each release and decide whether or not to upgrade. In addition, you’ll need a process to ensure that only one or two versions (or as few as possible) are deployed within the company. In particular, you’ll want to ensure the company doesn’t fall too far behind the latest version available from the open source project, as communities rarely support previous versions for long.
• Bugs: When a bug is discovered, what’s the process for reporting it to the open source project? Your policy should also specify when and how employees can fix bugs and submit bug fixes to open source projects. (You may want to provide some training about how best to create and provide patches, as it’s in your best interest to make sure patches are accepted upstream.)

The maintenance section of your open source policy should specify whether or not company employees can modify open source software. While you’ll probably want to encourage people to not modify open source software (unless they are planning on fixing a bug or adding a new feature to contribute upstream), it’s likely that some packages will require modifications to work in your environment or process. Your policy should specify when that’s allowed and how changes are documented for maintenance.

An open source policy might address the issue of ongoing maintenance with language like this:

Contributions

Your open source policy should include a clear statement about whether or not employees can contribute code changes to open source software projects. There are several situations in which you’ll probably will want employees to contribute. For example, if an employee fixes a bug, you’ll want him or her to contribute the patch to the project so that you don’t have to maintain a unique patch through every version upgrade. In addition, by contributing code your company might gain credibility within the open source community. If your company actively contributes to a project, the community will be be more likely to recognize employees and quickly respond to their emails when issues arise.

Situations to consider when thinking about whether employees can contribute code changes to open source software projects include:

• Can employees post questions and answers on mailing lists? While many companies are afraid of what employees may accidentally reveal on mailing lists, it’s best to give them the proper training on confidentiality and then let them work on mailing lists. Not only will they build credibility for themselves and the company, but it’s often one of the best ways to get help with a problem. Disallowing employee contributions on mailing lists will impede employees’ ability to use and support open source software solutions.
• Can employees post bug reports to the bug tracking system? Unless there are very good business reasons not to, you should allow employees to post bug reports in order to ensure they can be fixed in a timely manner that will work for the company.
• Can employees fix bugs and submit their patches? Employees often need to fix simple bugs in order to get things up and running. When they do, it’s in the company’s best interest to ensure the bug is fixed in a general way that’s acceptable to the project so it can be submitted upstream. This will simplify support over the long term and help build credibility for the company.
• Can employees contribute features to an open source project? Can they become project contributors?
• Can employees work on open source software projects in their free time? On the same project(s) they work on in the office? On unrelated projects? How do you decide if a project is unrelated to the company’s business?

An open source policy might address the issue of open source contributions with language like this:

Some open source policies state that employees can only interact with open source communities using personal email addresses, not company email addresses. Note that if you include this rule in your open source policy, your company will never develop any credibility with the community.

Communication

Although many companies try to hide that fact that they use open source software, it rarely remains a secret—especially for organizations that decide to provide their own support using internal resources. It’s best to establish a policy for how employees should communicate with open source communities and other interested parties, even if you intend to limit communication about open source usage as much as possible.

Your open source policy should provide guidance on communication by addressing the following issues:

• How can employees communicate with open source software projects? (For more on this topic, see the Maintenance section above.)
• How can employees communicate about open source usage at conferences? Employees will likely want to attend open source software conferences, which provide an excellent opportunity to meet open source project maintainers. If employees can talk about which open source packages they’re using and even present case studies, it will help them meet the right people and gain credibility for your company. The open source software community likes hearing about how their products are being used.
• How can employees communicate about open source usage in documentation? If you ship products that contain open source software, you may have to display the open source software licenses in the product documentation (depending on the licenses). You might also want to say something to end users about what you’re using and why, depending on the type of end users. For example, if you sell TVs that use open source software you may need to display one or more licenses in order to comply with them, but you probably don’t need to spend a lot of time talking about the software installed on the TV. If, on the other hand, you distribute a toolkit for software developers, you’ll probably want to allow more space in your documentation for discussion about the open source software you’re using and why it’s part of the toolkit.

Summary

Be sure to remain positive in the summary of your open source policy—after all, you want your employees to want to follow the policy—while also clearly stating when and how open source software usage triggers review. For example, the summary section of a corporate open source policy might look like this:

Mark Radcliffe and Dianne Brinson are the authors of The Internet Law and Business Handbook. (The book is currently out of print and undergoing revision, but you can reserve a copy of the next edition by sending an email to mradcliffe@sonic.net.) We’ve commissioned them to supply a series of articles to cover most of what you need to know about the legal issues you’ll encounter doing business on the Net. Among the detours into Internet Law they describe, you’ll find the answers to these (and other) burning questions:

• Does copyright protection apply to the work of celestial beings?
• How about my work? Beauty and artistic merit aside, does it qualify?
• How do I obtain a copyright?
• How original does “original thought” actually have to be?
• Trademark, copyright – what’s the difference, anyway?
• How secretive is a Trade Secret, and what have I got to do to keep mine securely under wraps?

Mark and Dianne are covering a lot of ground, so here’s a quick summary. Sit up and pay attention, now. Internet users in the United States need to be aware of four major intellectual property laws:

• Copyright law
• Patent law
• Trademark law
• Trade secret law

If you’re to avoid ending up on the wrong side of the law, you’ve got to be able to define which category your work falls under, and you’ve got to know how to make the system work for you. Last month’s article covered copyright law, defining the types of work that are covered, and the standards to which those works must adhere. The authors provide some great examples to brighten up the legalese, and they outline the procedures that must be followed in order to protect your own work.

This month’s article on patent law, trademark law and trade secret law examines the basics of United States patent law as defined under the Patent Act. What’s covered? What are the standards? How do you protect your work? You’ll find answers to these questions, as well as discovering the value of novelty, usefulness and (we love this term) non-obviousness. If you think you know it all already, go ahead and skip straight to the latest Security Issues, but we remind you that you ignore Internet Law at your peril.

Consider this: think you can patent an abstract idea? How about the discovery of a scientific principle, or a natural phenomenon? Easy, you say – of course you can’t patent, say, the discovery of the electricity contained in the lightning bolt that went right through you at the gas pump the other day, shocking you into a brilliant abstract idea for how to build a better mousetrap. Well, no. But you can patent the mousetrap. What’s more, if you don’t patent the mousetrap, the Emergency Room intern who was party to your crazed babbling while you were being treated for lightning-caused injuries might; and sure enough – before you know it you’ll be washed up; toiling away in obscurity and regaling your cynical grandchildren with tales of how you almost made a fortune.

To think you could have had all that money, if only you’d read this article.

Next month we’ll cover copyright ownership. Our legal experts will explain the Copyright Act, as well as touching on ownership regulations for patents, trademarks and trade secrets. If you acquire, make use of, or develop content for the Web, you really do need to understand this stuff. Some of the examples given hit closer to home than is comfortable; as in the story about the Marketing Director who was really pretty darn sure she had the permission she needed to use those photos on her company’s site, or the curious story of the Web Developer and the Shopping Cart.

As part of our continuing effort to help you keep at least one promise to yourself in 2009, we provide you with this next installment on Internet Law. If you develop or deal in Web content, it’s much more important to the community that you inform yourself about these legal issues, than it is that you have washboard abs, or that you quit drinking all that Sangria. Avail yourself of Mark & Dianne’s legal know-how! We really don’t want to have to say we told you so…

Patent Law

Introduction

Patent law in the United States is based on a federal statute, the Patent Act. States are prohibited from granting protection similar to that provided by the Patent Act.

Types of Works Protected

Patent law protects inventions (utility patents) and ornamental designs for articles of manufacture (design patents).

Inventions protected by utility patents include any new and useful process, machine, manufacture, or composition of matter. Inventions can be electrical, mechanical, biotechnology or chemical in nature. Examples of inventions protected by utility patents are a microwave oven, genetically engineered bacteria for cleaning up oil spills, a computerized method of running cash management accounts, and a method for curing rubber.

Internet-related inventions protected by utility patents include communications protocols, data compression techniques, interfaces, networking methods, encryption techniques, interfaces, online payment systems, and information processing and retrieval technologies. In the area of e-commerce, patentable inventions and processes include electronic postage, electronic cash, and e-commerce business methods (discussed below).

Examples of manufactured articles protected by design patents are a design for the sole of running shoes, a design for sterling silver tableware, and a design for a water fountain.

Standards

There are strict requirements for granting utility patents and design patents. We’ll discuss the requirements in this section.

Design Patents

To qualify for a design patent, a design must be new, original, and ornamental. Design patents are generally not suitable for protecting elements of Internet-related software processes. Design patents are considered rather narrow intellectual property protection because they are limited to the ornamental appearance of an article. Owners of design patents rarely sue to enforce their patents against infringers.

Utility Patents

To qualify for a utility patent, an invention must be new, useful, and “nonobvious.”

To meet the novelty requirement, the invention must not have been known or used by others in this country before the applicant invented it, and it also must not have been patented or described in a printed publication in the U.S. or a foreign country more than one year before the application date. The philosophy behind the novelty requirement is that a patent is issued in exchange for the inventor’s disclosure to the public of the details of his invention. If the inventor’s work is not novel, the inventor is not adding to the public knowledge, so the inventor should not be granted a patent.

Meeting the useful requirement is easy for most inventions. An invention is useful if it can be applied to some beneficial use in society.

To meet the nonobvious requirement, the invention must be sufficiently different from existing technology and knowledge so that, at the time the invention was made, the invention as a whole would not have been obvious to a person having ordinary skill in that field. This requirement makes sure patents are only granted for real advances, not for mere technical tinkering or modifications of existing inventions by skilled technicians.

First to Invent or First to File?

Who gets the patent if two inventors, working independently of each other, achieve patentable results around the same time? In the United States, the patent goes to the first person who invented the claimed subject matter (even if the first to invent was not the first to file a patent application). Only the U.S. has a first-to-invent system. In other countries, the first person who files a patent application gets the patent, even if he or she is not the first to invent the claimed subject matter.

It is difficult to obtain a utility patent. Even if the invention or process meets the requirements of novelty, utility, and nonobviousness, a patent will not be granted if the invention was patented or described in a printed publication in the U.S. or a foreign country more than one year before the application date, or if the invention was in public use or on sale in the U.S. for more than one year before the application date. This rule is known as the “statutory bar.” If you think your technology might be patentable, you should contact a patent attorney before you display or distribute your invention. The one-year grace period following disclosure of the invention is available only in the U.S. In most other countries, the patent application must be filed prior to any public disclosure of the invention.

“Printed Publications” on the Internet

In applying the statutory bar rule, material is considered a “printed publication” if it has been sufficiently accessible to that portion of the public interested in the particular field. Presumably, material made available on the Internet could count as a “printed publication.” Contact a patent attorney before publishing information about potentially patentable material on the Web.

Abstract ideas and mental conceptions are not patentable. Discoveries of scientific principles, laws of nature, and natural phenomena are not patentable (although applications of such discoveries are). Mathematical algorithms that have not been reduced to some type of practical application have been held to be unpatentable. However, a claim to a system or method that recites a mathematical algorithm and produces “a useful, concrete and tangible result” may be patentable. State Street Bank & Trust Co. v. Signature Financial Group, 149 F3d 1368 (Fed Cir 1998), cert. denied, 525 US 1093 (1999). The software process involved in the State Street Bank case was used by a computer system to recompute the share prices of a pool of mutual funds after each day’s trading activities ended, taking into account the day’s gains and losses and expenses attributable to each mutual fund. The final share prices were the “useful, concrete and tangible result.”

Until recently, methods of transacting business were thought not to be patentable. However, in the State Street Bank case, the court made it clear that systems or methods which implement business methods are patentable if they meet the requirements of novelty, usefulness, and nonobviousness.

You’ve probably read about new patents being issued for Internet-related methods of doing business. Here are a few:

• CyberGold’s patent for a method that rewards customers who receive online ads
• Netcentives’ patent for rewarding online purchasers with airline frequent-flyer miles
• Priceline.com’s patent for reverse auctions
• Open Market’s patents related to secure online credit-card payments
• Amazon.com’s patents on “one-click” technology and affiliate programs

Some people think that business methods should not be patentable. In State Street Bank, the Court of Appeals for the Federal Circuit, which reviews all patent appeals, held that processes which are otherwise patentable subject matter are not rendered unpatentable because they involve business methods. The Supreme Court, by denying certiorari, declined to review the position taken by the Court of Appeals. Unless Congress amends the Patent Act, processes involving business methods are patentable. However, they must meet the stringent requirements for patent protection discussed earlier in this section. The Patent and Trademark Office is now subjecting business methods patents to a second-level review.

Procedure for Getting Protection

Patent protection is obtained by demonstrating in an application filed with the U.S. Patent and Trademark Office, www.uspto.gov, that the invention meets the stringent standards for grant of a patent. The patent application process is an expensive, time-consuming process (it generally takes at least two years). Although you can file a patent application yourself, the application process is complex. You should consider using an experienced patent attorney or patent agent (a non-lawyer who has passed the special patent bar exam given by the U.S. Patent and Trademark Office).

If you want to be able to claim “patent pending” status without undertaking the expense and paperwork involved in a regular patent application, consider filing a “provisional patent application” (PPA). A PPA remains in effect for one year. The PPA filing date can be used to prove that the invention described in the PPA document predates other inventions in the field.

Exclusive Rights

A patent owner has the right to exclude others from making, using, selling, offering to sell, or importing the patented invention or design in the United States during the term of the patent. Anyone who makes, uses, sells, offers to sell, or imports a patented invention or design within the United States during the term of the patent without permission from the patent owner is an infringer—even if he or she did not copy the patented invention or design or even know about it.

Example: Developer’s staff members, working on their own, developed software for manipulating images in multimedia works. Although Developer’s staff didn’t know it, Inventor has a patent on that method of image manipulation. Developer’s use of the software infringes Inventor’s patent.

Duration

Under current law (effective June 8, 1995), utility patents are granted for a period of twenty years from the date the patent application was filed but in many countries you need to pay “maintenance fees” to keep the patent in force.

Example: Amazon.com, Inc. was issued a patent on its affiliates program on February 22, 2000. The patent application was filed on June 27, 1997. The patent will expire in June 2017.

Under prior law, patent protection lasted seventeen years from the date the patent was issued. Under the current law, if a patent application is pending for longer than three years, the patent’s term can be extended to give the applicant seventeen years to enjoy the patent.

Example: Inventor filed a patent application on June 15, 1997. She was granted a patent on December 15, 2000. Her term can be extended so that her patent will not expire until December 2017.

The extension is available only if the delay is not the fault of the applicant.

For utility patents in existence prior to June 8, 1995, the patent term is the greater of seventeen years from the date of issue (the term under prior law) or twenty years from the application filing date. Design patents are granted for a period of fourteen years.

The patent application must contain a written description of the invention and how to make and use the invention in such complete terms as to enable others to make and use it. Once a patent is issued, this information—known as the disclosure—becomes available to the public, as do the patent’s “claims” (patentee’s defined legal rights). Once the patent on an invention or design has expired, anyone is free to make, use, or sell the invention or design.

The Patent and Trademark Office maintains a free online searchable database of U.S. patents issued since January 1, 1976 at www.uspto.gov. Google has compiled a free searchable database of US patents issued between 1790 and 2006 available at www.google.com/patents. Commercial services such as Micropatent (www.micropatent.com) include pre-1971 patents in their databases. Patents may also be searched at Patent and Trademark Depository Libraries located throughout the U.S. Information on the libraries is available at www.uspto.gov.

Sample Specification and Claim Language

The specifications section of Amazon.com’s affiliates program starts with this description: “The present invention provides a software system and method for enabling an Internet sales entity . . . to efficiently market and sell goods in cooperation with Web sites or other network sites of respective business partners, referred to herein as ‘associates’.” The first claim starts this way: “A method of selling items with the assistance of associates, the method comprising: providing a Web site system that includes a browsable catalog of items and provides services for allowing customers to electronically purchase the items . . .” This patent is Patent 6,029,141, “Internet-based customer referral system.”

While most countries publish patent applications, Congress has only recently changed the U.S. Patent Act to allow the Patent and Trademark Office to publish patent applications. Effective November 29, 2000, the Patent and Trademark Office will publish patent applications eighteen months after they are filed, unless the applicant certifies that foreign patent protection is not being sought in a country that requires publication of applications eighteen months after filing. The publication provision does not apply to applications for design patents.

Limitations on Exclusive Rights

There are two major limitations on the patent owner’s exclusive rights. They are discussed in this section.

Functionally Equivalent Products

A patent owner can exclude others from making, using, or selling products or using processes that do substantially the same work as the patented invention in substantially the same manner. However, a patent does not protect the patent owner from competition from functionally equivalent products or processes that work in different ways.

Example: Microco owns a patent covering a laser printer. While Microco can prevent others from making, using, or selling laser printers that work in substantially the same manner as Microco’s printer, it cannot prevent others from making, using, or selling laser printers that operate in a different manner.

Invalidation

The validity of an issued patent is subject to challenge in an infringement proceeding or a re-examination proceeding. Defendants in infringement suits usually raise the defense of patent invalidity, asserting that the invention covered by the patent was not novel or nonobvious. It is not unusual for a patent infringement suit to result in a determination that the U.S. Patent and Trademark Office made a mistake in granting the patent.

Patent Validity

Patent invalidity is certain to be an issue in infringement suits to enforce e-commerce business methods patents. For example, when Amazon.com sued Barnesandnoble.com for infringing Amazon’s “One-Click Shopping” patent, Barnesandnoble.com’s defenses included patent invalidity. Barnesandnoble.com maintained that One-Click Shopping was not novel or nonobvious—and that the patent examiner who granted the patent to Amazon.com would have realized that had the examiner had all the relevant “prior art” available to him when he reviewed Amazon’s patent application.

Avoiding Infringement

New Internet-related and e-commerce patents are being granted in record numbers. If you learn of a patent and are concerned that your operations may infringe it, get advice from a patent attorney.

Consulting a patent attorney is particularly important if your potentially infringing operations are still in the planning stages. Based on the legal advice you receive, you may decide to modify your operations to avoid infringement—or you may decide to get a license from the patent owner. Avoid investing more money or time in your plans until you get legal advice.

If you learn that a patent has recently been granted on a method of doing business you are already using, you may have an “early inventor” defense (also known as a “first inventor” defense). The early inventor defense was added to the Patent Act in late 1999, after the State Street Bank case (discussed earlier in this section) was decided. Prior to that decision, business methods were thought not to be patentable. Now thousands of business methods patent applications are being filed. The early inventor defense, applicable only to business methods patents, is a complete defense to infringement for those who meet two requirements:

• Commercially used the subject matter covered in the patent prior to the patentee’s patent application date.
• Acting in good faith, “reduced the subject matter to practice” (executed the invention) at least one year before the patentee’s application filing date.

“Submarine patents” have long been a concern in fast-moving fields. A submarine patent is one that remains secret until it is issued, by which time competitors and other companies have made substantial investments to use the technology covered by the new patent. There is nothing you can do to eliminate the risk of submarine patents. However, the fact that many patent applications will now be published eighteen months after they are filed helps to reduce the risk.

If you are concerned that someone else is going to apply for a patent on a business method they and you are already using on the Internet, take comfort in the statutory bar mentioned earlier in this section. No patent can be granted on an invention that was in public use or on sale in the U.S. for more than one year prior to the patent application date.

Trademark Law

Introduction

Trademarks and service marks are words, names, symbols, or devices used by manufacturers of goods and providers of services to identify their goods and services, and to distinguish their goods and services from goods manufactured and sold by others.

Example: The trademark FrontPage is used by Microsoft Corporation to identify the company’s Web development software and to distinguish its software from other vendors’ Web development software.

For ease of expression, we will use “trademark” in this article to refer to both trademarks (used on goods) and service marks (used for services).

For trademarks used in commerce, federal trademark protection is available under the federal trademark statute, the Lanham Act. Many states have trademark registration statutes that resemble the Lanham Act, and all states protect unregistered trademarks under the common law (nonstatutory law) of trademarks.

Types of Works Protected

Examples of words used as trademarks are Kodak for cameras and Burger King for restaurant services. Examples of slogans used as trademarks are Fly the Friendly Skies of United for airline services and Get a Piece of the Rock for insurance services. Examples of characters used as trademarks are Pillsbury’s Dough Boy for baked goods and Aunt Jemima for breakfast foods.

Sounds can be used as trademarks, such as the jingle used by National Public Radio. Product shapes and configurations—for example, the distinctively shaped bottle used for Coca-Cola—can also serve as trademarks.

Standards

Trademark protection is available for words, names, symbols, or devices that are capable of distinguishing the owner’s goods or services from the goods or services of others. A trademark that merely describes a class of goods rather than distinguishing the trademark owner’s goods from goods provided by others is not protectible.

Example: The word “corn flakes” is not protectible as a trademark for cereal because that term describes a type of cereal that is sold by a number of cereal manufacturers rather than distinguishing one cereal manufacturer’s goods.

A trademark that resembles a trademark already in use in the U.S. so closely that it is likely to cause confusion or mistake is not protectible. Geographically descriptive marks—”Idaho” for potatoes grown in Idaho—are not protectible trademarks for products that originate in the geographical area (all Idaho potato growers should be able to use “Idaho” in connection with selling their potatoes). Geographically misdescriptive marks that are deceptive are not protectible.

Example: Hiromichi Wada, the owner of a Michigan leather goods shop, attempted to federally register the name New York Ways Gallery for leather goods. The Patent and Trademark Office refused to register the name because it thought the public would assume Wada’s goods were from New York. The Court of Appeals for the Federal Circuit upheld the Patent and Trademark Office’s decision. In re Hiromichi Wada, 194 F3d 1297 (Fed Cir 1999).

Procedure for Getting Protection

The most effective trademark protection is obtained by filing a trademark registration application in the Patent and Trademark Office, www.uspto.gov. Federal law also protects unregistered trademarks, but such protection is limited to the geographic area in which the mark is actually being used.

Federal Protection

Federal registration is limited to trademarks used in interstate commerce (or intended for use in interstate commerce). Before November 1989, a trademark application could be filed only after the trademark’s owner had actually used the trademark in commerce. Under current law, a person who has a “bona fide” intention to use a trademark in commerce may apply to register the trademark.

For federally registered marks, the use of notice of federal registration is optional. A federal registrant may give notice that his or her trademark is registered by displaying with the trademark the words “Registered in U.S. Patent and Trademark Office” or the symbol ®.

State Protection

State trademark protection under common law is obtained simply by adopting a trademark and using it in connection with goods or services. This protection is limited to the geographic area in which the trademark is actually being used.

State statutory protection is obtained by filing an application with the state trademark office. Those relying on state trademark law for protection cannot use the federal trademark registration symbol, but they can use the symbol ™ (or, for a service mark, ℠).

Domain Names as Trademarks

The mere registration of a domain name does not convey trademark rights. However, if you use your domain name to identify your goods or services—using it in ads for your e-commerce site, for example—it acquires trademark protection.

Exclusive Rights

Trademark law in general, whether federal or state, protects a trademark owner’s commercial identity (goodwill, reputation, and investment in advertising) by giving the trademark owner the exclusive right to use the trademark on the type of goods or services for which the owner is using the trademark. Any person who uses a trademark in connection with goods or services in a way that is likely to cause confusion is an infringer. Trademark owners can obtain injunctions against the confusing use of their trademarks by others, and they can collect damages for infringement.

Example: Distributed Learning Company is selling a line of interactive training products under the trademark Personal Tutor. If Giant Multimedia Company starts selling interactive training products under the name Personal Tutor, purchasers may think that Giant’s products come from the same source as Distributed Learning’s products. Giant is infringing Distributed Learning’s trademark.

One of the most important benefits of federal registration of a trademark is the nationwide nature of the rights obtained. For the registrant, federal registration in effect reserves the right to start using the mark in new areas of the U.S.

Example: In March 1999, Small Multimedia Company, a California corporation, obtained a federal trademark registration on the trademark Abra for computer games. Small Multimedia did not begin using the trademark on computer games in New York until 2000. In September 1999, Giant Company started using Abra on computer games in New York. Because Small Multimedia’s federal registration gives it a right to use Abra throughout the United States that is superior to Giant’s right to use Abra, Small Multimedia can stop Giant from using Abra on computer games in New York—even though Giant started using Abra in New York before Small Multimedia did.

A trademark owner’s rights under state trademark law (and the rights of an unregistered trademark owner under federal law) are generally limited to the geographical area in which the owner has used the trademark.

Example: (For this example, we changed just one fact from the previous example.) Small Multimedia Company did not get a federal trademark registration. Now Giant’s right to use Abra on computer games in New York is superior to Small Multimedia’s right to use Abra on computer games in New York, because Giant was the first to actually use the trademark on computer games in New York.

Internet Use

In the last example, what if Small Multimedia Company, the first company to use Abra on computer games, sold its games on a Web site? People anywhere in the world could view the Web site. Does that mean that Small Multimedia was using Abra throughout the world? We don’t know the answer. It is unclear how the above rule would apply when a trademark is protected only under state or common law and is used on the Internet.

Duration

A certificate of federal trademark registration remains in effect for ten years, provided that an affidavit of continued use is filed in the sixth year. A federal registration may be renewed for any number of successive ten-year terms so long as the mark is still in use in commerce. The duration of state registrations varies from state to state. Common law rights endure so long as use of the trademark continues.

Limitations of Exclusive Rights

Trademark law does not give protection against use of the trademark that is unlikely to cause confusion, mistake, or deception among consumers, but dilution laws may provide such broader protection.

Example: Western Software has a federal registration for the use of Flap on Web development tool software. If Giant Company starts using Flap on its desktop publishing software, Giant may be infringing Western Software’s trademarks because consumers may think the desktop publishing software and the Web development tool software come from the same source. If Giant starts using Flap on fire extinguishers, though, Giant is probably not infringing Western Software’s trademark. Consumers are unlikely to think that the Flap software and the Flap fire extinguishers come from the same source.

Avoiding Infringement

For tips on how to avoid trademark infringement in naming your products and services, tips on how to avoid trademark infringement when choosing domain names, and rules for using trademarks owned by others, see The Internet Law and Business Handbook. (This book is currently out of print and undergoing revision, but you can reserve a copy of the next edition by sending an email to mradcliffe@sonic.net.)

Trade Secret Law

Introduction

A trade secret is information of any type that is valuable to its owner, not generally known, and kept secret by the owner. Even negative information such as research options that have been explored and found to be worthless can be trade secrets.

Trade secrets are protected only under state law. The Uniform Trade Secrets Act, in effect in a number of states, defines trade secrets as “information, including a formula, pattern, compilation, program, device, method, technique, or process that derives independent economic value from not being generally known and not being readily ascertainable and is subject to reasonable efforts to maintain secrecy.”

Types of Works Protected

The following types of technical and business information are examples of material that can be protected by trade secret law:

• Customer lists
• Designs
• Instructional methods
• Manufacturing processes
• Document-tracking processes
• Formulas for producing products

Inventions and processes that are not patentable can be protected under trade secret law. Patent applicants generally rely on trade secret law to protect their inventions while the patent applications are pending.

Standards

Six factors are generally used to determine whether material is a trade secret:

• The extent to which the information is known outside the claimant’s business.
• The extent to which the information is known by the claimant’s employees.
• The extent of measures taken by the claimant to guard the secrecy of the information.
• The value of the information to the claimant and the claimant’s competitors.
• The amount of effort or money expended by the claimant in developing the information.
• The ease with which the information could be acquired by others.

Information has value if it gives rise to actual or potential commercial advantage for the owner of the information. Although a trade secret need not be unique in the patent law sense, information that is generally known is not protected under trade secret law.

Procedure for Getting Protection

Trade secret protection attaches automatically when information of value to the owner is kept secret by the owner.

Exclusive Rights

A trade secret owner has the right to keep others from misappropriating and using the trade secret. Sometimes the misappropriation is a result of industrial espionage. Many trade secret case defendants are people who have taken their former employers’ trade secrets for use in new businesses, or new employers of such people.

Trade secret protection endures so long as the requirements for protection—generally, value to the owner and secrecy—continue to be met. The protection is lost if the owner fails to take reasonable steps to keep the information secret.

Example: After Sam discovered a new method for manipulating images in multimedia works, he demonstrated his new method to a number of other developers at a multimedia conference without requiring the developers to sign nondisclosure agreements. Sam lost his trade secret protection for the image manipulation method because he failed to keep his method secret.

Limitations on Exclusive Rights

Trade secret owners have recourse only against misappropriation. Discovery of protected information through independent research or reverse engineering (taking a product apart to see how it works) is not misappropriation. However, many software license agreements prohibit reverse engineering.

Federal Criminal Trade Secret Law

The Economic Espionage Act of 1996 (EEA) makes stealing or knowingly buying trade secrets a criminal offense punishable by a fine of up to $250,000, imprisonment of up to fifteen years, or both. The EEA provides higher penalties for stealing or knowingly buying trade secrets for the benefit of a foreign government or agent.

Avoiding Infringement

To avoid infringing trade secrets, you should avoid using valuable confidential business and technical information you acquired while working for a former employer. When you hire someone to perform exactly the same duties he or she used to perform for another company, you run the risk of being sued for trade secret infringement. An individual is allowed to carry general knowledge or skill from one job to the next. Drawing the line between general knowledge or skill and protected trade secrets belonging to the former employer can be difficult. Consider consulting an experienced attorney if you need to make this distinction.

Customer Contacts List

Haber worked in sales at North Atlantic Instruments. He left North Atlantic and joined Apex Signal Corporation, where he immediately began calling the customer contacts he had developed and used while working at North Atlantic. North Atlantic sued for trade secret misappropriations and won. The customer contact list was held to be a trade secret belonging to North Atlantic because North Atlantic had taken appropriate steps to keep the information secret. North Atlantic Instruments v. Haber, 188 F3d 38 (2d Cir 1999).

International Protection

To obtain patent, trademark and trade secret protection in another country, you must comply with that country’s requirements for obtaining protection. For these intellectual property rights, there are no international conventions that provide automatic protection for U.S. rights owners. However, the World Intellectual Property Organization has proposed a Patent Law Treaty which will, if adopted, simplify the filing of multi-country patent applications.

Some inventors file patent applications in other countries simultaneously with the U.S. filing. The Paris Convention and the Patent Cooperation Treaty allow an inventor who files a patent application in the U.S. to delay filing in member countries based on the earlier U.S. application date. The European Patent Convention offers a way to file a single patent application for a patent which will be valid in 17 European countries. The European Community Trademark system provides a centralized procedure for obtaining trademark rights in European Community countries. The Madrid Protocol permits United States trademark owners to obtain trademark rights in a number of countries by filing a single application.

Mark Radcliffe and Dianne Brinson are the authors of The Internet Law and Business Handbook. (The book is currently out of print and undergoing revision, but you can reserve a copy of the next edition by sending an email to mradcliffe@sonic.net.) We’ve commissioned them to supply three articles, covering most of what you need to know about the legal issues you’ll encounter doing business on the Net. Among the detours into Internet Law they describe, you’ll find the answers to these (and other) burning questions:

• Does copyright protection apply to the work of celestial beings?
• How about my work? Beauty and artistic merit aside, does it qualify?
• How do I obtain a copyright?
• How original does “original thought” actually have to be?
• Trademark, copyright – what’s the difference, anyway?
• How secretive is a Trade Secret, and what have I got to do to keep mine securely under wraps?

Mark and Dianne are going to cover a lot of ground with this series, so we’ll provide you with a quick summary. Sit up and pay attention, now. Internet users in the United States need to be aware of four major intellectual property laws:

• Copyright law
• Patent law
• Trademark law
• Trade secret law

If you’re to avoid ending up on the wrong side of the law, you’ve got to be able to define which category your work falls under, and you’ve got to know how to make the system work for you. This month’s article on copyright law defines the types of work that are covered, and the standards to which those works must adhere. The authors have come up with some great examples to brighten up the legalese, and they outline the procedures that must be followed in order to protect your own work.

In next month’s article on patent, trademark and trade secret law we’ll examine the basics of United States patent law as defined under the Patent Act. In March, you can read the final article in the series, which concerns ownership of copyrights. Our legal experts will explain the Copyright Act, as well as touching on ownership regulations for patents, trademarks and trade secrets.

If you acquire, make use of, or develop content for the Web, you really do need to understand this stuff. Some of the examples given hit closer to home than is comfortable; as in the story about the Marketing Director who was really pretty darn sure she had the permission she needed to use those photos on her company’s site, or the curious story of the Web Developer and the Shopping Cart.

You can do all the push-ups and avoid all the french fries you want to this year, but if you develop or deal in Web content, it’s much more important to the community that you inform yourself about these legal issues, than it is that you have washboard abs. Avail yourself of Mark & Dianne’s legal know-how! We really don’t want to have to say we told you so…

Copyright Law

INTRODUCTION

Copyright law in the United States is based on the Copyright Act of 1976, a federal statute that went into effect on January 1, 1978.  We’ll refer to this statute throughout the book as the Copyright Act.  The Copyright Act (Title 17 of the United States Code) is available online in Adobe Acrobat PDF format at http://www.loc.gov/copyright/title17. The United States Copyright Office, part of the Library of Congress, handles copyright registrations (discussed later in this section) and provides information on copyright law on its Web site, www.loc.gov.

States cannot enact their own laws to protect the same rights as the rights provided by the Copyright Act. 17 USC § 301. For example, a state cannot pass a law to extend copyright protection on works in the state beyond the term of protection given by the Copyright Act.  State “copyright” laws exist, but they are limited to works that cannot be protected under federal copyright law.   (Requirements for federal protection are discussed in the “Standards” section below.)

Copyright law is important for Internet users for three reasons:

• Much of the material that is on the Internet is protected by copyright, making copyright law a concern for those wishing to use material they find on the Internet.
• The types of pre-existing material used for Web site content — text, graphics, photographs, and  music — are copyrightable, and much of this material is protected by copyright.   Web site owners and developers and Web product designers and publishers must avoid infringing copyrights owned by others.
• Copyright protection is available for Web sites and new Web content.

TYPES OF WORKS PROTECTED BY COPYRIGHT

Copyright law protects “works of authorship.” 17 USC § 102(a). The Copyright Act states that works of authorship include the following types of works:

• Literary works.  Novels, fictional characters, nonfiction prose, poetry, newspaper articles and newspapers, magazine articles and magazines, computer software, software documentation and manuals, training manuals, manuals, catalogs, brochures, ads (text), and compilations such as business directories.
• Musical works.  Songs, advertising jingles, and instrumentals.
• Dramatic works.  Plays, operas, and skits.
• Pantomimes and choreographic works.  Ballets, modern dance, jazz dance, and mime works.
• Pictorial, graphic, and sculptural works.  Photographs, posters, maps, paintings, drawings, graphic art, display ads, cartoon strips and cartoon characters, stuffed animals, statues, paintings, and works of fine art.
• Motion pictures and other audiovisual works.  Movies, documentaries, travelogues, training films and videos, television shows, television ads, and interactive multimedia works.
• Sound recordings.  Recordings of music, sounds, or words.
• Architectural works.  Building designs, whether in the form of architectural plans, drawings, or the constructed building itself.

STANDARDS

To receive copyright protection, a work must be “original” and must be “fixed” in a tangible medium of expression. 17 USC § 102(a). Certain types of works are not copyrightable.

Originality

The originality requirement is not stringent:  A work is original in the copyright sense if it owes its origin to the author and was not copied from some preexisting work.  A work can be original without being novel or unique.

Example: John’s book, Designing Web Sites, is original in the copyright sense so long as John did not create his book by copying existing material-even if it’s the millionth book to be written on the subject.

Only minimal creativity is required to meet the originality requirement.  No artistic merit or beauty is required.

Prior Widespread Use

While most works make the grade on the originality requirement — because they possess some creative spark, no matter how obvious — a phrase or slogan that has been in widespread use may lack the originality necessary for copyrightability.  A federal appeals court held that a music publishing company could not claim copyright in the phrase, “You’ve got to stand for something, or you’ll fall for anything,” because the phrase lacked originality.  Acuff-Rose Music Inc. v. Jostens Inc., 155  F3d 140 (2d Cir 1998).  Short phrases rarely meet the originality requirement and are usually not copyrightable.  However, they may qualify for trademark protection.

A work can incorporate preexisting material and still be original.  When preexisting material is incorporated into a new work, the copyright on the new work covers only the original material contributed by the author.

Example: Web Developer used preexisting photographs and graphics (with the permission of the copyright owners) in a Web design project.  The Web site as a whole owes its origin to Developer, but the photographs and graphics do not.  Web Developer’s copyright on the Web site does not cover the photographs, just the material created by Developer.

Facts owe their origin to no one and so are not original.  In the United States, a compilation of facts (a work formed by collecting and assembling data) is protected by copyright only to the extent of the author’s originality in the selection, coordination, and arrangement of the facts.

Example: Ralph created a neighborhood phone directory for his neighborhood by going door-to-door and acquiring his neighbors’ names and phone numbers.  The directory’s facts (names and phone numbers) are not original.  Ralph’s selection of facts was not original (he “selected” every household in the neighborhood).  His coordination and arrangement of facts (alphabetical order by last name) is routine rather than original.  The directory is not protected by copyright.

Selection and Arrangement

In the case Urantia Foundation v. Maaherra, the court had to decide whether a book believed by both parties to be the words of celestial beings was copyrightable.  The foundation claimed copyright ownership.  The defendant, who had distributed a computer disk version of the book without the permission of the foundation, maintained that the book was not copyrightable because no human creativity was involved in creating the book.  The court held that even if the book’s content originated with a celestial being, there had been sufficient human selection and arrangement of material to satisfy copyright law’s “originality” requirement. 114  F3d 955  (9th Cir 1997).

Fixation

According to Section 101 of the Copyright Act, a work is “fixed” when it is made “sufficiently permanent or stable to permit it to be perceived, reproduced, or otherwise communicated for a period of more than transitory duration.”  It makes no difference what the form, manner, or medium is.  An author can “fix” words, for example, by writing them down, typing them on an old-fashioned typewriter, dictating them into a tape recorder, or entering them into a computer.  A live television broadcast is “fixed” if it is recorded simultaneously with the transmission.

Uncopyrightable Works

Works prepared by federal government officers and employees as part of their official duties are not protected by copyright. 17 USC § 105. Consequently, federal statutes (the Copyright Act, for example) and regulations are not protected by copyright.  This rule does not apply to works created by state government officers and employees.

Titles of works are not copyrightable.  However, titles may be protectible under trademark law.

The design of a useful article is protected by copyright only if, and to the extent that, the design “incorporates pictorial, graphic, or sculptural features that can be identified separately from, and are capable of existing independently of, the utilitarian aspects of the article.” 17 USC § 101 (definition of “pictorial, graphic, and sculptural works”).  For example, while a standard belt buckle design is not protected, a three-dimensional belt-buckle design with a dolphin shape qualifies for limited protection.

Uncopyrightable works and works for which copyright protection has ended are referred to as “public domain” works.

PROCEDURE FOR GETTING PROTECTION

Copyright protection arises automatically when an original work of authorship is fixed in a tangible medium of expression. 17 USC § 102.  Registration with the Copyright Office is optional (but you have to register before you file an infringement suit, if you are a United States citizen or corporation).

The use of copyright notice is optional for works distributed after March 1, 1989.  Copyright notice can take any of these three forms:

• © followed by a date and name.
• “Copyright”  followed by a date and name.
• “Copr.” followed by a date and name.

THE EXCLUSIVE RIGHTS

According to section 106 of the Copyright Act, a copyright owner has five exclusive rights in the copyrighted work:

• Reproduction Right. The reproduction right is the right to copy, duplicate, transcribe, or imitate the work in fixed form.   Scanning a copyrighted work for use on a Web site is an exercise of the copyright owner’s reproduction right.
• Modification Right. The modification right (also known as the derivative works right) is the right to modify the work to create a new work.  A new work that is based on a preexisting work is known as a “derivative work.”  Altering a photograph is an exercise of the modification right, as is creating an interactive version of a novel or creating a sequel to a computer game or motion picture.
• Distribution Right. The distribution right is the right to distribute copies of the work to the public by sale, rental, lease, or lending.
• Public Performance Right. The public performance right is the right to recite, play, dance, act, or show the work at a public place or to transmit it to the public. In the case of a motion picture or other audiovisual work, showing the work’s images in sequence is considered “performance.”  Showing scenes from a copyrighted motion picture in sequence on the Web is an exercise of the public performance right, as is the use of a copyrighted musical composition on the Web.
• Public Display Right. The public display right is the right to show a copy of the work directly or by means of a film, slide, or television image at a public place or to transmit it to the public.  In the case of a motion picture or other audiovisual work, showing the work’s images out of sequence is considered “display.”  Posting copyrighted material on the Web is an exercise of the public display right.

INFRINGEMENT

Anyone who violates any of the exclusive rights of a copyright owner is an infringer.

Example: John scanned Photographer’s copyrighted photograph, altered the image by using digital editing software, and used the altered version of the photograph on  an e-commerce site.  If John used the photograph without Photographer’s permission, John infringed Photographer’s copyright by violating the reproduction right, the modification right, and the public display right.

A copyright owner can recover actual or, in some cases, statutory damages from an infringer.  The federal district courts have the power to issue injunctions (orders) to prevent or restrain copyright infringement and to order the impoundment and destruction of infringing copies.

There are two essential elements to an infringement case:  (a) that the defendant copied from the plaintiff’s copyrighted work; and (b) that the copyright was improper appropriation.  Copying generally is established by showing that the defendant had access to the plaintiff’s work and that the defendant’s work is substantially similar to the plaintiff’s work.

Most copyright infringement cases are civil cases.  However, copyright infringement also can be a criminal offense.   According to Section 506 of the Copyright Act, two types of willful copyright infringement are criminal offenses:

• Willful infringement for purposes of commercial advantage or private financial gain.
• Willful infringement by reproducing or distributing copies or phonorecords of copyrighted works having a total retail value of more than $1000 in a 180-day period.

Barter Boards

David LaMacchia, an MIT student, invited users to post commercial software on his bulletin board for exchange with other users.  LaMacchia made no money from the exchanges.  He was arrested, but the court dismissed the suit because the criminal copyright law in effect at the time of the prosecution applied only to willful infringement for commercial motive or private gain.   Congress then amended the law, adding the second violation category discussed in the paragraph immediately above.  Prosecutors can use the provision to shut down barter boards through which pirated copies of software and computer games are traded.

DURATION OF THE RIGHTS

The duration of copyright law is very complicated because it depends on when the work was created, when the work was “published” (distribution of copies to the general public), the author of the work and, in some cases, the type of work. However, works created under the Copyright Act of 1976, the copyright term for works created by individuals is the life of the author plus seventy years. 17 USC § 302(a).

The copyright term for “works made for hire” is ninety-five years from the date of first “publication” or 120 years from the date of creation, whichever expires first. 17 USC § 302(c).  Works made for hire are works created by employees for employers and certain types of specially commissioned works.

LIMITATIONS ON THE EXCLUSIVE RIGHTS

The copyright owner’s exclusive rights are subject to a number of exceptions and limitations that give others the right to make limited use of a copyrighted work.  Major exceptions and limitations are outlined in this section.

Ideas

Copyright protects only against the unauthorized taking of a protected work’s “expression.”  It does not extend to the work’s ideas, procedures, processes, systems, methods of operation, concepts, principles, or discoveries.

Facts

A work’s facts are not protected by copyright, even if the author spent large amounts of time, effort, and money discovering those facts. In the United States, copyright protects originality, not effort or “sweat of the brow.”

Extracting Facts from a Web Site

In Ticketmaster Corp. v. Tickets.com, Inc., the court held that extracting facts from a Web site is not copyright infringement.  “This falls in the same category of taking historical facts from a work of reference and printing them in a different expression,” the court stated.   54 USPQ2d 1344  (CD Cal 2000).  The court also held that using facts from a Web site is neither an unfair business practice nor unjust enrichment.

Independent Creation

A copyright owner has no recourse against another person who, working independently, creates an exact duplicate of the copyrighted work.  The independent creation of a similar work or even an exact duplicate does not violate any of the copyright owner’s exclusive rights.

Fair Use

The “fair use” of a copyrighted work, including use for purposes such as criticism, comment, news reporting, teaching, scholarship, or research, is not an infringement of copyright.  Copyright owners are, by law, deemed to consent to fair use of their works by others.

The Copyright Act does not define fair use.  Instead, whether a use is fair use is determined by balancing these factors:

• The purpose and character of the use.
• The nature of the copyrighted work.
• The amount and substantiality of the portion used in relation to the copyrighted work as a whole.
• The effect of the use on the potential market for, or value of, the copyrighted work.

INTERNATIONAL PROTECTION

U.S. authors automatically receive copyright protection in all countries that are parties to the Berne Convention for the Protection of Literary and Artistic Works, or parties to the Universal Copyright Convention (UCC).  Most countries belong to at least one of these conventions.  Members of the two international copyright conventions have agreed to give nationals of member countries the same level of copyright protection they give their own nationals.

Example: Publisher has discovered that bootleg copies of one of its software are being sold in England.  Because the United Kingdom is a member of the Berne Convention and the UCC, Publisher’s work is automatically protected by copyright in England.  When Publisher files a copyright infringement action in England against the bootlegger, Publisher will be given the same rights that an English copyright owner would be given.

The copyright laws (and other intellectual property laws) of a number of countries are posted at www.wipo.int/clea.

Works of foreign authors who are nationals of Berne or UCC-member countries automatically receive copyright protection in the U.S., as do works first published in a Berne Convention or UCC country.  Unpublished works are subject to copyright protection in the U.S. without regard to the nationality or domicile of the author.

But are OpenOffice and other open source alternatives to Office really ready for prime time? In this article we’ll gauge how OpenOffice 3.0 stacks up to Microsoft Office 2007 by comparing the key attributes and features of both product suites. We’ll also take a look at Evolution and GnuCash — open source alternatives to Microsoft Outlook and Microsoft Accounting Express (respectively) — and determine whether or not they’re worthy of consideration for use in your office.

OpenOffice Advantages

Sure, Microsoft Office has widespread adoption and an impressive range of features, but OpenOffice offers its own unique advantages — particularly in the areas of cost, localization, cross-platform support, and the availability of third-party extensions and support.

Cost and Localization

OpenOffice has as clear advantage on price — it’s available for free download. Depending upon the specific functionality you require, the cost savings can be significant. Microsoft pricing for a single seat (non-volume) license ranges from $149.95 for Office Home and Student to $679.95 USD for Office Ultimate. Additional charges apply for those needing one or more of the 36 language packs available from Microsoft. In contrast, OpenOffice supports over 80 locales for free, and each comes with its own localized website and documentation.

When researching Office pricing, be sure to read the fine print to determine the actual costs for the functionality you need. For example, Microsoft Exchange Server is required for dynamic calendars and advanced collaboration functionality. Similarly, Microsoft Office SharePoint Server is required for certain advanced functionality and for the PowerPoint Slide Library. To share data among multiple computers, the host computer must be running at least Windows XP Professional.

Supported Platforms

For heterogeneous environments, OpenOffice offers a clear advantage with its cross-platform support. Versions are available for:

• Windows ME and higher
• 32 bit, 64 bit, Sparc, and PPC versions for Linux in rpm and deb formats
• x86 and Sparc for Solaris
• Intel and PPC for Mac OSX
• packages and ports for FreeBSD and OpenBSD, PBIs for PC-BSD, pkgsrc for NetBSD and DragonFly BSD
• Irix and OpenVMS

In contrast, Office is available in 32 and 64 bit (which has some limitations) versions for Microsoft Windows XP or higher, and a separate version is available for Mac OSX.

Extensions and Support

Typical of a mature open source project, OpenOffice boasts a community of users who write freely-downloadable extensions that expand the functionality of the base product. Currently, over 100 extensions are available to OpenOffice users who want additional templates, labels, dictionaries, converters, and tools. The OpenOffice extensions site is well worth a browse to get a feel for the features that are available. An RSS feed is available for those who wish to be informed when new extensions are added.

The support section of the OpenOffice website provides free documentation, guides, and tutorials along with the expected forums and mailing lists. Commercial support is available through Sun and from an online directory of consultants. Several books are also available for sale.

Feature Comparison

OpenOffice clearly offers several impressive advantages, but the real question is whether or not it delivers all the features you’re currently using in Microsoft Office. In this section we’ll compare each Office 2007 product to its OpenOffice or other open source equivalent. We’ll start with Word, PowerPoint, Excel, and Access and the OpenOffice 3.0 alternatives to each, then move onto a comparison of Microsoft Outlook and Evolution. We’ll finish with look at how GnuCash compares to Microsoft Accounting Express.

Microsoft Word vs OpenOffice Writer and Draw

OpenOffice Writer provides nearly the same functionality as Microsoft Word, so users who migrate to Writer should be able to perform their usual tasks with minimal disruption. The most notable difference to end-users will be the layout of the toolbars, which may take some getting used to. While not nearly as slick-looking, the tools are all there — but often in a different location than they are in Word.

OpenOffice Writer Toolbar Layout

Diagrams can be created directly within Writer using the Drawing toolbar or in the standalone OpenOffice Draw application.

Writer does provide some nice features not available in Word. Most notable is its ability to export documents to PDF format, which can save the cost of purchasing Adobe Acrobat or using online converters for this purpose. An OpenOffice extension (currently in beta) is available to modify and annotate PDF files.

Writer also provides support for reading and saving documents in multiple formats, including odt, sxw, doc, rtf, sdw, txt, html, pdb, xml, psw, and uot. Note that the core product currently does not support changes to the new docx format introduced in Office 2007, but OpenOffice users can download a converter-integrator or convert docx documents online. However, this is a minor disadvantage considering the docx format is not backwards compatible with older versions of Microsoft Office, which require a Microsoft Compatibility Pack to read and write the docx format.

Microsoft PowerPoint vs OpenOffice Impress

Impress is OpenOffice’s PowerPoint equivalent for creating presentations. This utility provides a presentation creation wizard, animations, effects, slide show settings, and the ability to include charts, tables, and images. It can read existing PowerPoint presentations and export presentations to PDF format. Users accustomed to PowerPoint will wonder at the lack of built-in templates, although additional templates are available for free download.

Create New Presentation Wizard

Microsoft Excel vs OpenOffice Calc

Excel users should find OpenOffice Calc to be a drop-in replacement. Calc can read and write to Excel, Pocket Excel, and dBase formats as well as save to csv, html, and xml formats. Older versions of Calc sometimes had glitches in formatting when switching between Excel and the native Calc format, but these issues seem to have been ironed out in version 3.0.

Microsoft Access vs OpenOffice Base

While Access is only available in the Professional and Ultimate editions of Microsoft Office, the equivalent database product Base comes standard with OpenOffice 3.0. Base includes a wizard to help users create a new database and tables or connect to an existing database.

New Database Wizard in Base

Native drivers support Access, MySQL, Adabas D, and PostgreSQL databases. JDBC and ODBC connectors allow for connections to virtually any database, though this can be easier said then done for the non-power user. Fortunately, there is plenty of documentation available, making Base a good open source alternative for businesses that need to integrate database functionality.

Microsoft Outlook vs Evolution

While Outlook is included with every version of Office except for the Home and Student editions, OpenOffice does not include an email/contact manager application. For those interested in an open source alternative to Outlook, Evolution is an excellent candidate. Evolution is often touted as the “Outlook killer” for Linux, and now there is even a version of Evolution for Windows. Evolution does not require OpenOffice but may integrate with it.

Evolution supports Bayesian-based junk filtering, intelligent searches, integration with instant messaging, shared calendars and contacts, and integration with Microsoft Exchange and Novell Groupwise. Several dozen EPlugins, as well as the documentation for creating EPlugins, are available to further extend the base feature set. Evolution can import mail, contacts, and calendars from several different types of sources and provides a mechanism to easily backup and restore settings, mail, contacts, tasks, memos, and calendars. Existing Outlook users will find the interface similar, though not quite as slick.

Evolution Read Mail Interface

It should be noted that some Linux distributions, such as Novell SUSE, integrate Evolution with OpenOffice, allowing users to seamlessly send documents as e-mail and perform mail merges using their address book.

Microsoft Accounting Express vs GnuCash

Accounting Express is available only in the US with the Small Business, Professional, and Ultimate editions of Microsoft Office. For those who are unable to obtain Accounting Express or simply want an alternative, GnuCash is a reasonable open source equivalent for tracking financial transactions, creating reports and graphs, handling invoices and bill payments, and reconciling statements. It also imports Intuit Quicken files and automatically eliminates duplicate transactions. Like Evolution, GnuCash does not require OpenOffice but may integrate with it.

GnuCash is available for Windows, Linux, FreeBSD, Solaris and Mac OSX and has been localized into 21 languages. While the online documentation leaves much to be desired, the built-in GnuCash Tutorial and Concepts Guide provides an excellent introduction to both the product and general bookkeeping concepts. Wizards (druids) are available to assist with common tasks. And if you’re interested in using GnuCash in conjunction with OpenOffice, an OpenOffice extension for Calc allows you to read and import GnuCash output data.

GnuCash Account Setup Wizard

Conclusions

For individuals and businesses requiring basic functionality from an office suite, OpenOffice is a clear winner. Further, it may be the only reasonable choice for organizations requiring cross-platform support or localization in a language not available from the Microsoft Office Suite. Organizations that need advanced functionality or rely heavily on the shared functions that require back-end Microsoft servers will have to conduct their own trials to ensure that the needed features are supported in OpenOffice. We recommend that potential users download OpenOffice for their platform and use it to perform their daily office tasks for a month or so. This trial period will indicate the extent of any learning curve for new users as well as highlight any glitches in formatting or collaboration with other users.

1. First Major Appellate Decision For a FOSS License. Last year, the District Court in San Francisco in Jacobsen v. Katzner decided the first case under US law interpreting an open source license. That decision had the potential to significantly undercut the ability of FOSS licensors to enforce their license. However in August, the Court of Appeals for the Federal Circuit (”CAFC”) overturned the District Court decision and strongly supported the right of FOSS licensors to obtain copyright remedies for breach of FOSS licenses: such remedies include injunctive relief (an order by the court to the licensee to obey the license) and statutory damages of up to $150,000 for each infringed work. (Read more about the victory for open source in the Jacobsen Decision.)

2. Final End Of the SCO Attack On Linux. Although SCO’s lawsuits against IBM and others were largely resolved by the decision last year against SCO in its litigation with Novell over ownership of the copyrights to UNIX, several important issues remained. This year the court confirmed its ruling against SCO and awarded Novell $2,547,817 from the amount paid to SCO by Sun. The decision is interesting because the court came to different conclusions about whether licenses to SVRX software in SCO’s agreements with Sun and Microsoft were “incidental.” This term was important because SCO did not owe royalties to Novell if the license of the SVRX software (the royalties from which would have to be paid to Novell) was “incidental” to the licensing of Unixware. This case demonstrates the importance of careful drafting in intellectual property licenses.

3. First Settlement of Patent Infringement Litigation For an Open Source Community. Red Hat’s settlement of the Firestar litigation demonstrated the need to carefully consider the nature of open source communities on the settlement of patent litigation. Unlike traditional patent settlements, Red Hat ensured that the settlement covered other members of the community including upstream licensors of products incorporated in the Red Hat product and downstream licensees. The settlement of patent litigation for open source products needs to deal with the complexity of many open source products and communities. This reality makes settlement of patent litigation much more complicated for open source products than for traditional software. (Read more about the patent litigation settlement agreement between Red Hat and Firestar.)

4. Major Litigation on GPL. In December, the Software Freedom Law Center (SFLC) filed suit against Cisco Systems, Inc. alleging that Cisco had violated the GPLv2 and LGPLv2 in its distribution of certain software whose copyright is owned by the Free Software Foundation (FSF), including GNU C Library, GNU Coreutils, GNU Readline, GNU Parted, GNU Wget, GNU Compiler Collection, GNU Binutils, and GNU Debugger. The complaint asserts that Cisco distributed the programs without providing complete and corresponding source code as required by the GPLv2 and LGPLv2. FSF requested that an injunction be issued against Cisco and that damages and litigation costs be awarded to the FSF. The SFLC states that they filed the lawsuit reluctantly and had negotiated with Cisco for two years on the issues. The suit raises the question of whether the SFLC is becoming more willing to file suits to enforce the GPL. For example, the SFLC has been vigorously enforcing the rights under the GPLv2 for Busybox.

5. Enforcement of GPL For Busybox Continues. The Software Freedom Law Center has continued to enforce the GPLv2 on behalf of the owners of the copyright in Busybox software. Although most of these cases apparently are settled without litigation, SLFC filed suit three suits this year: Bell Products, Super Micro Computer, Inc. and Extreme Networks, Inc.

6. Open Source Litigation From Other Countries. Although litigation about open source licenses has generally been confined to Germany and the United States, one case that settled this year about the enforceability of the GPL was in Isreal. The plaintiff, Maryanovsky, claimed that the IchessU software violated the terms of the GPL because IchessU software did not include credit for him and was released under a proprietary end-user license agreement. He also suggested that an audio-visual module developed by IchessU was a derivative work, since it could not compile without his code. The case was filed in 2006, but was settled confidentially this year.

7. SFLC Guide to Legal Issues and GPL Compliance. The increasing ubiquity of open source software as well as the litigation to enforce the GPL and other open source licenses has made understanding the obligations imposed by the GPL very important for a wide range of companies. The SFLC has been the leader in developing and enforcing the GPL. They shared their views of the legal issues in open source and the obligations imposed by the GPL in two publications: A Legal Issues Primer for Open Source and Free Software Projects and A Practical Guide for GPL Compliance. The Primer and Guide are quite useful. Although licensing attorneys may not agree with all of their conclusions (the nature of the law and the lack of court decisions make this statement true about most open source license issues), the Primer and the Guide should be read by any lawyer working with open source legal issues.

8. American Law Institute Publishes Draft of Principles of the Law of Software Contracts with Significant Problems for Open Source Software. The ALI is a very prestigious and influential non-profit institution whose purpose is “to promote the clarification and simplification of the law and its better adaptation to social needs.” The Principles state that the “best practices” in software licensing would be to include two new “non-disclaimable” warranties which would result in significant problems for the open source community. The warranties are the (1) warranty of non-infringement of intellectual property rights (such as patents or copyrights) if the contributor knew or should have known of the infringement and the contributor holds himself out by occupation as having knowledge or skill peculiar to the software and (2) warranty of no hidden material defects. Current law (and all OSI-approved licenses) permit the contributor (and any licensor) of open source software to completely disclaim all warranties—i.e., promises about performance or non infringement which could result in liability to a contributor or a licensor (so called AS IS provisions). If accepted by the courts, these recommendations would have a significantly negative effect on open source licensors. (Read more about how the ALI’s legal recommendations could create new liabilities for open source licensors.)

9. Publication of Version 1.3 of GNU Free Documentation License. The new version permits the use of the Free Documentation License (FDL) with the Creative Commons Attribution ShareAlike License (CCASL). The draft is an interim one and SFLC is working on FDL 2.0. However, the Wikimedia Foundation requested the FDL be made compatible with the CCASL. This change recognizes the need for the two major branches of “free” content licenses to be compatible just as the GPLv3 was modified to be compatible with the Apache license.

10. Project Governance Concerns Become More Important. The recent fork in the Twiki community (an open source wiki project) demonstrates the need for a community to think about how it will manage itself. As open source projects have greater economic value, the potential for the community to split over decisions regarding the direction of the project (in particular, commercialization) will increase. Communities need to develop processes to discuss these issues and come to a conclusion that is supported by the community. Although forks are always an option for open source projects, they generally create significant loss of momentum and can doom a project if it has competitors offering similar functionality. In the case of Twiki, the ownership of the Twiki trademark by Peter Theony, the project leader, was critical to the control of the project.

Today, all developers, entrepreneurs, and users of software need to understand open source, not least because, by dramatically speeding up development, improving quality, and reducing the cost of marketing and sales, it represents a paradigm shift in the development and distribution of software. The use of open source software is becoming ubiquitous: for example, the Apache web server is used by more than 60 percent of web servers and the Linux operating system is used on a wide variety of products ranging from digital televisions to computers.

Although the press has paid much attention to “pure” open source companies, such as JBoss or Monta Vista, many companies are adopting “hybrid” business models which include both open source and proprietary software. In 2007, major proprietary software companies announced the “open sourcing” of some of their products: Adobe “open sourced” its Flex tool for Flash programming and Yahoo “open sourced” its Flickr upload tool.  For software developers, open source software provides a significant opportunity to speed development and enhance functionality. Therefore, virtually all software companies that don’t closely manage their development and IT departments may have open source software in their products. The open source business model, even more that proprietary software business model, requires careful attention to legal issues because many such issues remain open.

Although some companies still openly express skepticism about the viability of the open source model, open source products are used by such major companies as IBM, HP, Dell, DaimlerChrysler, and E*TRADE. Furthermore, open source companies have become quite popular in the venture capital community. Major venture capital firms such as Kleiner Perkins, NEA, Draper Fisher & Jurvetson, and Walden International have invested in one or more open source companies. In 2005, venture capitalists invested over $120 million (some reports claim as much as $400 million) in open source companies. Although some investors have expressed concern about the availability of “exits” for open source companies, these concerns have been laid to rest in the last year including Yahoo’s acquisition of Zimbra, Oracle’s acquisition of Sleepycat, IBM’s acquisition of Gluecode, Citrix’s acquisition of Xensource, Red Hat’s acquisition of JBoss and Sun’s acquisition of MySQL. Sun Microsystems has shifted to an open source business model, making both its Solaris operating system and Java software available under open source licenses.

However, the uncontrolled use of open source software can lead to serious problems for companies. For example, IBM reduced the purchase price for Think Dynamics by 30 percent due to uncertainties arising from the use of open source. The use of open source software needs to be managed carefully. One reason for this is the many legal uncertainties that surround its use. None of the more than 50 licenses approved by the Open Source Initiative as being “open source” have been interpreted by United States courts; thus, many issues regarding use of open source remain uncertain. For example, the General Public License Version 2 (GPLv2), the most commonly used open source license, extends to all “derivative works” of the original program. A “derivative work” is a term with special meaning in copyright law, but its definition for software varies in different courts in the United States. The definition of derivative work becomes very important because the GPLv2 requires that if a company distributes GPLv2 licensed software, it must include the source code (as well as the object code) of all software, as well as the “derivative works” of such software. The Free Software Foundation has defined derivative works to include “dynamically linked” software. The GPLv2 further requires that all licensees be given the right to modify and redistribute such software without charge. Another major concern for many companies is that the GPLv2 terminates immediately upon any breach of its terms rather than the more common approach of providing a thirty day (or longer) period to “cure” any such breach. This immediate termination is particularly troubling because of the many uncertainties in the GPLv2. The new version, General Public License Version 3 (”GPLv3″), has corrected many of these problems, for example GPLv3 includes a “cure” period.

Another way to look at this issue is to note that profitable software development requires close management of open source software. For example, after Cisco bought Linksys for $500 million, the Free Software Foundation approached Cisco claiming that elements of Linksys products should be made available in source code form because open source code licensed under the GPLv2 was included in the product. Neither Cisco nor Linksys were aware of this at the time of acquisition. The Free Software Foundation, the developer and enforcer of the GPLv2, initially insisted that Cisco make the entire source code of the Linksys operating system available under the GPLv2. Such a result would have dramatically reduced the value of Linksys because the source code of the Linksys products would have been available at no charge to any licensee. However, Cisco and the Free Software Foundation came to an agreement that the open source software was limited to a single driver, and Cisco agreed to distribute that driver under the GPLv2. Recently, the Free Software Foundation has filed three lawsuits to enforce the GPLv2, including a suit against Verizon.

Both software developers and software users should avoid such problems by adopting an open source use policy. An open source use policy should address the following issues:

• Use of open source components in products for third parties

• Use of open source for internal purposes

• Approved usage models

• Implementation of policy by industry experts or outsourced teams

• Permitted/forbidden open source licenses

• Rules for contribution by employees to open source projects

• Use of commercial products (Black Duck/Palmida/HP FOSSology) to audit use of open source code

These policies may range from simple ones for startups to elaborate 60-page documents for large companies. A company’s open source policy is frequently implemented by committees which include technical, business development, and legal representatives who make the final determinations. One large company reviewed 1,500 potential uses of open source products in an 18-month period (they approved all but 10 uses).

As noted above, many companies who do not consider themselves “open source” are nevertheless incorporating elements of open source distribution and development into their core business model. The business model for software products can range from the traditional “services only” model, such as Collabnet, to “commercial” open source products such as SugarCRM. A common commercial open source model provides for distribution of the product under an open source license as well as distribution of a version under traditional commercial terms, including a performance warranty and infringement indemnity. The open source business model is very powerful because it enables a company to leverage its open source “community” of developers to review the source code and discover and correct bugs much more rapidly, in addition to the community contributing to new code which provides additional functionality. In addition, the open source model allows customers to “try before you buy,” which dramatically decreases the company’s costs for sales and sales personnel. Many open source companies have thousands or tens of thousands of downloads each month.

The relationship between a company and the open source community is unique to the business model, and it is essential. One radical difference between the open source business model and the proprietary business model is that the open source model requires that the software code be accessible to individual programmers: it should be “lightly” coupled or integrated so the members of the community can focus on a part of the product and not be forced to use large amounts of software with little value to them. Software programs that are tightly coupled or “non-modular” in design are not likely to be accepted by the open source community.

In addition, the open source community is very sensitive to companies that attempt to claim “open source” status without “giving back to the community.” A number of companies have claimed to be open source but they don’t make their source code available and/or don’t use an Open Source Initiative approved license: these companies have been uniformly unsuccessful in developing communities or have lost any community support. When a company loses a good relationship with the community, the result is sparse contribution by the community. Without community support, companies will lose the leverage that makes the open source business model so powerful.

In the worst case, failure to properly manage open source can result in the “forking” of code into two separate incompatible products. Forking is a problem particular to the open source business model. Forking is possible only because of the availability of source code, and it can destroy a product. As an illustration the content management project Mambo — founded by a commercial company, Miro — split into two groups, Mambo and Joomla, because Miro tried to exert too much control over the community.

The adoption of an open source business model also requires a different approach to an intellectual property strategy. Providing the software under an open source license means the trade secrets in the product will be lost and copyright will be much less important because of the scope of open source licenses. Thus, open source companies must depend much more on trademark and patent rights to maximize their value.

Even those software companies that do not incorporate components of open source into their business model need to understand these issues because both customers and potential acquirers are becoming much more sensitive to the use of open source software. Many large Silicon Valley companies have a specific provision in their development agreements which requires the description of, and advance approval of, all use of open source software. In fact, in one case, the provision relating to open source software has the title “Infectious Software.” Many sophisticated acquirers now have a separate “due diligence process” for open source software. The results of such due diligence regarding open source software can result in a reduction in purchase price or even termination of the transaction. Since acquisitions are very intense transactions, the worst result for a software company is to discover the use of open source software during the due diligence: when that happens, the solution or remediation must be found quickly, which limits options. The best approach is to adopt an appropriate open source use policy and to meticulously use commercial products to audit the implementation of the policy.

Companies that are users of software must also be careful about their use of open source software. The use can lead to problems if “blended” with proprietary software: as stated earlier, the breach of many open source licenses results in automatic termination without the ability to “cure” the breach. And many software “users” also distribute software to their customers, thus triggering the obligations regarding distribution under traditional open source licenses. Thus, many large software users also have open source use policies.

Open source provides many great opportunities, but it requires careful research, understanding and thoughtful management.

Each of these questions scratches the surface of concerns we think are urgent, and they’re not addressed by scanning alone.

The rumor mongers have an agenda, and you’d be right to suspect that we do, too. We are, after all, the company behind OpenLogic Exchange (OLEX), which comes in an Enterprise Edition that’s designed to cover all the bases of open source governance. However, rest assured that the point of this article is not to push our solution so much as to share the thinking behind our solution. If you can put together another stack that covers the bases we lay out for you here, more power to you.

Governance of Open Source in the Enterprise -  Six Elements

What you really want is open source governance that’s so easy you (and your users) will barely know it’s there. We’ve done this a gazillion times, and we’ve boiled it down to Six Elements:

1. Policies – First, decide what Is OK and what Is Not OK
2. Inventory - Figure out what you got
3. Provisioning – Figure out how you’re gonna get more…
4. Managing – …while following the rules from #1
5. Auditing – Circle back and confirm that everything’s still going ok
6. Reporting – Gift-wrap that “OK” to show you care (and give them sparkle for the board slides)

Approach these elements roughly as steps and they’ll lead you through a set of exercises that determine comfort level and current usage, establish monitoring and control of what’s used and where going forward, and result in the creation of a sustainable system going forward.

You’ll notice ’scanning’ is not mentioned at all here. That’s because we believe scanning is a means, not an end.

Policies

Scan to your heart’s content, but unless you’ve got a policy or policies in place, how in the world do you know if the open source you find in use in your enterprise is “okay”, or not? What’s “okay”?

To answer that question, you need to know some stuff, and then you need to create an open source policy. The questions below include the basic questions you and your organization need to be able to answer. A comprehensive open source policy includes bits of items #2 through #6 in this list, and we’ll get you more detail on each of those later.

1. Legal Stuff: How and why are you using open source software?  Policies should reflect a broader strategy — do you have one? Has your legal team vetted open source licenses?  Which open sources licenses are considered enterprise friendly for your use case?  Are different licenses acceptable for open source packages that are used in-house versus packages that are embedded in distributed products (e.g., products given to partners or offered for sale)?  Distribution is the key concept here, as many open source licenses contain special clauses invoked only in situations where code is distributed downstream.

2. Getting It: How is open source currently evaluated and approved in your organization? Where do users get the source once a package has been approved for use?  Is there an open source review board that defines the request and approval process, or are requests submitted to department managers, each with a different review process and risk tolerance threshold?  Is there a repository where users can find and download approved packages, or do employees download open source from the Internet whenever they want? Where is all this usage information tracked?  Who is the responsible party within the organization?  The goal of these questions is to determine what the standards are across the enterprise. Key to governance is ensuring that users all follow same process by making it policy.

3. Using It: Are employees allowed to modify open source code, and can they contribute code changes back to open source communities?  If code contributions are allowed, can employees use company email addresses when posting changes?  Are employees allowed to participate in online discussions using their corporate email address?  How do any of these policies apply to contractors, offshore resources, or partners?

4. Updating It: What are the guidelines for managing version updates?  Open source projects typically release more often than commercial software companies, and most CIOs don’t want 30 different versions of a particular package deployed throughout the enterprise.  Do new version releases need to go back through the evaluation and approval process before they can be deployed? Version upgrades are often necessary for security reasons, but multiple versions can also present problems when it comes to support.  Which brings us to…

5. Supporting It: Is technical support required for some of the open source packages you use, all packages, or just specific ones?  Can employees get support from the open source community mailing lists, and, if so, can they post questions using company email addresses?  Or do some/all/specific packages require commercial-grade technical support (which, by the way, you can get from OpenLogic — just an FYI because, seriously, we’re in this for money as well as the glory).

6. Communicating: How does the organization track and audit all of the above (or at least the most relevant parts), and how are results reported?  Also, how often are audits conducted, and who’s responsible for auditing and reporting?  How does your policy apply to software already in use vs. software currently in development?

Not to toot our own horn, but we know a thing or two about this stuff. We’ve been teaching Fortune 500 companies how to realize the benefits of open source software for ten years. We offer open source policy workshops as well as one-on-one guidance for organizations looking to create or improve their open source policy.  We also help organizations evaluate and select the open source packages that best fit their needs. Just sayin’.

Ok, so once you’ve got your policies in place, it’s time for a scan.

Inventory

All an inventory does is tell you open source software you got, and where you are using it.

Not to get all existential on you, but before you go crazy with an inventory, we suggest you first ask WHY. Why do you, X guy at Y company, why do YOU want or need an inventory of your open source?  Here are some of the reasons we’ve heard in our work:

• kickstart an open source policy
• establish a baseline for ongoing auditing efforts
• plan for support
• manage security updates
• manage risk
• prepare to distribute, divest, or donate software
• prepare for a merger or acquisition
• comply with internal policies
• comply with regulations
• comply with open source licenses
• manage intellectual property issues

The significance of these issues is weighted differently if the open source is intended for use internally, or it will be distributed.  For example, your company may not have to worry too much about “intellectual property” issues if you only use open source internally. Generally speaking, it’s more important to scan for licenses or code snippets when it comes to open source that is distributed outside the enterprise, and concerns around technical support are more relevant to scanning for open source software used internally.

WHY simplifies HOW. There are two main approaches to how: ask people or scan. Asking people to tell you which open source packages, licenses, and/or code snippets they’ve got in use has obvious limitations. Scanning tools are more reliable, but there are a bunch of options available with varying levels of cost and complexity. With your “why” information in hand, you can select the scanning tools that give you the information you need that fit in the context of the resources (both time and dollars) you’ve got. There are several open source scanning tools you can use, but the options listed below are usually a good place to start if you are just a normal user of open source — since you can’t beat the price (FREE).

• To scan for installed open source packages on a server or desktop, your best option is to go with OSS Discovery, a scanning application developed by OpenLogic that is both free and open source. OSS Discovery will tell you what’s installed on your machines, or what libraries your application is composed of, and it’s easy to download and run. OpenLogic also offers a free open source inventory analysis for up to 500 systems using OSS Discovery. Relatively painless.
• To scan for open source licenses, you might want to try a solution like HP’s FOSSology. FOSSology finds open source licenses in source code or binaries and it’s a free and open source application. The learning curve on this one is a little high, but still well below planetary physics.

If you’re part of a software company or a company that distributes hardware that contains open source software, you may want to consider shelling out the bucks for a proprietary scanning tool.  Keep in mind, though, that this option will also require some expert analysts to run the tools and sort through the results, so make sure you’ve got that in your budget.

• The most complicated scanning options available look for open source code snippets in addition to installed open source packages and licenses. Black Duck and Palamida are the two main purveyors of this type of tool. Because the learning curve on these solutions is high, and the costs associated, you don’t want to go this route unless absolutely necessary. “Absolute necessity” might be, for example, if you need to be 100% sure that you won’t be obligated to release as open source the code in, say, the missile defense system your company is planning on selling to the government. If you need this level of coverage, there aren’t a lot of options, so be prepared to spend. Fortunately, most folks can get by with a more practicable level of diligence.

The important thing when picking a scanning solution is to start by defining your scanning goals.  Once you do that, you can pick the right level of scanning that meets your needs.  Be selective and avoid overkill, yet ensure you’ve covered all your bases — it’s quite possible that you could end up using different scanning tools to create the result desired in different realms of the organization. Also, keep in mind that creating an inventory won’t be a one time activity.  Depending on your goals, you’ll want to inventory again in the future — for example when putting a new application into production or releasing a new product.

Next, you’ll want a place to report on and store your inventory results.  You’ll also want to compare your inventory against your policy in order to see where you might have, let’s say, “circumvented” the policy.  Once you’ve got your inventory cross-checked against your policies, you’ll need to do a little remediation, but then you’re caught up, up-to-date, and in the clear.

And what will you do with the results of cross-checking between policy and scan results? It would be best if there were a place to load the scan results that would log usage. If this place applied your policies, or checked against your policies and provided you a report on infractions, that would be best. A central open source governace tool, say for instance OLEX, might be a good option, but we’ll get a little further into that in a minute.

Provisioning

As you’re taking inventory of the open source you’ve already got, consider establishing a go-forward process that will govern the use of any new open source users need. Presuming you’ve taken our advice and put your policies in place, what you need now is a comprehensive repository of open source that’s safe, secure, and ready for deployment in the enterprise.

Funnily enough, the OpenLogic Library of open source is just such a place. We provide a tidy one-stop-shop that’s freely accessible through OpenLogic Exchange (OLEX).  The OpenLogic Library offers the most extensive repository of enterprise-ready open source software on the planet.  And “enterprise-ready” is not just marketing buzz in this case. If you download a “certified” open source package from the OpenLogic Library, you know that it has passed our 42-point certification process and meets basic standards of quality, usability, and community backing.  OLEX provides you all the information you need to determine whether or not a package fits into your policies, and we also check daily for security issues and provide patches as they are released for all business-critical projects. When we find such an issue, we notify you via OpenUpdate — an HTML newsletter available to subscribers of OLEX Enterprise Edition.  We also sell support on open source in case you find yourself needing such services.

The Request and Approval mechanism in OLEX provides part of the go-forward audit trail governance requires. You can, by policy, decide if a particular project can be used with abandon, requires approval, or should be denied. Policies can be applied to specific open source packages, specific versions of packages, and/or licenses.  Users simply submit online forms, which are routed to reviewers for approval (if necessary) and stored for future auditing purposes.  End result: OLEX ensures that all open source in the enterprise comes from a single source, adheres to the same policy, and can be easily audited at any point in the future.  (If you’d like to try the OLEX Request and Approval process for yourself, sign up for a free 30-day trial. Again, access to the library is free, but the additional governance features require a subscription.)

Managing

So, now:

• you’ve got your open source policies in place
• you’ve scanned all machines and applications for installed open source in your enterprise and cross-referenced the results against your policies
• you’ve done some remediation and established accepted baselines of open source packages in use
• you’ve got a go-forward solution in place and employees are using a system like OLEX to enter requests to use specific open source packages

This all takes you a long way toward effective management of open source usage in your company, and we can all agree that management is the key aspect of governance. But at this point you’ll also want to take a look at your build and development practices and pull the scanning option back in. Add a scan of source code to your practices, and also scan any third party source code if you’ll be distributing the project downstream.

This set of scans is really the only way to be certain you’re meeting all open source license obligations, which is a key element in the effective, legal use of open source. Different licenses require different actions on behalf of the user, from nothing at all to acknowledgment of the original author to the inclusion of modified source code. Establishing and maintaining a firm hold on your license obligations is key to successful use of open source in your enterprise.

Auditing

Policy? Check.  Inventory? Check.  Repository for provisioning?  Check.  Approval process? Check.

By now you should have a good handle on your open source usage.  But, you’re going to still want to check up on yourself every now and then.  An audit will tell you how well all of your policies and processes are working.

You may want to audit a particular application or solution based on development milestones at the end-stage of the development process, just before a new application goes into production or gets released.  You may also want to audit a sampling of systems on a regular basis, such as quarterly or annually.

Typically you’ll use one or more scanning tools to conduct the audit. All the results should get tracked, stored, and compared to what your policy says and what’s been approved.  You can look for any red flags — where what’s being used is different than what you thought — so that you can work on improving your process (and maybe having a friendly little chat with the offender). OLEX Enterprise Edition lets you upload scan results and provides reports showing any place where open source usage doesn’t match your policy and approvals.

The point is, scanning should play a continued role in your go-forward strategy. You’ll want to establish a process by which scans are routinely (annually, or more often) run on machines and applications, and the results are compared against reports of what’s been approved. OLEX provides these reports based on the open source usage requests submitted and approved, and it will also give you a heads-up if any in-use packages violate your policies.  Further, OLEX can help you to see if you are falling behind in terms of released versions, and alert you to any security vulnerabilities that exist in the open source packages you are using.  Pretty cool, huh?

With this information in hand, you’ll also want a process in place to evaluate corrections to the results of infractions indicated by auditing results.

Reporting

One client we’ve worked with has 4,000 machines in play — definitely not information that the most competent systems administrator can keep in her head. That’s why, whatever solution you choose for your governance needs, you’ll want a stack that includes reports. Lots of reports. For instance, you’ll want:

1. Inventory Reports: What open source packages are used, on which machines, as part of which internal development project. This will enable you to

• Assess technical support needs
• Manage security patches and version updates
• Assess potential risks
• Assess version aging and proliferation

2. Policy Compliance Reports: Where am I out of compliance with internal policy?

3. License Compliance Reports: Where am I out of compliance with open source licenses?

And that’s just a start. OLEX Enterprise Edition can provide these reports for you, so you can keep the “suits” happy and the developers developing.

Conclusion

What more can we say? We’ve given this a lot of thought. It’s our business.

WHAT’S DIFFERENT

JBoss is now JEE 5 certified.  In truth, it’s had most of the significant features of JEE 5 for a long time, but if you’re one of Those People who’s been waiting on the official certification, your wait is over.

Another significant change is that the components of the JBoss Application Server are more modular than before, and developed as separate projects (e.g. JBoss Messaging, JBoss Transactions, JBoss EJB3). The JBoss AS 5 distribution includes all those separate projects already grouped together. The modular nature of these components will probably allow for easier development, resulting in a shorter release cycle.

This version introduces a new microcontainer that replaces the JMX-based microkernel . This lightweight container manages POJOs, but it allows for “multiple personalities”, continuing to support the old JMX model for backward compatibility while paving a way for OSGi support. The microcontainer integrates with JBoss AOP, and JBoss 5 uses AOP heavily. The new deployment layer is heavily influenced by AOP, too.

And that’s just the tip o’ the old icy burger…

TALK OF THE TOWN

Here’s some other stuff to be excited about:

• This new JBoss can be embedded much more easily. Nice feature if you need a container available in your JUnit tests, or want to use EJBs in an app server that doesn’t support them.

• JBoss 5 is probably the largest software system heavily using AOP. If you are using aspects in your software or are just curious how are they used on very large and highly visible project, JBoss 5 and JBoss AOP is worth a look.

• At the time of this writing, documentation about JBoss 5 is still in the fairly early stage but is getting better by the day.
• If you’re particularly interested in JBoss and JDK 6, take a look at the release notes.

JBoss 5 was available in Beta and Release Candidate form for the long time, so GA release likely benefited from user feedback. Some of the new features that it offers are extremely useful and there is no doubt that JBoss 5 represents the future of JBoss. If you are using JBoss in your development environment or just starting to develop your application, consider the move to JBoss 5 soon.
If you are thinking about use in production environment, our take is that you should plan for moving to JBoss 5 in the next few months and start your internal testing with that in mind. But for immediate production use, we would recommend testing and learning about JBoss 5, but waiting a bit before you migrate it to production. This will give developers a chance to improve  the documentation, you a chance to get experience with it in non-critical environment.
DIG DEEPER

• Release Notes

• More on embedding JBoss

• More about microcontainer

• JBoss 5 microcontainer user guide

• JBoss 5 Installation and Getting Started Guide

What’s different

There is a loooooong list of changes for this release. Sun/MySQL have been working on this version for years so that’s to be expected. Despite that, upgrading from a prior 5.0.x release is painless and they have even added a upgrade helper.

Here are some of the new features:

• Partitioning: Increased Performance, the optimizer knows about the partitions and what data is stored in the partition so mysql will access only those necessary partitions during query execution. Simplified Data Management, if designing the data structure correctly you can get an easier/cleaner database that will be easier to manage.
• Event Scheduler: This tool has been missing in MySQL. Moving common recurring SQL-based tasks to execute on the database server and not in cron/windows scheduler is a very welcome feature.
• Row-Based and Hybrid Replication: There are so many wins that you get from using row-based replication and I feel this is a great feature that was added to 5.1. The new default to 5.1.30 is the hybrid mode which downgrades to statement based replication. The MySQL manual has a good pros and cons for the two http://dev.mysql.com/doc/refman/5.1/en/replication-sbr-rbr.html.
• MySQL Cluster: This is now a separate product which has to be added if you want to use the NDB cluster engine. Pay attention here as this move confused people since the Cluster version is now at 6.3.
• Tablespace Backup: You can now use mysqldump –all-tablespaces to dump a NDCLUSTER tablespace.
• mysql_upgrade: Checks all tables in all databases for incompatibilities with the current version of MySQL Server. If a table is found to have a possible incompatibility, it is checked. If any problems are found, the table is repaired. With multiple mysql servers running on one db server use mysql_upgrade -p 3307.

Talk of the town

There has been much talk about the new release and “if” this release is production ready. It is our belief that this release is production ready. For our applications, we have been running 5.1 for 6 months in production without hitting one single bug. That said, we caution you to make this decision on your own, with proper testing. We recommend that you read the MySQL bugs list, and install a test server where you can run tests with your environment.

Dig Deeper

Here is the extensive list of changes for MySQL 5.1.x.

What’s different

Much of the cruft that had accumulated over the 2.x releases has been removed, and the language has received a serious amount of well thought out tidying.  Unfortunately, nothing in this world is free, and the exceptional cleanness of Python 3 comes at the cost of backwards compatibility.  Still, the cost appears to be worth the price as the update is less error prone, more internally consistent and easier to maintain.  This greater consistency results in a language that is easier to learn. With whole classes of defects effectively eliminated, Python 3 is a safer bet as well.

A selection of the bigger changes include:

• print is now a function instead of a statement.  Keywords are now used to replace the special syntax of the old statement.  This change makes the language more consistent, but the most significant benefit is that it’s now substantially easier to alter the behavior of print in your code. Here are a couple of examples:

  print "foo" #old
  print("foo") #new
   
  print >>openfile, "bar" #old
  print("bar", file=openfile) #new

• String formatting has likewise received a significant overhaul.  Instead of using the old % syntax for templating strings, the str class now has a format() method.  Format can use positional arguments in the string ( {0}, {1} ) to pull values from a list or a set, but it can also use keywords to fetch values from dictionaries and objects ({0[name]}, {sys.platform} for format(somedict) and format(sys=sys) respectively).
• All strings are Unicode now.  The str class has been replaced with the unicode class.  The bytes class has been introduced to store unencoded data.  Effectively this means that str behaves like unicode used to, and bytes behaves much like str used to.  The biggest difference in the new behavior is that you can now no longer mix the two types, and so you must use str.encode() and bytes.decode().
• long has been renamed to int.  The old int type has been removed.  There is now only one integral type in python.
• Integer division is now true division and returns a float.  3/2 will return 1.5.  Use the 3//2 syntax to get the old behavior of returning 1.
• String exceptions are dead.  All exceptions need to be exception classes that inherit from BaseException or it’s children.  (Though in most cases they should inherit from Exception.)  This means the long transition from Perl-style string exceptions to more Java-style object exceptions is complete.  (As a note, the object exceptions became even more Java-like with exception chaining being added.  The days of Python swallowing exceptions are numbered!)
• Set literals have been added with syntax similar to dictionaries: {1, 2}.
• Dictionaries and sets can now both be created with comprehensions.  A comprehension is like a dict or set literal that uses a function to populate the set or dict instead of declaring specific values.  Example:

  # set comprehension
  {letter.upper() for letter in "foo"}
  {'F', 'O'} #resulting set
   
  # dict comprehension
  {letter: letter.upper() for letter in "foo"}
  {'f': 'F', 'o': 'O'} #resulting dict

• Views and Iterators replace lists in much of the standard library.  dict.keys(), dict.items(), dict.values(), map(), filter() and zip() amongst other functions no longer return lists.  Instead they return views or iterators.  This change prevents a whole group of possible hard to detect defects that come from people depending on the order of values returned from these functions.  Each of these more properly returns an unordered set or an iterator instead of a list.

There are many other more minor changes as well, mostly involving the removal of parts of the language that should no longer be used such as old style classes. A few other highlights include the removal of <> in favor of != for inequality, dropping dict.has_key(foo) in favor of foo in dict and the addition of function annotations to unify how various IDEs can do some level of type checking.

Porting your code and the value of Python 2.6

Many of the changes for 3.0 have been previewed in the simultaneously developed release 2.6.  Version 2.6 is not just a new release in the 2.x series, it is also a fantastic tool for assisting in the migration of code from 2.x to 3.x.  Some changes – such as string formatting – were backported fully to 2.6, and many other features – such as the print function – are available to import from __future__ for use in your 2.6 code today.  Finally, the tool 2to3 will automate most of the process of porting code from 2.6 to 3.0.  Reports so far are that most code can be made to work in 2.6 and automatically translated to 3.0 with a relative minimum of fuss.  As a note, the Python maintainers suggest that as long as a project wants to maintain both 2.x and 3.x sources, they should maintain the 2.x code, and use the code generated by 2to3 unmodified (with bugfixes to the 3.x code implemented in the 2.x sources).

What does it mean

Python 3.0 has done a lot to keep the language’s syntax clear, clean and obvious, but that doesn’t mean anything if you don’t have the libraries you need.  Python 3.0 can be thought of as more of a transitional release then something targeted at the average developer.  For the average developer to find it useful, the libraries need to get ported first.  Until frameworks such as Django and libraries like Twisted are ported to the new syntax, likely most of us won’t find ourselves coding on a release past 2.6. Version 3.0 is a well done introduction to the new language syntax, but it’s really a release intended for the maintainers of popular Python libraries and frameworks so that they can get their offerings up and running for future releases like 3.1. or 3.2.  This should give the 3.0 code a chance to become rock solid and as fast as the 2.6 branch before we all make the leap (3.0 is purportedly about 10% slower then 2.6, but the C code is as yet unoptimized).  Python has taken a great step forward, but it will still be a year or two before the rest of us can take that step with it.

Dig deeper

Find out about all the changes in the Python 3.0 changelog.  You can also read about many of the transitional features in the Python 2.6 changelog.