GPL or BSD? A Personal View on Licensing Hobby and Academic Software

Software licenses are sometimes discussed as if one of them represented freedom while another did not. This is not particularly helpful. Both the GNU General Public License and the BSD licenses grant freedoms which ordinary proprietary licenses withhold. They differ mainly in which freedom is protected when the software is passed on.

The GPL attempts to preserve a commons. A recipient may use, inspect, modify and redistribute the program, but a distributed derivative work must remain available under the corresponding GPL conditions (copyleft, virality). A permissive BSD license makes a different decision: the recipient may also incorporate the code into a closed product, provided that the rather small set of conditions in the license is respected (“do whatever you want, just cite it”).

My own personal preference, especially for hobby projects and research software, is usually the BSD approach. This is not based on the belief that the GPL has failed. Quite the opposite: it has produced some very visible successes. It is based on a different answer to the question of what it means to give software away “for free”.

⚠️ Disclaimer: I am not a lawyer, and this article does not constitute legal advice. It presents a technical and personal interpretation of common software-licensing principles. For concrete licensing decisions or disputes, qualified legal advice should be obtained.

• Two different meanings of freedom
• What the GPL has demonstrably achieved
• When copyleft prevents otherwise useful combinations
• Why a permissive license often fits hobby software
• Academic software has an additional purpose
• The advertising-clause confusion
  • Why GPL projects ask for the advertising clause to be removed
• “Do what you want, but cite correctly”
• Some qualifications
• A preference, not a universal rule
• References

Two different meanings of freedom

The word freedom hides the central disagreement.

Under a permissive license, freedom is primarily granted to the next recipient. The code may be studied, modified, redistributed, sold, embedded into a device or combined with a proprietary program. Few demands are made about what the recipient must do with a larger work constructed around it.

Under the GPL, freedom is treated more collectively and over time. The next recipient is given extensive rights, but is not permitted to distribute a covered derivative under terms which deny the same essential rights to later recipients. The restriction imposed on one distributor is intended to preserve freedom for everyone farther down the chain.

Consequently, it is possible to describe either license family as the freer one, depending on what is being measured:

Question	GPL	BSD-2/BSD-3
May the software be used privately or commercially?	Yes	Yes
May the source be modified privately?	Yes; private changes need not generally be published	Yes
May modified versions be redistributed?	Yes, subject to the GPL’s copyleft conditions	Yes, with notices and disclaimers retained as required
May the code become part of a proprietary derivative?	Generally not when the combined work is covered by the GPL	Yes
Is source availability preserved for downstream recipients of covered distributions?	Yes	No

Calling GPL software “restricting freedom” would therefore be inaccurate. Calling the GPL viral is also rather imprecise, even though the term captures the practical concern many developers have. The GPL does not somehow spread merely because GPL software is installed beside another program, used as a development tool or communicates with independent software in an ordinary way. The difficult questions concern whether code has been copied, adapted, linked or combined into a single derivative work and whether that work is being conveyed to someone else. The exact boundary depends on the technical arrangement, the applicable GPL version and ultimately copyright law.

Nevertheless, copyleft is deliberately reciprocal. That reciprocity is exactly what supporters value and exactly what others may not want to impose.

What the GPL has demonstrably achieved

It would be difficult to discuss this subject without acknowledging what the GPL has accomplished.

The Linksys WRT54G is the conventional and still useful example. Its firmware contained GPL-licensed software (Linux). Once the corresponding licensing obligations were enforced, source code became available and helped enable an unusually productive ecosystem of alternative firmware. The WRT54G and later WRT54GL became useful far beyond the intentions normally associated with a consumer router. OpenWrt, DD-WRT, Tomato and many experimental installations benefited from the opportunity.

This was not an accidental side effect of an open-source license. It was exactly the type of result for which copyleft had been designed. Had the relevant components been available only under a permissive license, publication of the vendor’s changes could not have been demanded merely on the basis of that license.

Similar reasoning applies whenever there is a realistic danger that improvements to a shared foundation will disappear into appliances or proprietary distributions. A compiler, operating-system component, infrastructure platform or other work intended to remain a public commons can be very well served by the GPL. The license is not merely an expression of distrust toward companies, it is a mechanism which prevents any distributor from accepting the common source while withholding covered improvements from its recipients.

For such a goal, the GPL is both coherent and effective.

When copyleft prevents otherwise useful combinations

The same mechanism can also obstruct integration even when all of the software involved is open source. ZFS provides a particularly instructive example.

