<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 8:00 AM John Cowan <<a href="mailto:cowan@ccil.org">cowan@ccil.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_1731251187643384530gmail_attr">On Wed, Jan 23, 2019 at 1:27 AM Bruce Perens <<a href="mailto:bruce@perens.com" target="_blank">bruce@perens.com</a>> wrote:<br></div><div dir="ltr" class="gmail-m_1731251187643384530gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>It's not fair to blame FSF for what the court did in an entirely unrelated case.</div></div></div></blockquote><div> </div><div>On the contrary, alas.  The FSF's GPL FAQ says:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote></div></div></div></div></blockquote><div><br></div><div>OK. This is a silly rhetorical trick. You started with:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><span class="gmail-im" style="color:rgb(80,0,80)"><div dir="ltr" class="gmail-m_-6241924258581900329gmail-m_-1726375947947657055gmail-m_-1042100628760343906gmail_attr">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.</div></span></div></div></div></blockquote><br class="gmail-Apple-interchange-newline"></div><div>Of course, that is obviously untrue, as stated in the GPL FAQ you quoted: "the modules normally are separate programs".</div><div><br></div><div>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.</div><div><br></div><div>Bait and switch.</div><div><br></div><div>The difference here is that this is obviously, deliberately done as a copyright avoidance mechanism. </div><div><br></div><div>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 such thing.</div><div><br></div><div>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 they?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>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.</div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce</div></div></div>