wiki:LGPLvsBSD

Comparison of BSD and LGPL

Glossary

  • BSD = Berkeley Software Distribution
  • FSF = Free Software Foundation
  • GPL = General Public License
  • LGPL = Lesser GPL
  • ASL = Apache Software License

Disclaimer

From the author (Daniel Weck):

Although I am more inclined towards the LGPL license, I appreciate the "benefits" of a BSD-style license. Please bare in mind that I am not a lawyer nor experienced in this complex field.

Licensing Scenarios

Both BSD and LGPL licenses address the needs of businesses (i.e. protect their source code and intellectual property). However, there is a significant difference which should be explained.

Let's illustrate with an application "APP" and a library "LIB": APP cannot really exist without LIB, because LIB provides services that APP requires in order to execute properly. We assume that APP ships with LIB, whether LIB is dynamically or statically linked into the application is irrelevant.

A typical real-world example is XML input/output: companies won't bother programming an XML parser/serializer for their application, they will just use an existing library and ship it along with their executable binary.

Another concrete example for us is Obi and the Urakawa SDK.

Now, let's consider these various scenarios:

  1. If LIB is GPL, APP must be GPL too, which means that the entire source code of APP must be under the GPL license. GPL guarantees that the whole software stack remains open, so it doesn't serve business interests at all.
  1. If LIB is LGPL, APP can be closed-source (aka proprietary). That is if LIB is a verbatim copy of the original. Now, if the company decides to modify the source code of LIB in order to meet their needs, they must release the modifications into the public domain, as a contribution back to the open-source community. This is sometimes described as the "quid-pro-quo". LGPL guarantes that the library remains open, but is compatible with business motives at the same time. FSF licenses (GPL, LGPL, etc.) are typically developer-friendly. The rationale for companies is that they ultimately benefit from QA patches and updates made by other companies, thanks to the quid-pro-quo loop mechanism. Because of this, LGPL is GPL-compatible. By contrast, BSD is not GPL-compatible.
  1. If LIB is BSD, APP can be closed-source. Now, when the company modifies the source code of LIB (aka "derivative work"), they are not obliged to disclose the changes. This is called a proprietary fork, and this is a common characteristic of permissive licenses which allow adding restrictions.

The BSD license is very simple and short: it has few restrictions compared to LGPL, or even the default restrictions provided by copyright. This probably explains why it is so popular. BSD-supporters argue that it puts it closer to the public domain.

Unfortunately, BSD-style licenses serve a niche market of competing vendors, at the detriment of the broader open-source community which contributed LIB in the first place, but also at the detriment of the large number of third-party vendors. BSD is basically a license to steal. As a developer, the choice of BSD means offering the competition the very rope with which to hang yourself <grin>.

In concrete terms, the advantage of LGPL over BSD is that it promotes project stability, by avoiding fork fragmentation and by encouraging positive feedback.

Most existing large open-source products are successful today because they have not forked. Apache (under BSD-style licensing) is one of the exceptions, which can be explained because it was the first there, grew fast, and eliminated the potential of a profitable market around the core product. Where there is value-added (i.e. server-side components, SSL encryption, etc.), there is a lot of forking because of BSD-style licenses.

Competition is good, but product fragmentation in a highly competitive market place never benefits the end-user (too much choice of exactly the same technology with various level of quality and support from several competing vendors).

The vast majority of third-party vendors tend to contribute to a great extent back into the open-source community. That is something that BSD licensing simply doesn't protect, and it fact it encourages the reverse by being nonreciprocal.

Dual-Licensing

Dual-licensing is a popular option, and it often occurs between LGPL and a permissive license, like BSD or ASL.

Generally-speaking, the main motivation for dual-licensing is a desire to please both the LGPL-fanatics and the BSD-lunatics <grin>. This way, you are guaranteed to reach a wider audience.

Unfortunately it is also a symptom of the lack of understanding between the different licenses (disclaimer: in my opinion).

It comes down to where one wants to stand in the market place.

DAISY-Pipeline [core]

Exploiting the Pipeline-core commercially seems to consist essentially in writing plugins and distributing the whole application together. I think LGPL is perfect: companies needing to improve the core must contribute indirectly (in-house patches + public commits) or directly (staff contribution into the main repository).

DAISY-Pipeline [GUI]

Extending the Pipeline-GUI could be contentious, because companies might want to protect the user-interface design changes they make in order to meet organization-specific requirements. I think that dual licensing LGPL-BSD/ASL is more appropriate.

Obi

I would make the same remarks as above, although this is debatable.

Urakawa SDK

I think that the SDK should be LGPL, because we want to get feedback when modifications to the core are made. This does not prevent a third-party vendor to develop and extend the SDK under BSD-style licensing (because they don't modify the internals of the core SDK, they just extend it programmatically, like with any other framework). Basically, they can extend the SDK in their own namespace, ship it in their own library or application, and make money while not divulging their proprietary code. But at least, they are forced to give back to the Urakawa project when they fix bugs or improve the core SDK.

AMIS

DAISY playback is a competitive area in the market-place, and SMIL playback could definitely gain momentum by providing value-added to third-party developers.

Ambulant is LGPL. I think that's a good idea, given how few decent SMIL runtimes there are on the market. If this became a competitive market area, BSD-style licensing would encourage forking without contributing back.

I think the same about AMIS, it's best to keep it a "real" open-source application, with real benefits for developers. AMIS needs to remain quality software to serve developing countries, as per DFA's mandate. Using BSD-style would jeopardize that, or at least compromise it.

Tobi

It's too early for me to comment. It depends on the kind of contributions we get from third-party vendors that contribute to the project.

References