Dirk Riehle's Industry and Research Publications

An Analysis of Copyleft Compliance Behavior

It is the year 2020 and my Twitterverse and other professional time sinks are still full of … comments about Copyleft. So for the first time ever, I decided to venture into that pit. I see four observable behaviors when it comes to complying with copyleft.

  • Kickin’ and screamin’
  • No use
  • Dump and run
  • Enlightened self-interest

The Copyleft obligation

First things first: Copyleft is a particular obligation of (open source) software licenses that requires the recipient of so-licensed software to lay open any modifications (under the same license that came with the original source code) when passing on that software.

The moral thrust of this obligation, according to its creator and proponents, is to “free software” so that any recipient (user) can help themselves if something goes wrong.

For many years, Microsoft and other companies called copyleft licenses “viral” and “socialist” that were out “to destroy” the software industry. I think it is safe to say that this “fear, uncertainty, and doubt” (“FUD”) campaign stalled the progress of open source significantly.

Kickin’ and screamin’

And indeed, there are companies who use copyleft-licensed code in their products and who do not comply with the obligation. Usually, this happens by accident, sometimes by deliberate neglect. If this becomes known, the companies may find themselves in court.

The companies are being dragged towards license compliance, “kickin’ and screamin’” because they don’t want to.

The Software Freedom Conservancy (SFC) is now the leading institution that has taken it upon itself to enforce copyleft, usually around the Linux kernel. The SFC pools money and represents developers whose rights have not been observed.

Beyond this, I particularly applaud the grace period that companies in violation of license obligations are now given to fix the issue. It shows that enforcing copyleft is not about shaking down companies but rather about maintaining developer rights.

No use

In general though, once a company wises up on open source licensing, code with a copyleft license gets blacklisted, and that’s the end of it. Then, complying with copyleft is simple, because the company doesn’t have to.

Due to some important projects, most notably the Linux kernel, special situations (like kernel drivers) remain, but don’t constitute the bulk of problems.

Dump and run

There is still a lot of useful code available under the once dominant GPLv2, the leading copyleft license. As a consequence, despite black-listing GPLv2 and similar, companies sometimes can’t avoid using so-licensed code in their products. They then have to comply with the copyleft obligation.

This leads to a dump (of the modifications, if any) and run. The company which must open source their modifications, does so only unwillingly. This can be seen in the excruciatingly detailed instructions in the GPLv3 license, which are trying to prevent any workarounds that an engineer at the unwilling company might dream up to prevent actual use of the laid-open code.

The unwilling company will not cooperate with the underlying open source project and will definitely not try to put in the extra effort of contributing any modifications back to the original project. Rather, it will simply put their code onto some remote place on their website or use one of the official graveyards created for this purpose.

Enlightened self-interest

Sometimes, however, business model permitting, using copyleft licensed code in a product does not create problems for a company. Once a company realizes this, they usually come around and start to manage their dependency on the open source project. In practice, this means that a developer is tasked with monitoring the project.

They will also start to contribute any minor (or major) fixes the company might have created for the project, and if only to reduce the maintenance burden of repeatedly patching new versions of a component with their internal bug fixes.

This is called participation and contribution out of “enlightened self-interest”. Companies are helping themselves by helping others.


The irony of it? Quality contributions to an open source project don’t need a copleft obligation; they happen by themselves out of enlightened self-interest of the participating parties.

As an educator, this warms my heart.

Newsletter subscription


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Share the joy

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes collaborative qualitative data analysis fun and easy.
EDITIVE makes document collaboration more effective.

Featured projects

Making free and open data easy, safe, and reliable to use
Bringing business intelligence to engineering management
Making open source in products easy, safe, and fun to use