Open source needs to clean up its language

Open source licenses are all very different, but they are often categorized according to an important attribute. Some open source licenses implement a clever hack invented by Richard Stallman where as a condition of the copyright license, anyone creating derived versions has to agree they will license the new version the same way as the original. In a play on words, this concept is called "copyleft."

In its strongest form, this "copyleft" idea can place a condition on the licensing of all the other code compiled together to make the eventual binary executable program. Complying with this requirement can be complicated (and expensive), so as a consequence, many commercial software developers avoid the strongest forms of copyleft licensing.

[ InfoWorld presents the Bossies 2013, the best open source software for clouds, mobile, developers, and more. | Track trends in open source with InfoWorld's Open Sources blog and Technology: Open Source newsletter. ]

There are less stringent forms of copyleft. Licenses like the MPL (Mozilla Public License) and the CDDL (Common Distribution and Development License) only require individual files that are modified to be licensed under the same license as the original and don't extend that requirement to other files used to build the executable. This is sometimes called "weak copyleft".

In discussing these licensing approaches with clients, I've often found that these terms "strong copyleft" and "weak copyleft" lead to misunderstandings. As a consequence, I prefer to use different terms.

Instead of 'copyleft,' use 'reciprocal licensing'
First, I try to address the complexity introduced by the clever, often unfamiliar term "copyleft." Instead of that term, I explain that the communities involved have norms based of reciprocal behaviour -- "do as you would be done by." Leading licensing specialist Eben Moglen (key co-creator of the modern GPL) explains that open source licenses embody the norms of the communities that use them. They are the "constitution of the community."

They use this copyleft concept in their licenses to embody the expectation of reciprocity by community participants. So I refer to this aspect of the license as "reciprocal licensing" in an effort to acknowledge the use of copyleft to express the community expectation of reciprocity. I've found this term leads to less confusion.

Instead of 'strong' or 'weak' copyleft, describe the reciprocity
Second, I have found that the terms "strong" and "weak" are not well understood. What really matters to developers is the expected scope of the reciprocity by the community that's involved. The term "reciprocity" is used to indicate that the same freedom extended to the person using project code to create improved code is expected to be extended by that person to others. This does not always mean contributing code to a project; for example, the GPL only requires that a developer offers to make code available on the same terms as the original. But reciprocity does mean that consistent licensing must be maintained.

This concept helps in the case of the LGPL. That license is often described as a "weak copyleft" license since it allows combination of the resulting binary with non-GPL-licensed works (unlike the GPL itself). But the "weak" categorization is unhelpful as it means different things in different contexts.

LGPL is not "weak" in the same way MPL is, for example. Code from an LGPL project itself is fully reciprocally licensed at a project level. Any code borrowed from it for other uses as well as any alternative uses of the project itself are expected to be fully licensed under the same LGPL. Within the project itself, LGPL is "strong copyleft" just like GPL code, but the resulting executable does not necessarily have "strong copyleft" requirements -- it's effectively non-reciprocal in many uses.

I prefer to categorize reciprocal licenses by the scope of the expected reciprocity. Licenses like GPL and EUPL set the scope of the expected reciprocity to include any code needed to create the resulting project binary, so I describe these as "project-scoped reciprocal licenses." This categorization proves helpful with LGPLv3, which is a project-scoped reciprocal license with an exception limiting the boundary of the project.

Licenses like MPL and CDDL set the scope of the expected reciprocity to the individual source files within the project, not the whole project collectively. If you change a file that's part of the project, or reuse code from a file in the project in a new codebase, the resulting file must be licensed the same way as the original file, but there are no requirements placed on other files combined together to create new executables. I refer to these as "file-scoped reciprocal licenses."

Instead of 'permissive,' use 'non-reciprocal'
Thirdly, licenses like the MIT, BSD and Apache licenses are sometimes described as "permissive." This tends to disguise the fact they include strong terms requiring specific actions by developers using the code in them; those terms simply don't include reciprocity requirements. Consequently, I find it more helpful to describe them as "non-reciprocal licenses" so that the classification is clearly limited to just the reciprocity characteristics of the licenses.

In practice, I have found that these three terms -- project-scoped reciprocal, file-scoped reciprocal, and non-reciprocal -- highlight what matters most to developers and avoid unintentionally confusing the issue. I recommend their use.

This article, "Open source needs to clean up its language," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

Source: http://www.infoworld.com/d/open-source-software/open-source-needs-clean-its-language-229838?source=rss_infoworld_top_stories_
Tags: kansas city chiefs   Revolt TV   TSLA   world war z   new york times