ZFS originated at Sun and was released as part of OpenSolaris under the Common Development and Distribution License (CDDL). The CDDL is itself an open-source license and a form of file-level copyleft. It requires covered source files and modifications to them to remain available under the CDDL, while permitting them to be used as part of a larger work under different terms.

The Linux kernel, by contrast, is distributed under GPL version 2. The prevailing interpretation is that CDDL-covered ZFS code and the GPLv2-covered Linux kernel cannot simply be distributed as one combined kernel work: the CDDL does not allow its covered code to be relicensed under GPLv2, while GPLv2 does not permit a covered combined work to retain additional incompatible licensing conditions. Neither license supplies a set of terms which satisfies the other.

This is sometimes shortened to the statement that “the GPL would require ZFS to be relicensed.” That conveys the practical obstacle, but it is not quite the legal mechanism. The GPL does not acquire the copyright in ZFS or automatically change its license. Rather, if integration produces a work governed as a whole by GPLv2, distribution would require permissions which the existing CDDL license does not provide. Relicensing the ZFS code under GPL-compatible terms could resolve the conflict, but only the relevant copyright holders could grant that permission. In a mature project with code from many contributors, this is not a trivial option.

FreeBSD could take a different path. Although the FreeBSD base system is not literally composed only of BSD-licensed files, its predominantly permissive licensing does not demand that an integrated kernel component be relicensed under BSD terms. FreeBSDs licensing policy explicitly permits CDDL-licensed ZFS kernel and userland code. ZFS could therefore become a deeply integrated part of FreeBSD while remaining under the CDDL.

ZFS is available on Linux today through OpenZFS, normally as a separately maintained, out-of-tree kernel module rather than code merged into the mainline Linux kernel. Whether particular ways of combining and distributing such a module with Linux are lawful has been debated for years and different distributors have reached different practical conclusions. This makes it unsuitable as a simple claim that “ZFS cannot run on Linux.” What the licensing conflict prevented was the straightforward inclusion and distribution of the CDDL implementation as an ordinary part of the GPLv2 kernel source tree.

This example is useful because no proprietary vendor needs to be introduced. Both sides consist of open-source software, both licenses were intended to protect openness and yet the reciprocal conditions do not compose. The result is duplicated integration work, an out-of-tree compatibility layer and continuing uncertainty for distributors.

It would also be unfair to attribute the entire conflict to one side. The CDDL is not a permissive BSD license; it deliberately keeps covered files under the CDDL. The incompatibility arises from the interaction of two copyleft regimes. Nevertheless, the GPLs whole-work reciprocity makes it considerably harder for a GPL-covered kernel to absorb independently developed code under another open-source license. A permissively licensed host such as FreeBSD can accept such a component without demanding that the component adopt the hosts license.

This is the corresponding cost of the protection illustrated by the WRT54G. Copyleft can force improvements to remain available when compatible code is distributed as part of a covered work. It can also prevent useful open-source components from being combined when their authors selected different, mutually incompatible conditions. Whether the protection is worth that cost depends on the purpose of the project.

Why a permissive license often fits hobby software

A hobby project is frequently published for a simpler reason: something useful was created, and there is no wish to prevent someone else from using it.

In that setting, a reciprocal obligation may exceed the author’s actual intention. If a small numerical routine, device driver, parser, visualization component or microcontroller library is useful inside somebody elses larger project, it may not matter whether that project is open or closed. Use by a small company, inclusion in a commercial instrument or adaptation for an unexpected platform may be welcomed rather than treated as a loss.

The BSD licenses express this position with unusual clarity. Permission is broad. The copyright notice, license conditions and disclaimer must be preserved in the ways specified by the license. BSD-3-Clause additionally prevents the names of the copyright holder and contributors from being used to endorse derived products without permission. Beyond this, the recipient is largely left alone.

This also reduces license-integration problems. Permissively licensed code can be accepted by GPL projects and, in most cases, by proprietary projects. GPL code cannot simply be incorporated into every project whose distribution model is incompatible with copyleft. For a small library whose purpose is maximum adoption, the asymmetry matters.

There is, of course, a downside. A company may take the code, improve it and distribute the result without publishing those improvements. The original author may never receive a patch. This is not an unforeseen loophole in the BSD model; it is the permission which the license intentionally grants.

For my own hobby software, that possibility is usually acceptable. Once the code has been released, another person’s use of it does not remove the original public version. A proprietary derivative may be disappointing, but it does not retroactively make the published code less useful. If preventing closed derivatives is an essential project goal, the GPL should be selected instead. If it is not, imposing that goal merely as a precaution appears unnecessary.

