that licensing is a bigger consideration for techies than it is for business managers, and it is important to get the issues into perspective. As Ira Heffan wrote yesterday: "If you are planning to use the open source software internally as a stand-alone application and are not going to distribute it, most likely [the license] will be compatible, but still worth taking a look."

All organizations should have processes in place for evaluating contracts and licensing terms, and these should also be used to evaluate open source software, but unless an organization is planning to modify and distribute the software, open source is not necessarily deserving of special attention.

The issue of contribution is covered by today's other question.

If an IT manager is looking to purchase a technology or service based on an open source technology, they should make sure that their procurement and legal groups are brought into the discussion as early as possible.

The larger your organization is, the more likely there will be some sort of clause in any type of terms and conditions attached to a purchase order that would be used to buy technology or services from a solution provider that makes use of open source.

If there is a desire to purchase open source products, then working with your legal and procurement groups before you ring a vendor into the conversation can be more effective then letting your vendor of choice do the negotiation.

Ron Gula
CEO, Tenable Network Security
http://www.tenablesecurity.com
http://www.nessus.org

Framing the question in terms of AGPL and GPLv3 implies that variations of the GPL are the only licenses that matter. Which is a shame because if open source ever settles into a single licensing model we have collectively lost a large part of what is important about open source: diversity. Diversity of community and diversity of business models. And a mono-culture in open source does not sound any more attractive to me than a monopoly in proprietary software.

Open source licenses to a very large degree determine the business models of the companies that use them. Companies that select the GPL and its variants are typically following the dual-license model so successfully pursued by MySQL. Venture-backed companies are attracted to this model because it allows them to maintain complete control over their IP, simultaneously offer a commercially licensed variant and potentially foster a community around their code. The question of course, is why do enterprise buyers elect to purchase the commercial version? For many of them it is simply because their legal departments do not want GPL-licensed code in their software stack above the Linux operating system watermark. They would rather pay for commercial licenses. In that context, comparing GPLv2, GPLv3 and AGPL is really comparing different varieties of apples, not apples and oranges.

Because the IT industry hype machines largely runs based on what’s happening in the startups, there is a perception that “open source business” is settling around the GPL and dual-license model. But the fact is that if you look outside startups, what you find is very different. If your enterprise uses commercially licensed software such as IBM Websphere, BEA (now Oracle) Weblogic or SAP Netweaver Studio to list just a few examples, your enterprise is using open source. All of those products make liberal use of code from Apache (ASL) and/or Eclipse (EPL) amongst others. The difference is that the IP due diligence and the license compatibility checking was all performed by the vendor, rather than asking the enterprise to take on the role of both system and license integrator. In all of those cases, the companies shipping commercially licensed products make significant contributions back to the communities from which they take code. In fact, in many cases they collaborate with their direct competitors in order to build open source platforms, and then compete with their differentiated products in the marketplace.

The point is that you cannot separate licensing issues from business models. The two are highly correlated in the open source world. And “open source business” is a much larger conversation than GPL variants and which venture-backed open source startups are going to survive in the long term.

Open Source often gives you more choices in how you may use the software. And that is probably one of the main reasons there is so much ado about the licensing. Consider the following questions for your specific use case scenario:

Is your organization planning on using the Commercial or the Community/Open Source Edition of the software (i.e. which of the licenses apply in a dual-license model that is adapted by many Commercial Open Source vendors)?

If you plan on using the Commercial Version, then it is likely you will be dealing with a Commercial License.

If you plan on using the Community/Open Source edition then you are likely to be governed by the Open Source version of the license. As Matt mentioned above, if you use the software in a contained fashion, i.e. no redistributing, incorporating or re-packaging, you are likely to be safe. Some of the licenses covering Community Editions make specific provisions for modifying and extending the code base, but pragmatically protect from more invasive revenue-generating actions like branching and re-distributing.

Of course, Open Source software is distributed under a range of licenses, ranging from GPLv3 to BSD. The choice is often particular to the nature of the software itself and the goals behind the project. Viral licensing (like GPLv3) is critical for consumer-ready applications, while BSD-type licensing may be used by more infrastructure/system vendors and non-commercial groups. The question goes back to how a given company applies its Open Source strategy: is is at the core of the business, a lead generator, a market share-driver, a way to build a community, etc. Each goal may require a unique set of parameters, and therefore a modified license.

For the IT manager in charge of purchasing however, it is always critical to understand the license terms, regardless whether it is an Open Source or a Commercial license. Open Source by the definition is no more or less dangerous, but it opens doors to possibilities that Commercial software just does not present (since, well, you can’t see and then re-use the code!). So with any software you are considering, do a once-over with legal on it.

At Alfresco we have gone through several permutations of open source (OS) licensing before settling on GPL v2. Why, you might ask, didn’t we start with GPL v2 – which is the most popular OS license?

I think this really reflected both the development of our thinking and our confidence in OS as well as concerns from “advisors” about how enterprises would react to GPL.

The reality we came to realize was that the OS business model works if all the non-value added activities can be minimised i.e. maximum value can be delivered to the customer for the minimum amount of effort.

Licensing discussion have no added value as far of the performance and operation of the software and so Alfresco settled on the GPL simply because it is the most common and best understood license and for us has dramatically reduced these non-core conversations. This in turn benefits our customers as we can grow and scale faster.

John Powell
CEO, Alfresco Software
http://www.alfresco.com