Reciprocity means a mutual or cooperative interchange of favors or privileges. Something is reciprocal when it is performed, experienced, or felt by both sides. (The American Heritage Dictionary of the English Language, 4th edition.)

The GPL license is reciprocal, because it is “performed, experienced, or felt” by both sides—the licensor and the licensees both use the GPL.

In non-legal terms, I'd put this as "the GPL allows you to redistribute in kind: by extending the offer the original licensor made to others." The "price" of redistribution is agreeing to public participation in the co-evolution of the software.

This is not to be confused with Artifex's offer to dual-license: you may either accept the terms of the GPL or purchase a commercial license. These two worlds do not interact other than Artifex, the copyright holder, uses its rights under copyright law to offer these two alternatives.

With respect to the book chapter, as I interpret it, reciprocity includes asking for the licensee to open source their work. But I leave this to the experts to interpret definitively.

Assuming I am not misunderstanding, if the licensee "reciprocates", then there is no closed source and the "problem" I am alluding to goes away. Because users can now see the source code and theoretically they can determine where it came from.

(The problem being that GPL source code and the value thereof is sometimes "concealed" in closed source products. This is just my personal view. I may care about things that others do not. Opinions may differ.)

The Affero GPL tries to close that loophole.

If I copy GPL-licensed code without following the license terms, the GPL no longer applies and the code becomes unlicensed. The GPL is explicit about that.

If I acquire code under another license than the GPL my copy is not GPL-licensed even if it's available under the GPL license. Ultimately, the GPL requires that all people who pass on code under the GPL adhere to its terms. If one person in the chain didn't (for example by not making available the source) all subsequent copies become unlicensed.

