
Toward Copyleft Equality for All - pabs3
https://sfconservancy.org/blog/2020/jan/06/copyleft-equality/
======
tptacek
The premise of this post is that dual-licensing --- offering a piece of
serverside or on-prem commercial software under (A)GPL terms, with a
proprietary license available for firms that want unrestricted usage --- is
"seedy". It's not clear to me how that premise is justified, and Kuhn's claim
that the model has failed to increase software freedom seems totally
unjustified.

At the heart of Kuhn's argument about "seediness" seems to be CLAs, which is
where a third-party developer using software under FOSS terms is asked to sign
the rights to their modifications over to the original vendor. If CLAs were
coercive, this would indeed be seedy: FOSS developers would be getting baited
into contributing to commercial products. But CLAs aren't coercive; the AGPL
requires only that you meet the requirements of the license itself, not that
you sign away your rights to your own modifications. People sign CLAs because
they want their modifications upstreamed, and to avoid maintaining forks, not
because they're legally required to do so.

Meanwhile, the kinds of software we talk about when we talk about the AGPL are
overwhelmingly things that used to be (and in some cases in large part still
are) closed source proprietary products. It's a little hard to imagine a
closed source distributed database taking off in 2020; 20-30 years ago, to use
Kuhn's framing, the opposite statement would have been more valid.

Fundamentally, software offered under the AGPL is almost always developed
under the model of a single commercial vendor doing most of the heavy lifting,
and, usually, all of the initial lift in getting a piece of software to the
point of viability. It's hard to see how these vendors are taking something
from the community by releasing their products under the AGPL when their
alternatives would certainly be either a fully closed-source proprietary
release, or no release at all. Kuhn writes as if licensing and advocacy
decisions determine the economics of software development, but if the last 30
years has been an experiment conclusively demonstrating anything, it's that
--- at least for the kinds of serverside code we're talking about --- no
matter how you license it, companies paying software developers are what gets
software built.

I have strong opinions only about the AGPL; I don't pretend to fully
understand the ramifications of MongoDB's SS GPL, nor do I support the SS GPL
unreservedly.

~~~
rocqua
> People sign CLAs because they want their modifications upstreamed, and to
> avoid maintaining forks, not because they're legally required to do so.

This is still coercive though. It is the big party using their power to get
developers to give up their rights.

Notably, by giving up these rights, it becomes possible for the party to go
against the FOSS principles that were the reason copy-left was invented.

~~~
m4rtink
Also, CLAs are yet another stumbling block for contributors. Many people that
could easily contribute to a regular GPL/BSD project per company guidelines
might be prevented from doing by the need to effectively sign a contract or
might need to involve comapny legal department.

~~~
tptacek
Remember the context here. Yes, commercially-owned AGPL projects that require
CLAs are not especially easy to contribute to. FOSS projects can be more or
less easy to contribute to for lots of reasons, and most of those reasons
aren't "seedy". I'd argue that in most cases, the CLA case isn't "seedy"
either: the commercial sponsor funds most of the work; the project isn't an
elaborate scheme to get free dev cycles from the community, but rather trades
access to code (and the potential for a hostile fork) for greater adoption.
That seems like a trade that Kuhn should welcome.

------
pabs3
This reminded me of the agreement between Qt and KDE, where if Qt is ever made
proprietary, KDE can publish Qt under the BSD license:

