Blog | Lex Pan Law

At Copyleft Conf 2019, I did a presentation under the provocative title "Extreme Copyleft, Boon or Bane?"

The main point of the presentation was to look at current hot issues in license drafting, that were roiling around the FOSS world both inside and outside the OSI's license approval process. As a thought experiment, I posited an "Extreme Copyleft Public License" (ECPL), representing the potential end state of copyleft licenses (no, APGLv3 isn't the end state). In summary, a license that says "all your code are belong to us" (to the extent that is possible under any intellectual property regime under which the license is exercised).

It was an interesting thought experiment (and pointed out that the *GPL family of licenses have plenty of carve-outs that, if one were so inclined, could be plugged), although at least one person in the audience (I think Harald Welte) pointed out a drafting error in my proposal (it didn't obligate you to reuse the license -- oops).

Well, Extreme Copyleft seems to still be a matter of interest; there's a presentation at State of the Source* next month on the topic. Perhaps a call for the ECPL to be submitted to the OSI and for all to adopt it? [That's sarcasm; when I posited the license, I said it was a thought experiment and I doubt anyone would want to use it or code licensed under it.]

There was some ancillary discussion in the presentation, and in the questions afterward, about license experimentation and license proliferation; on the former, I was pro (even pro failed experiments), on the latter, neutral to anti, depending on my client. These topics are also becoming a bit hot (at least in the Twitterverse, which doesn't really represent reality), particularly given some of the recently-proposed ethical licenses, the most recent example being the Anti-Capitalist Software License (ACPL?).

It's nice to see people still talking about things I talked about almost 2 years ago (not everything I say is just ephemera!). For those who weren't at my presentation in 2019, I've posted my slides. Note that they are a bit messy, as I had a full-scale laptop brick event on the plane ride over to Brussels, so reconstructing my beautifully constructed and presented pre-flight slides to absolute fidelity was not possible; they may also not be fully self-explanatory (that's what the spoken presentation was for!) but readers may be able to get the drift.

*Lex Pan Law is a watch party sponsor of State of the Source, but had no involvement in the proposing or approving of this session. I was just a fortunate happenstance.

On the USA’s Independence Day, 2020, the Open Source Initiative posted an announcement about the formation of at least one new committee to examine the current list of OSI-approved open source licenses. As at least initially presented, this committee does not have specific outcomes it is expected to achieve, although the announcement indicates that the committee might very well:

· Reevaluat[e] the criteria for approving licenses, potentially setting different standards for licenses in use versus new licenses

· Reevaluat[e] the process for considering licenses for approval, including whether the OSI should itself nominate licenses for approval

· Reevaluat[e] the current categories for licenses, including how they are used and their usefulness

· Evaluat[e] whether there should be a process for decertifying licenses, and what the process and standards would be for the process

For those unfamiliar with the long (now 20 year) history of the OSI and the long-standing debate about the issue of “license proliferation,” the formation of this committee looks to be directed to tackling that issue – at least in part – for the second time. In 2004-2006, this issue was raised – and a committee was formed – to look into the ever-increasing number of licenses being submitted and approved by the OSI. At the time this committee was formed in 2004, there were about 50 OSI-approved open source licenses; today, in 2020, there are over one hundred.

I was a member of the 2004-2006 committee, and the history of that committee, its deliberations, its initial conclusions, and the ultimate report accepted and published by the OSI, would make a fascinating historical study (or oral history). Many of the people on the committee are still around and active in open source (or open source adjacent) activities, although a few of the participants have disengaged – sometimes in rather public ways – from the OSI and its activities.

Whether “license proliferation” is a problem is one I’ve been of two minds of over the years. When I joined the license proliferation committee in 2004, it seemed like a problem that really needed to be tackled (and I personally felt the end result of that committee’s work didn’t adequately tackle the issue). As more and more initiatives were put in place within the tech industry – OpenChain, SPDX, REUSE, and the Linux Foundation’s efforts to create an industry-developed Automated Compliance Tooling – the proliferation “problem” seemed like one that could be soluble using technology. For larger companies who have the resources to commit to developing a robust Open Source Program Office (OSPO), this very well may be the case. But for smaller companies without an OSPO or struggling to set them up, seeing an OSI-approved list of over 100 different licenses can be quite daunting.

It is not just the license list and the process for approving licenses that may ultimately be reviewed by the OSI – they have also indicated that:

"This Working Group will not be investigating or evaluating whether the Open Source Definition should be revised. That project is likely to require a different assortment of participants than this proposed Working Group, so a review of the OSD is more appropriately undertaken separately."

I have been on record – and in fact made it a part of my (unsuccessful) candidacy for the OSI Board earlier in 2020 – as saying that the OSI ought to relook at not only the license approval process, and the full list of licenses that have been approved – but the Open Source Definition itself. As a personal matter, I’m pleased to see the OSI look into tackling these questions (or tackling them again), as in the 15 years since the License Proliferation Committee upon which I sat, much has changed, much has been learned, and the fundamental understandings of what are and aren’t “open source” licenses are being tested as never before. It will be healthy for the OSI to reexamine some of the language currently in the OSD – which contains certain ambiguities, in my opinion, that has caused frustrations for some license submitters – as well as the current list of licenses – to see if some of the assumptions that were made in approving them may no longer be operative anymore.

For those of you who work with these licenses frequently – as developers, attorneys, or businesspeople – I encourage you to support this effort by the OSI, and if you are so inclined, to volunteer for the committee (or committees) being formed to confront these fundamental questions.

®

GPLv3's "Installation Information" Requirement

Extreme Copyleft, Redux

License Proliferation (And the OSD?) Revisited