So while writing this comment I remembered the old case of QT and found this article (https://www.fsf.org/blogs/rms/selling-exceptions). To quote it similar to a "inferior choice, but it's not wrong".

You can legally do this, but it will not be easy. You cannot distribute a binary in this way, if you do your patch becomes GPL so the first person who buys your patch can legally give it to everyone else. That means you have to sell the source code to your patch and your customers have to build the binary themselves. You need to ensure that your customers understand that they cannot distribute any binaries they make. (they probably can distribute it within their company but they need to have some process to ensure that their employees know they cannot distribute this)

If anyone is thinking about this, make sure all sales include your lawyer: you will need to ensure that your customer understands all the subtleties otherwise the courts might decide your patch is GPL.

A patch is a derivative work, no matter how you try to dodge that part of the law. So it would still be violation of copyright.

For example, the original work might be very valuable, a significant work. It could be the collective work of many authors. But it has been made available for free. The derivative work, maybe patches or some additional source code by a single author, is also valuable but on its own much less so.

Then the large original work is packaged together with the patches and additonal source code as a "derivative work". It is commercially licensed to an end user who sees the value as a whole, most of it coming from the original work, which of course was available for free.

Depending on whether attribution is given, the user may have no idea that the core of the product was open source and available for free.

More importantly, there appears to be no assessment of the relative "value" of the free portion versus the closed-source commercial portion of the product.

(Edited to add the last statement above, for clarity.)

Absolutely you can sell, but your can't restrict user rights

I've often thought that this was a pretty ideal way of licensing OSS.

It provides a revenue stream for improving upon open source from those with the deepest pockets and the greatest ability to pay which clearly works (QT, for instance, probably wouldn't exist without this model).

Moreover, it doesn't remove others' freedom to be able to develop free software from it.

It's telling that the biggest whinges about the GPL often come from large (often abusive) corporations with deep pockets, an inflated sense of entitlement, paranoia about "their" intellectual property and a desire to get freebies from ordinary developers.

As for Stallman's intentions, he's talked about this exact model: https://www.fsf.org/blogs/rms/selling-exceptions

"I've considered selling exceptions acceptable since the 1990s, and on occasion I've suggested it to companies. Sometimes this approach has made it possible for important programs to become free software."

Read his full text for some boundaries he sees.

https://www.fsf.org/blogs/rms/selling-exceptions

It does make sense. It sounds like he's against things like Magento/Gitlab/Alfresco which have totally open source versions and commercial/enterprise versions with closed extensions. (I realize those aren't the best examples as they're not GPL).

With the dual licensed product, you simply have two licenses for the exact same code base. If you want to reuse it, you can, but you need to release your derivative works back to the community. But the people/organisation behind the tools still have to live in this capitalist world that's far from the free software paradise of the FSF. Developing under a dual license can provide a revenue stream back to the writers to help keep that work going.

"Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding. Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license." https://www.gnu.org/philosophy/selling.html

What he cares about is that the software is free as in freedom and contains no lock-in: You can look at it, you can edit it, you can distribute it.

You can sell it, but it's still subject to GPL.

Distribution of binaries is a bit of a diversion here, and not a key issue - it dorsn't really matter if we're talking about C or python.

Nothing is stopping someone from paying the rights owner of a BSD-licensed work for the right to use it without preserving the copyright notice. The analysis is the same as for a GPL-licensed work.

If the argument is that it's better to have BSD-licensed works without paid exceptions than GPL-licensed works with paid exceptions, well... first off, nothing stops the paid exceptions from being "You can use this under the BSD license". Second, this seems like a strategic thing; if most users comply with the GPL, and you raise some money, that seems like a net win compared to everyone complying with the BSD and not providing source despite not paying.

> Assume further that they do not use "interfaces" designed by the GPL source code author.

I'm having a lot of trouble imagining a patch that works this way. If you're patching the program, aren't you interfacing with the program somehow?

I can think of two possible ways. One is that you're actually patching other interfaces (e.g., providing an LD_PRELOAD) provided by more-liberally-licensed software. I don't think that an LD_PRELOAD of POSIX interfaces intended for use with specific GPL software is a derivative work, but I also don't super look forward to convincing my lawyer of what's going on, let alone a judge.

The second is that you're running the program in such a way that you're really wrapping standard I/O and not touching the program itself, but I wouldn't call that a patch. JuiceSSH for Android does this with mosh, for instance; it uses an upstream mosh-client binary (and provides source) in a subprocess of its proprietary UI. On a system like iOS where you can't fork, I could imagine some scheme for running the process in the same address space with some serious emulation. I very much wouldn't look forward to litigating this; it sounds sorta like the VMware lawsuit, which is a huge mess.

If you're providing a plugin through a defined plugin interface, and the software author has said "Use of this plugin interface doesn't subject you to my program's license" (or the plugin interface is an external standard like VST), then you're in the clear. It's worth noting that Linux has an explicit statement that the syscall interface does not subject userspace programs to the GPL. I don't know if such a statement is necessary, but it's nice that it's there. But these sorts of things are definitely not what I think anyone would call a "patch".

It is true the patterns could be excerpts from the GPL work. But they need not be functional or even intelligible as anything other than as part of instructions, e.g., short strings of octal values representing characters, with wildcard characters interspersed.

Patching might even operate by only using line and column numbers. The patch itself in that case need not contain any text from the GPL work. It might be just an index into some file, a list of line numbers and columns and any new text to be inserted.

The point is that the process of patching need not necessarily reveal anything about the original GPL work. The editing could theroretically be done in such a way to make this separation.

Anyway, we have drifted from the original question which was , essentially, why do programmers not distribute instructions on how to modify GPL source code or additional source code that can be linked with GPL source separately from the GPL source code.

The reason I asked is because what I see is that original GPL source code is sometimes "hidden" in commercial products by virtue of being bundled with some "derivative work". To me this obscures the value of the original GPL source code in favor of the closed source derivative work, which may or may not be as valuable. NB The usage of the words value and valuable is purely subjective. Opinions may differ.

I am not sure I understand the comment about BSD licensing. Assume for example that the goal of the license is to require attribution, how does one avoid that requirement without changing the license? The licensor can opt not to enforce the license and may accept payment. But the license still requires what it says.

I think you're misunderstanding how copyright law views works. A "work" in the sense of copyright law isn't a pattern of bits: it's a creative expression of an idea (a binding between a pattern of bits and some concept in a human brain) that has a context for how it came to exist.

The classic article "What Colour are your bits" is a good overview of this: http://ansuz.sooke.bc.ca/entry/23

It's worth reading, to understand exactly what copyright law covers / how it works. But suffice it to say that the ability to create a set of bits that does not include any inherent reference to the GPL'd work does not make the bits no longer a derivative work, any more than Monolith (the example from that article) causes bits to stop being copyrighted.

Which answers your question of why programmers do not distribute instructions on how to modify GPL source code without distributing the source itself: there's no point. The legal requirements on them are exactly the same.

My comment about BSD licensing is that if people who own GPL'd works sometimes accept payment to give you the work without the requirements of the GPL, nothing is stopping people who own BSD-licensed works to accept payment to give you the work without the requirements of the BSD license. If it's a bad thing that you can in theory pay money to avoid the GPL, it's equally a bad thing that you can in theory pay money to avoid the BSD license.

It's clearly a derivative work, as described.

Some don't.

If your customers wanted the source, they would have to ask the original authors to sue you and have the court force you to accept the GPL post-factum. It's not clear how this would turn out because afaik such line of "defense" has never been tried by violators so far. A few such lawsuits settled out of court, usually with source code being part of the deal.

A ruling in this kind of case, where the violator stubbornly refused to comply and maybe tried to escape with just paying damages or some other trickery, that would be interesting.

As you mention, though, some potential defendants will determine it's just cheaper to just disclose the modified code and walk away.

And yes, if you refuse source to your customers that's where you are - software copyright violation. Just the same as if you did this with proprietary stuff. Someone with standing would have to start the ball rolling.

The GPL does place nontechnical restrictions on developers, but those restrictions exist to ensure that bad actors can't add new restrictions to users.

But seriously, "GPL is DRM" makes no sense. Aside from the fact that DRM and the GPL are completely different classes of things, they also have completely contradictory philosophies and are applied and act in completely contradictory ways. That's just FUD.

Nothing stops anyone from charging for the GPL code in the first place.

But the idea I had in mind with this question was that there is often an initial free source of high value code and then someone may add an addtional amount of their own code that is by comparison far less valuable.

The end user of the commercial product if it is closed source may not be able to see the extent of the contribution of that free portion to the value of the product as a whole.

For lack of a better hypothetical, imagine a product that is a combination of 1. GPL licensed command line executable that anyone can download and compile for no charge and 2. a GUI "skin" written by someone who has no copyright in the command line executable.

The author of the skin, let's call him "the entrepreneur", wants to charge end users.

The entrepreneur packages his skin together with the GPL licensed command line executable as a closed source commercial "product".

As you state, "Nothing stops anyone from charging for the GPL code in the first place."

But in this case, as is common among GPL-licensed programs, the author who wrote the command line executable never charged for it.

The problem I see with this situation is that because the product is closed source, the end user may not be able to determine the extent of "the entrepreneur's" work.

For example, his contribution to the "product" may be quite small in comparison to the work of the original author. That is, the core of the product, the most important bits, may comprise the freely available GPL source code, available to anyone for no charge.

This is not a situation that I expect anyone else to care about. But as an end user, if I were faced with paying for a commercial software product, I would want to know about the entrepreneur's use GPL source code that I could obtain elsewhere for free and the extent of the entrepreneur's "contribution" in relation to the original author.

Returning to my original stupid question, why does the entrepreneur not sell his skin separately from the command line executable. It is a rhetorical question. (Commenters tried to answer it anyway.)

Assuming the command line executable is a well-written, highly valuable program and an end user does not know about its existance, the entrepreneur's product may look quite valuable. The entrepreneur may be piggybacking on the value of the GPL source code but concealing this by keeping the source code secret.

As to your question, you've already agreed not to charge for your patch by the fact that you've utilized the GPL to access the code in the first place. That's one of the points of the GPL after all.

You'd be wrong, though. He considers it a legitimate alternative to "not releasing source at all":

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

https://www.fsf.org/blogs/rms/selling-exceptions

And in fact, it could be argued that it's better (for rms' goals) than MIT/BSD/etc, since the proprietary license will impose some restrictions on its usage by other proprietary vendors.

Remember also, Stallman and co. did come up with the LGPL, which itself is a pragmatic compromise to allow GPLed libraries that can be used in non-GPL applications: under LGPL, you have to share any changes you make to the library itself, but the rest of your application can use a different and/or proprietary license.

It's better to have some GPL rather than no GPL.

Nothing about the GPL stats that you can't _charge_ for your software, in fact RMS explicitly encourages people to make money from free software. You just can't restrict the buyer from redistributing it once you sell it to them.

Probably not. Although from what I've seen, he was rather short on explaining how devs would make money to support themselves under GPL.