Academic software has an additional purpose

Research software occupies a somewhat different position. It is not only a program but often also part of the method by which a scientific result was obtained. Several goals then become relevant at once:

• results should be reproducible
• methods should be inspectable
• other groups should be able to adapt the implementation
• the origin of ideas and implementations should remain visible
• researchers should receive appropriate scholarly credit
• transfer into teaching, instrumentation and industry should not be obstructed without a reason

A permissive license is a very natural default for these goals. It permits replication and modification without making the licensing of an entire surrounding research system dependent on the chosen component. This matters because academic code is often combined with vendor libraries, laboratory-control software, institutional frameworks and pre-existing tools under many different terms. A small permissively licensed module can travel through this environment more easily than a strongly copyleft component.

It can also move into practice. If an algorithm developed at a university becomes useful in a microscope, a medical-analysis pipeline or an industrial controller, adoption should not necessarily depend on whether the complete product can be released under the GPL. There are cases in which reciprocity is more important than adoption, but this should be an intentional decision rather than an automatic one. This also reflects the idea that products of Universities should be available to the general public since the universities are usually publicly funded.

The BSD model also resembles an important academic convention: work may be taken further, including for purposes the original author did not anticipate, while its origin should not be erased.

The advertising-clause confusion

The commonly used BSD variants are easy to confuse:

• BSD-2-Clause requires preservation of the copyright notice, license conditions and disclaimer in source redistributions and their reproduction in documentation or other materials accompanying binary redistributions.
• BSD-3-Clause adds the non-endorsement condition: the names of the copyright holder and contributors may not be used to promote a derived product without written permission.
• BSD-4-Clause, historically called the original BSD license, additionally contained the advertising clause. Advertising materials mentioning features or use of the software had to display an acknowledgement.

Thus, the license with the advertising clause is the four-clause BSD license, although the advertising requirement itself was numbered clause 3. This is probably the source of much of the confusion. UC Berkeley rescinded that clause for its BSD-licensed code, and the revised three-clause license became the familiar form.

Why GPL projects ask for the advertising clause to be removed

Removal of the advertising clause was not requested only because acknowledgements became inconvenient. It also made BSD-licensed code substantially easier to combine with GPL-covered software.

The important concept is license compatibility. Two programs may each be free and open-source software while their licenses still make it impossible to distribute a derivative work containing both. Every condition of both licenses must be satisfiable at the same time. If one license requires a condition which the other forbids distributors from imposing, broad permission in each license considered separately does not solve the conflict.

GPLv2 illustrates this directly. Section 6 says that a distributor may not impose further restrictions on a recipient’s exercise of the rights granted by the GPL. A combined derivative distributed under GPLv2 must therefore reach its recipients under the GPL’s conditions without an additional obligation inherited from some incorporated component.

BSD-4-Clause, however, requires advertising materials which mention the software’s features or use to display a specified acknowledgement. This obligation is not present in GPLv2. If BSD-4-Clause code were incorporated into a GPLv2-covered program, a distributor would face incompatible instructions:

• BSD-4-Clause would require the additional advertising acknowledgement;
• GPLv2 would prohibit imposing that additional restriction on downstream redistribution.

Dropping the acknowledgement would violate the BSD license. Retaining it as a mandatory condition would conflict with the GPL. Consequently, the original four-clause BSD license is generally treated as GPL-incompatible even though it is a free-software license.

This explains why developers wishing to reuse such code in GPL projects have often asked copyright holders to remove the advertising clause or grant an appropriate exception. A downstream developer cannot simply delete it from an existing license notice: only the holder of the relevant copyright can offer that code under altered terms. UC Berkeleys rescission resolved the issue for the code to which Berkeley held the applicable rights, but it did not automatically rewrite similar four-clause licenses adopted by unrelated authors.

BSD-3-Clause avoids this conflict. Its ordinary notice-preservation requirements and non-endorsement clause are regarded as compatible with the GPL. Code under BSD-3-Clause can therefore normally be incorporated into a GPL-covered derivative and the resulting combined work distributed under the applicable GPL terms, while the original BSD copyright and license notices remain preserved for the BSD-derived portions.

