> It seems like "reciprocity" has an even worse outcome than BSD source code. The origin of the source code can be completely hidden from the user.
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".
Patching might operate by locating patterns in source files and editing the source files. Either deleting, changing existing text and/or adding new text. The patch files themselves might be considered nothing more than instructions on how to make edits.
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.
> 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.
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.
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.
I think that argument would also imply that you don't need a copyright license to write a sequel to a book (assuming you don't quote the book, but the sequel includes characters / plots from the original book), and I think it's the case that a sequel is a derivative work. So by contradiction, it doesn't matter if the patch to the source includes a nontrivial portion of the source; it's still based on the source either way.
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".