[License-discuss] Intimacy in open source (SSPL and AGPL)
bruce at perens.com
Wed Jan 23 17:29:19 UTC 2019
On Wed, Jan 23, 2019 at 8:00 AM John Cowan <cowan at ccil.org> wrote:
> On Wed, Jan 23, 2019 at 1:27 AM Bruce Perens <bruce at perens.com> wrote:
> It's not fair to blame FSF for what the court did in an entirely unrelated
> On the contrary, alas. The FSF's GPL FAQ says:
> By contrast, pipes, sockets and command-line arguments are communication
>> mechanisms normally used between two separate programs. So when they are
>> used for communication, the modules normally are separate programs. But if
>> the semantics of the communication are intimate enough, exchanging complex
>> internal data structures, that too could be a basis to consider the two
>> parts as combined into a larger program.
OK. This is a silly rhetorical trick. You started with:
As far as I can tell, if I create a one-line shell script that pipes a
> proprietary program (say, Windows NET PRINT, whose output is not documented
> anywhere, I've just eyeballed it) into a GPL-licensed program, say GNU sed,
> I have created a work in which the proprietary part is in "intimate data
> communication" with the GPL program, and so I can't do that.
Of course, that is obviously untrue, as stated in the GPL FAQ you quoted:
"the modules normally are separate programs".
You then went on to cite a pernicious example where a program is modified
to exchange its internal data structures with another program. This is done
only for one purpose, to combine the program with a proprietary program
without having the two programs share an address space.
Bait and switch.
The difference here is that this is obviously, deliberately done as a
copyright avoidance mechanism.
So, it sounds like you want FSF to constrain itself not to fight copyright
avoidance mechanisms in the name of declaring a certain form of interface
as immutably a barrier between programs, when the law and case law does no
And obviously, the FSF isn't going to do things to benefit people who want
to combine proprietary software with software under the GPL. And why should
And I think it is fair to blame the FSF for introducing an undefined term,
> not known to be a term of art, into the GPL3, and thus putting a weapon
> into the hands of those who use the GPL solely for commercial advantage
> and/or employ the SCO business model.
I happen to have been on the GPL 3 committee, although my involvement
wasn't deep, I seem to remember seeing Larry at one of the meetings, and
about 40 other people, mostly attorneys. It wasn't just FSF.
The license wording was constructed to deal with a 20 year accumulation of
case law. That a word unfamiliar from previous licenses was used is simply
due to evidence of various GPL circumventions piling up over time, and
should be no surprise. It seems to me that you wanted FSF to avoid their
responsibility to prevent abuse in the new license text, if this meant
using a single new word. This doesn't sound reasonable.
SCO's business method had nothing to do with GPL. The other business method
you criticized seems to be dual licensing, which is in general beneficial
to Open Source because it funds the production of more Open Source software.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-discuss