Author: Mary E. Tyler
(OSI) lists more than 50 approved open source licenses. Each license
is anywhere from slightly to vastly unlike its neighbors.
All of them are written for lawyers, not mere mortal software
developers. So how do you choose the most sensible an open source
license for your projects?
There isn’t one answer for all open source projects,
according to Lawrence Rosen, the founding partner of Rosenlaw and Einschlag, general
counsel for OSI and author of a new book Open
Source Licensing: Software Freedom and Intellectual Property
Law. “I say, ‘Tell me about your software.’ There are
companies that want to open source some of their [code] and not all
of it,” says Rosen. In order to advise them, “I have to understand
what their product is.”
Sometimes the choice of license is dictated because the software
in question is a derivative of software open-sourced under a
particular license such as the GNU Public
License (GPL). “[Reciprocity] is a common feature,” says Rosen.
“At least half of [open source licenses] contain a reciprocity clause
— a derivative work of a GPL program is required to be GPL.”
Of
course, if the product is derived from more than one piece of open
source software then it becomes a sticky exercise to combine the two
licenses. For example, suppose one ingredient is GPL and another is Apache
Software License (ASL). GPL has reciprocity and ASL doesn’t. “When
the [developer] uses this from column A and this from column B and
now the license from A and the license from B have to be put together.
It’s not a start from scratch,” says Rosen. “It becomes complicated.”
When not dealing with a derivative work, the process is both
easier and harder. First, a company should decide if they want to
open source their product at all. There are other models besides open
source, according to Rosen’s book. There is
“shared source,” which allows customers to read and examine the source,
but not to modify it or build derivative works. There is “public
source,” which allows modification and derivative works for
non-commercial purposes (as defined by the license). A company can
license its works under multiple licenses, including a commercial
license for those who want an official copy to integrate with their
own offerings without the onus of a GPL license. MySQL is licensed
this way, under both commercial terms and the GPL. Another scheme has
the current version of a product remaining commercial while its
predecessors get released under a traditional open source license.
Some of these schemes are heretical to the diehard open source
community, but
for a company there has to be a business case in favor of, or at
least not against, open sourcing the product. A company has to know
that it can still make money from its product even if it gives
it away. Rosen uses a familiar metaphor from supermarket shopping.
“If you give [your product] away, you have to turn free stuff
into a loss leader for expensive stuff.” This stuff (a technical
term, see “appurtenance“)
could be the hardware that runs the software, or the services that
install, maintain, support, or integrate the software.
A company must also come to terms with the fact that it will
not be able to prevent others from profiting from its open sourced
product without returning a penny of that profit. According to Rosen,
there are some things developers can do to inhibit the free rider
problem. “The first issue is, do you want a reciprocal license like
the GPL or an academic one which allows [software] to be turned
proprietary,” says Rosen, acknowledging that this is an argument that
continues to rage through the community. “If you decide on a
reciprocal license,” Rosen continues, “which one? The GPL says
“works based on the program.” [It’s] vague so people are
afraid of it. The Mozilla
[Public] License (MPL) is a reciprocal license, but if you create
a file [with any “Original Code” (see MPL section 1.1)], you have to
release that file.
According to Rosen, there are a multitude of other considerations.
If you decide you want a reciprocal license, do you want a wide
definition of “derivative works” like the GPL or a narrow one like
the MPL? Or do you want something like the CPL, which lets
copyright law define what is deriviative and what isn’t? You have to
consider what patents you are licensing, if any, and whether those licenses
flow through to any derivative works. Do you want to protect your
downstream developers from patent infringement? Warrantees and
liability, or disclaiming such, should be on the radar as well. You
should be considering issues like jurisdiction — where you want any
claims to go to court — and governing law: contracts or copyright, or
both? And if someone sues you or you sue a licensee, who pays for the
lawyers? The license has to cover all those issues as well.
“There are lots of licenses by lots of companies, so
you have to think about those differences and how they apply to your
product,” Rosen cautions. “There is no one-size-fits-all solution.”