[http://www.olafsw.de/a-better-qt-because-of-open-source-
and-...](http://www.olafsw.de/a-better-qt-because-of-open-source-and-kde/)
[https://old.reddit.com/r/QtFramework/comments/e9376a/trouble...](https://old.reddit.com/r/QtFramework/comments/e9376a/troublesome_development_about_relicensing_qt/)
[https://news.ycombinator.com/item?id=21755337](https://news.ycombinator.com/item?id=21755337)

~~~
richardfontana
Indeed that Qt-KDE "treaty" was an inspiration for the feature of copyleft-
next that bkuhn lauds in this article.

~~~
kemitchell
Any additional reading on the Qt-KDE treaty that you would recommend?

~~~
rrix2
[https://kde.org/community/whatiskde/kdefreeqtfoundation.php](https://kde.org/community/whatiskde/kdefreeqtfoundation.php)

[http://www.olafsw.de/a-better-qt-because-of-open-source-
and-...](http://www.olafsw.de/a-better-qt-because-of-open-source-and-kde/)

------
kazinator
> _The essence in non-legalese is this: If you offer a license that isn 't a
> copyleft license, the copyleft provisions collapse and the software is now
> available to all under a non-copyleft, hyper-permissive FOSS license._

Why would anyone choose this?

It must be for the sake of giving the downstream users some sort of assurance
that a Bad Thing won't happen to them, as a sort of promise.

"If we ever commercialize this, we will give all of you the opportunity to do
the same."

It seems that the only authors for whom it would make sense to choosing this
license would be authors who have no intention of going mixed proprietary
licensing now, or in the future. Moreover, authors who believe in copyleft
FOSS licenses and want to keep the project that way.

Someone who chooses that license knowing they will likely issue proprietary
versions might as well skip straight to a simpler BSD-style license that is
implied in that action.

Someone who doesn't believe in copyleft FOSS would also just skip this sort of
thing and give the users the "hyper-permissive" license.

No matter what promises a copyright holder makes, they can retract them.
However, at least this will be in force for users who hold existing copies. So
that is to say, if the authors decide to commercialize and switch to Affero
GPL, then only the new issues of the software going forward will be bound by
that AGPL; the existing users will have the "hyper-permissive" license for the
code up to that point.

~~~
fourthark
I am guessing that now the software can’t be included in something else that
uses “predatory copyleft“.

And those derivative works do not have the option to use a less restrictive
license that allows such behavior.

Not sure of this though.

~~~
kazinator
Ah, good thinking.

But is that true? Basically, the license is copyleft now, but if certain
conditions occur in the future, it will become BSD-like (let's go with that
designation for familiarity).

Thus, the license is effectively (copyleft | BSD).

A project which uses regular old predatory copyleft can therefore use it now
and continue to use it, whichever way it plays out.

~~~
fourthark
Confusing. I’ll be interested to see this explained to mortals.

But I would assume that derived works could not choose to use the code as BSD
- it’s not “choice of copyleft or BSD” it’s “copyleft unless you try to do
something shady.”

Somehow..?

------
dredmorbius
Two standout points from this essay:

1\. I've long heard that various SaaS companies _really didn 't like_ the
Affero General Public License. Kuhn makes a case for why this is a validly
justified concern, something I'd not previously considered.

2\. The copyleft restriction termination is a _really_ interesting concept,
though not without its own set of consequences which should be closely
examined. Historically, the advantage of copyleft has been that it applies
equally to all. The abuse of it (by firms also marketing properietary
solutions) is a problem, but removing copyleft obligations entirely might not
go as intended.

3\. Copyright assignments to copylefted codebases without an explicit
restriction of those to require copyleft-only usage, a distinction which
differentiates strongly between the uses at, say, FSF vs. MySQL AG / Oracle,
clearly also present issues, as has long been argued.

~~~
kazinator
That Affero license doesn't seem very useful, because if you depend on code
running on someone else's server, it doesn't help you if you have an honest
copy of the source code that is actually running on it. You still don't
control it. You can't make changes and deploy it to that server, or update it
yourself, etc..

Free, open-source software is about control: controlling what code manipulates
your data.

In short, it seems that the license really doesn't really do much of substance
for the user, and just saddles the operator with extra burdens.

~~~
dredmorbius
The Affero license gives you _precisely_ the rights to the _code_. No, it
doesn't give you rights to the _server_ the code runs on, but you can spin up
your own server (often little more than a RaPi box, possibly more at scale),
avoiding lock-in based on software alone.

But it obliges you to provide or make available those changes if the use will
"propogate" the work.

[https://www.gnu.org/licenses/agpl-3.0.en.html](https://www.gnu.org/licenses/agpl-3.0.en.html)

~~~
kazinator
If I spin my own server, why would I care what anyone else has done with their
server, code-wise? Does everyone in the world who has publicly installed that
server owe me a copy of their source code, even if what I run and use is
strictly my own server built from the upstream code?

By the way, the AGPL3 definition of "propagate" looks exactly the same as that
of the the regular GPL3. Operating software as a server doesn't fall under
"propagate".

~~~
dredmorbius
If you're _competing_ with a service, it means that you're not going to suffer
disadvantage based on the coding / development capabilities of your
competitor. What they produce is going to be something that's available to
your own deployment.

For self-service, this means that you're not locked out of the development
capabilities of the service you've left -- though that arguably creates a
free-rider problem for that service.

------
zeveb
I believe that this is arguing from a false premise: the reason that companies
despise the AGPL is not, I think, that they fear that they fear accidentally
violating copyleft and thus being forced to buy a proprietary license but
rather than they simply want to have their cake and eat it too: copyleft for
thee but not for me. They want to use software for free but not grant the
rights they received to their own users.

Thus a provision reverting to a BSD-style license in case of proprietary
licensing would, I believe, do nothing to encourage them to use it in the
first place.

~~~
singron
In my experience, the copyleft provisions of the AGPL are misunderstood by
just about everyone to be much more viral than they really are. E.g. "if there
is some AGPL software on a workstation or server, we might have to release all
source code in the company!"

I wouldn't be surprised if MongoDB has been spreading FUD for years to cause
this.

~~~
munk-a
I agree with this, AGPL is aimed to be comprehensible in its permissiveness,
but most folks don't know AGPL from GPL and, even with AGPL, there are ways to
have infectious copy-left licensing if the raw binaries are directly linked
into an application.

------
yarrel
> The toxicity of this business model has only become apparent in hindsight.

I'm glad that Bradley is drawing critical attention to this issue.

> efforts to draft even more restrictive software copyleft licenses

A non-free "copyleft" license is not worthy of the name and is a problem
because it is non-free, not because of "copyleft".

> The clause still needs work

The _license_ needs work,it seems to treat copyleft as a form of punishment
for authors to be tolerated for a while rather than as a strategy to
permanently protect the freedom of all software users.

> a basic approach to incorporating similar copyleft equality clauses into
> written exceptions for existing copyleft licenses, such as the Affero GPL

These clauses can and will be removed by downstream users for any alterations
or additions they make to the software in order to provide it to their cloud-
based users. This will redouble the downstream use dynamics that VC-funded
"open source" projects, some of the heaviest users of abusive CLAs, whine
about.

~~~
kazinator
Downstream users cannot remove clauses put in place by the copyright holder,
even for alterations that they make, because those are derived works. A pure
addition that you make to a copylefted program is your copyright; you have to
license it in a way which is compatible with that program, but otherwise it
can be anything. E.g. you can add 2-Clause-BSD-licensed code to a GPL-ed
program and then redistribute that to your own downstream users. The GPL still
applies to the thing as a whole; users can use just your portion alone under
its BSD license (like borrow the code into another program).

------
_frkl
I'm torn. On one side I do like this idea, on the other hand I don't see a
practical way to work on exploratory open source software in some areas where
your effort (even if it actually ends up delivering value to somebody) will be
rewarded adequately. The existing models (open core, support contracts,
donations, ...) may work here and there (although some of those would be
invalidated by this suggestion), but compared to a traditional strategy just
writing proprietary code it's quite a bit more difficult to make money. And I
reckon that is difficult enough as it is...

~~~
shmerl
I don't think anyone suggested that it should be easy to make money that way.
It was and likely will always be more difficult. Which doesn't mean it
shouldn't be done.

~~~
_frkl
Of course nobody suggested that, that's far off the point I was trying to
make. If it's harder to do, less people will do it. Whereas I'd like the
opposite to happen. If you take away the option to dual-license, it becomes
harder still.

------
v7x
I see a few comments in here, and have seen similar comments in similar topics
in other threads, saying that they dont understand why anyone would choose
this over other FOSS licenses. These questions are asked from a developer-
centric perspective. FOSS never has been, and never will be, developer-
centric. Free as in freedom software was created to be USER-centric. The whole
point is to take power AWAY from the developer, because otherwise the balance
is always in the developer's favor. The benefit for the developer is that
developers are also users, so they in turn benefit from others releasing the
software as FOSS, both as libraries to write better software with and as
programs used in day to day computing.

Any issues companies have with FOSS licenses is entirely on them, assuming
they arent one of the few who actively contributes to and fights for FOSS.
MongoDB doesn't like competition from Amazon? Understandable. But don't play
the victim and then turn around and screw everyone who isn't Amazon over with
a license change. Maybe instead you could take some of your shake-down money
and put it to good use by lobbying against these monopolistic conglomarates in
the valley so that they can't use their overreaching power to screw you with
your own code. Maybe instead, you could encourage ALL developers to start
using copyleft licenses, instead of the weaker licenses everyone loves to
throw on their project these days. Because those weaker licenses are somewhat
to blame for this too. What good is a FOSS program if its just going to lead
to more proprietary software? How does that help anyone? There's a reason most
of the big tech monopolies release most of the open source code they do
produce under non-copyleft licenses. Its not because they love FOSS, its so
that they can pay lip service to the community and then use it with their the
proprietary programs we're so concerned about them surveiling us with. Of
course, the retort to all of this is "developers need to eat to, how can we
make money off of copyleft?" I have two answers, one thats snarky but possibly
helpful and one that's honest but possibly rude, and hopefully enlightening.
The first answer is "Ask Qt." "Ask Blender." "Ask Redhat." Ask one of the many
companies that do buisiness while still releasing their main software under a
FOSS license. They all seem to be doing pretty well. The second answer is that
I don't care how or even if you make money. Thats not the reason you release
something as FOSS. Never has been, never will be. If you release software as
FOSS, its because you believe that there should be a balance of power between
developers and users. Its because you believe that sharing information and
knowledge is the best way we can improve quality of life for ourselves and
those around us. If you can't make those ideals your biggest priority even in
the face of financial loss, frankly don't even bother releasing your software
as FOSS. I'd rather your software be proprietary. That way I'll know to avoid
it and we won't have to waste eachothers time.

