Toward Copyleft Equality for All | Hacker News Reader

Toward Copyleft Equality for All

sfconservancy.org

87 pointspabs346 comments

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.

I've reread Kuhn's piece several times. It's that unfortunate mix of tantalising and unclear.

My understanding is that it's not the dual-licensing per se that's toxic, but the goal of copyleft-noncompliance legal actions. Rather than, as the FSF and SFC seek: "Our primary goal in GPL enforcement is to bring about GPL compliance." (https://sfconservancy.org/copyleft-compliance/principles.htm...) The businesses of which Kuhn is critical seek instead "to 'convert' those FOSS users into paying customers for proprietary licensing for the same codebase."

Arguably, the failure here might be of the GPL failing to specify what is an acceptable remedy, though if that were defanged to only be "release affected code as <copyleft license>", it might afford too great a latitude to other forms of black-hat actors.

I'm not sure if I agree with Kuhn's assessments or remedies. I think the discussion's worth having, and appreciate your input.

Agreed. Copyleft Free software with an option to purchase a non-copyleft license exception is strictly better than proprietary software, which in many cases is the only realistic alternative. If there's something immoral about selling these exceptions then it's also immoral to release software under permissive Free licenses, which is a very unusual belief.

RMS discusses this here:

https://www.gnu.org/philosophy/selling-exceptions.html

"I consider selling exceptions an acceptable thing for a company to do, and I will suggest it where appropriate as a way to get programs freed."

If you wish for a dissenting opinion on the MongoDB, I enjoy the writing of Kyle Mitchel at /dev/lawyer

https://writing.kemitchell.com/series/SSPL.html

Kyle is a advocate of dual licensing ("selling exceptions") and has even created License Zero [1] which is attempting to allow the creation of npm libraries which are dual licensed and an automatic command line tool to pay developers.

[1]: https://licensezero.com/ see also https://writing.kemitchell.com/2017/09/12/The-License-Zero-M...

Except Kyle misleadingly calls his licenses open source when they aren't. Prosperity discriminates between commercial and non-commercial organizations rather than on how the code is used. He should stop muddying the waters.

I've never called Prosperity, the noncommercial license, open source. I've called Parity open source.

None of the URL fragments on https://licensezero.com/licenses/parity actually work. Your <h2>s don't have ids.

> 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.

> It is the big party using their power to get developers to give up their rights.

Sometimes that big party is a single developer, or just a small group. They invest several years into developing a working product, unpaid, and then give it away, with the condition that anybody who wants to use it in a proprietary product must pay up.

Not all CLAs require a developer to "give up their rights." The code authors can retain their copyright, but sign an irrevocable contract which allows for the distributor to re-license their work as they see fit. The original author too, is still able to license it as they see fit.

If, on the other hand, the developers only release their work as AGPL with no separate licensing, all they are doing is ensuring that a subset of companies who might otherwise use their software, definitely wont. There are many companies who simply can't AGPL their own works and if they can't use your software, they'll find an alternative, or develop and alternative in house.

I'm certainly against the idea of coercing companies to pay for licenses by instilling fear, but I think it's only a subset of dual licensing companies which do this. A dual licensing approach isn't inherently coercive. If they're clear about their licensing model up-front then it shouldn't be an issue.

Also consider that at any point, you can take one of these AGPL dual licensed products, fork it, and not sign over any CLA, then you can distribute a fully copy-left variant of it with some additions of your own. You would question why wouldn't everyone contribute to your version rather than the one where they hand over the copyright of their modifications. There's an obvious reason this rarely happens: The bulk of the work and maintenance is being done by the company collecting the license fees, and community contributions are just a small percent. There are cases where the community version gets enough development effort to be able to spin off a successful fork - eg, MariaDB.

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.

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.

But all this doesn't leave contributors without any rights: they can still decide to band together and fork the whole thing. Even after signing CLAs and having contributed to the original codebase for a while.

If this story is true, it definitely sounds shady to me:

"This problem became clear to me in mid-2003 when MySQL AB attempted to hire me as a consultant. I was financially in need of supplementary income so I seriously considered taking the work, but the initial conference call felt surreal and convinced me that MySQL AB was engaging in problematic behavior . Specifically, their goal was to develop scare tactics regarding the GPLv2."

I think this refers to the attempt of MySQL AB to invent "internal distribution" so where if you have proprietary software which you might be distributing from one department to another in the same company you can't do that with GPL2 and need to buy the proprietary version

I always wondered if an employee could make a GPL source request to their employer. Is there any more reading about any of these events or legal theory? I'm having difficulty Googling this.

No, GPL opts out from such distribution channels. https://www.gnu.org/licenses/gpl-faq.html#InternalDistributi...

> But CLAs aren't coercive

CLAs are frequently coercive, rights depriving and generally a bad move, and I as a FOSS contributor won't sign them.

Yes, occasionally they are used correctly - but more often than not they're used to crowdsource work on what is really a proprietary codebase with crazy potential restrictions if the owning company decides to call them in.

I want to be clear that I think CLAs can be a bad idea for contributors and people should think carefully before signing them. But since the AGPL doesn't obligate you to sign a CLA, I don't see how the existence of CLAs is an indictment of the AGPL or of dual-licensed business models. It's my belief that most dual-licensed software wouldn't be open sourced at all (and a lot of it wouldn't exist at all) without the dual-license model that Kuhn opposes.

I agree.

To me the GPL is clear: You can USE the software for anything, but you have legal responsibilities if you redistribute it.

The dual license scheme seems like a good way of letting people buy their way out of the responsibility part, and generating revenue to help maintain the software.

In addition, I'm not sure using MySQL as an example makes a whole lot of sense. After all, that project was forked and the 'freer' alternative won out, so said 'seedy' behavior wasn't really a winning strategy. Or, at least, the community isn't worse of, from today's standpoint.

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-... https://old.reddit.com/r/QtFramework/comments/e9376a/trouble... https://news.ycombinator.com/item?id=21755337

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

Do I understand that feature correctly that, because it's not a limitation on user rights but a pledge by the author, it can be added to any copyleft license without becoming incompatible to the base license or making the result a non-free license?

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

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

http://www.olafsw.de/a-better-qt-because-of-open-source-and-...

> 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.

>Why would anyone choose this?

It's about clear communication of a commitment to users and licensees. It's about building trust, and hence strengthening and broadening the community around the software.

I licensor can know that they never intend to re-license code commercially, but their users and licensees can't know that in the same way. Without a clause like this have to take that on trust and some might choose not to do that, missing out and weakening the adoption of the code and it's community. The presence of a clear commitments avoids that problem.

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.

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.

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..?

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.

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.

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

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".

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.

You are not locked into a particular proprietary service provider. So with the Affero license in principle you get the following benefits:

* You know what code is providing your services.

* You have the option to run that code yourself.

* Other service providers can provide the same service using the same code, so you're not locked in.

Isn't the point that you can modify and deploy a copy on your own infrastructure?

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.

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.

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.

> 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.

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).

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...

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.

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.

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.

Reply on news.ycombinator.com