This is sometimes described loosely as the BSD code becoming GPL. More precisely, the original BSD-licensed code remains available from its copyright holder under BSD terms. The distributor applies the GPL to the combined derivative work and must also preserve the BSD notices associated with the incorporated material. Other people may still obtain the original component under BSD-3-Clause and use it in non-GPL projects. Copyleft governs the distributed combination; it does not retroactively cancel the permissive license already granted by the original author.

GPLv3 contains a more elaborate treatment of certain permitted additional terms, including some forms of attribution and legal-notice preservation. Compatibility analysis can therefore differ between GPL versions and between exact license wordings. The conventional and safest general statement remains that BSD-2-Clause and BSD-3-Clause are GPL-compatible, whereas the original BSD-4-Clause advertising requirement is treated as GPL-incompatible. This is another reason not to revive the historical clause merely to encourage academic citation.

At first sight, the old requirement appears attractive for academic software: do what you want, but acknowledge where it came from. I support that idea.

“Do what you want, but cite correctly”

The desired arrangement can be expressed more effectively as a combination rather than as an unusual software license:

• Release the source under BSD-3-Clause.
• Preserve a clear copyright statement and identify the contributors.
• Add a CITATION.cff file containing the preferred software citation if desired.
• Archive significant releases in a repository which issues a persistent identifier, such as a DOI (Zenodo for example).
• If there is a paper describing the method, state clearly when that paper is the appropriate scholarly reference.
• Keep the citation request separate from the license unless there is a specific legal reason to do otherwise.

This says, in effect: the legal permission to use the software does not depend on performing an academic ritual, but ordinary standards of research integrity still apply. A person who redistributes the code must comply with the BSD license. A person who relies on the software scientifically should cite it because the contribution is relevant to the work, just as methods, datasets and prior results should be cited.

This distinction may initially look weaker because the citation request is not converted into an additional copyright condition. In practice, it is also more accurate. Citations belong in papers because they explain provenance and give credit, not because an advertising clause happened to be triggered. When a use is too trivial or remote to warrant scholarly citation, the license notice may still need to be retained in a redistribution. When a scientific result depends critically on the software without redistributing it, citation may be appropriate even though the BSD conditions were never triggered. The two systems cover different relations.

Some qualifications

No short license comparison can settle every concrete case. In particular, GPL is a family of licenses and versions and linking or combination questions can become legally and technically complicated. The Affero GPL adds network-use provisions which ordinary GPL versions do not contain. Merely operating a modified GPL program as a service does not generally create the same source-provision obligation as distributing it; this is one reason the AGPL exists.

The BSD licenses also do not solve every problem. Their short texts contain no express patent grant comparable to that in Apache License 2.0. For projects in patent-sensitive fields, Apache-2.0 may therefore be a better permissive choice. University ownership policies, employment agreements, third-party dependencies, export controls, personal data and ethical restrictions can impose additional constraints which cannot be removed by selecting a license template.

Finally, an author can license only rights which the author actually controls. Code copied or derived from other projects remains subject to their licenses.

These are reasons to inspect the concrete project, not reasons to leave it without a license. _Without a license, publication of source code does not ordinarily give everybody a general right to modify and redistribute it. “Available on the Internet” and “open source” are not equivalent.

A preference, not a universal rule

For most hobby applications and much academic software, I prefer BSD-3-Clause. It grants the broadest practical scope to whoever receives the work, creates few compatibility obstacles and leaves later applications - open, commercial or otherwise - to the people building them. Together with explicit citation metadata, it also fits the academic principle that work may be reused freely while its origin remains properly documented.

This preference does not require the GPL to be portrayed as hostile or obsolete. The GPL protects a different and legitimate objective: a body of software which cannot be made proprietary by its distributors. The history of the WRT54G demonstrates why that mechanism can matter. If preserving an open commons is the primary purpose of a project, copyleft may be the best fitting license choice.

If the primary purpose is instead to place a tool into the world with as few restrictions as reasonably possible, a BSD license is closer to the intended gift.

The relevant question is therefore not simply which license is freer. It is which freedom the author intends to preserve: the recipients freedom to do almost anything with the code, or the later recipients freedom to receive covered derivatives under the same open terms.

References

• The 3-Clause BSD License
• GNU General Public License, version 2
• GNU General Public License, version 3
• Various Licenses and Comments about Them
• Amendment of the 4-Clause BSD Software License
• Common Development and Distribution License 1.1
• FreeBSD Licensing Policy
• OpenZFS
• Andrew Morin, A Quick Guide to Software Licensing for the Scientist-Programmer
• University of Cambridge Open Research: Licensing software and code

This article is tagged: