5 ms·

There are good reasons the so-called "BSD zealots" won the so-called "culture war", such as the definition of a derived work being largely uncharted territory.

There are good reasons the so-called "BSD zealots" won the so-called "culture war", such as the definition of a derived work being largely uncharted territory. Did you know that there's a compelling legal argument that the GPL attaches to programs talking to each other via JSON data structures? I think MPL 2.0 is the ideal kind of copyleft, because of its scope being very clear.

kstrauser 1y ago
There is no such compelling legal argument. That’s an extraordinary idea with zero precedent or support.
- sunshowers 1y ago
  https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins > When is a program and its plug-ins considered a single combined program? > It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program. JSON data sent over the wire, particularly data with nested arrays and maps, and especially a bidirectional communication protocol, can reasonably count as "intimate communication" with "complex data structures" shipped "back and forth". This is nonbinding guidance, but it is from the FSF, and it is legally untested afaik (not a lawyer). There's sufficient legal risk here that I'd be wary of using rich communication protocols with GPL programs, particularly if there isn't an explicit exception for that protocol.
  - kstrauser 1y ago
    "Intimate communication" here almost certainly refers to shared memory. No one is claiming passing JSON over the wire is the same as linking, or else a GPL webserver could insist that browsers be licensed under the GPL.
    - sunshowers 1y ago
      > "Intimate communication" here almost certainly refers to shared memory. No, shared memory is addressed later within the same answer. > Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking. The first part of the answer clearly includes programs sending each other "complex data structures", including nested JSON data, over pipes.
      - darkwater 1y ago
        And the first part of your quote starts with > If the main program uses fork and exec to invoke plug-ins Which limits a lot the relationship between the original program and the "plug-in" concept. I mean, we literally have binary proprietary blobs used as kernel drivers...
lmm 1y ago
> Did you know that there's a compelling legal argument that the GPL attaches to programs talking to each other via JSON data structures? The GPL attaches to programs that are legally derivative works. So does any other license that doesn't explicitly grant the right to prepare and distribute derivative works, such as the overwhelming majority of commercial/proprietary licenses. The issue is with the overall copyright/legal system, not with the GPL specifically, and given that most entities are comfortable using at least some non-BSD programs it doesn't seem to worry people in practice.
- sunshowers 1y ago
  Right, as mentioned in https://news.ycombinator.com/item?id=45096736 https://news.ycombinator.com/item?id=45096736, simply running GPL programs is probably fine. Input/output that doesn't establish "intimate communication" probably doesn't create a combined work, but "shipping complex data structures back and forth" does, according to the FSF. There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses) -- whether or not a plugin counts as a combined work, there are no requirements on you.
  - lmm 1y ago
    > There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses) There is a similar degree of legal risk with the overwhelming majority of licenses in use. Yes, using exclusively permissively-licensed software would let you avoid this particular risk - but given that essentially no-one (BSD advocates are, if anything, less scrupulous about avoiding proprietary software than GPL advocates - you rarely hear of BSD-land pushing firmware into a separate nonfree repository or the like) does that, it's clearly not a risk many people care much about.
    - sunshowers 1y ago
      Is your position that the FSF is wrong? If so, why trust the licenses that the same FSF wrote? In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking.

kstrauser 1y ago

There is no such compelling legal argument. That’s an extraordinary idea with zero precedent or support.

sunshowers 1y ago
https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins > When is a program and its plug-ins considered a single combined program? > It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program. JSON data sent over the wire, particularly data with nested arrays and maps, and especially a bidirectional communication protocol, can reasonably count as "intimate communication" with "complex data structures" shipped "back and forth". This is nonbinding guidance, but it is from the FSF, and it is legally untested afaik (not a lawyer). There's sufficient legal risk here that I'd be wary of using rich communication protocols with GPL programs, particularly if there isn't an explicit exception for that protocol.
- kstrauser 1y ago
  "Intimate communication" here almost certainly refers to shared memory. No one is claiming passing JSON over the wire is the same as linking, or else a GPL webserver could insist that browsers be licensed under the GPL.
  - sunshowers 1y ago
    > "Intimate communication" here almost certainly refers to shared memory. No, shared memory is addressed later within the same answer. > Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking. The first part of the answer clearly includes programs sending each other "complex data structures", including nested JSON data, over pipes.
    - darkwater 1y ago
      And the first part of your quote starts with > If the main program uses fork and exec to invoke plug-ins Which limits a lot the relationship between the original program and the "plug-in" concept. I mean, we literally have binary proprietary blobs used as kernel drivers...

lmm 1y ago

> Did you know that there's a compelling legal argument that the GPL attaches to programs talking to each other via JSON data structures? The GPL attaches to programs that are legally derivative works. So does any other license that doesn't explicitly grant the right to prepare and distribute derivative works, such as the overwhelming majority of commercial/proprietary licenses. The issue is with the overall copyright/legal system, not with the GPL specifically, and given that most entities are comfortable using at least some non-BSD programs it doesn't seem to worry people in practice.

sunshowers 1y ago
Right, as mentioned in https://news.ycombinator.com/item?id=45096736 https://news.ycombinator.com/item?id=45096736, simply running GPL programs is probably fine. Input/output that doesn't establish "intimate communication" probably doesn't create a combined work, but "shipping complex data structures back and forth" does, according to the FSF. There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses) -- whether or not a plugin counts as a combined work, there are no requirements on you.
- lmm 1y ago
  > There isn't a similar degree of legal risk with MPL 2.0, nor with non-copyleft licenses (which is the subject of this subthread, not proprietary licenses) There is a similar degree of legal risk with the overwhelming majority of licenses in use. Yes, using exclusively permissively-licensed software would let you avoid this particular risk - but given that essentially no-one (BSD advocates are, if anything, less scrupulous about avoiding proprietary software than GPL advocates - you rarely hear of BSD-land pushing firmware into a separate nonfree repository or the like) does that, it's clearly not a risk many people care much about.
  - sunshowers 1y ago
    Is your position that the FSF is wrong? If so, why trust the licenses that the same FSF wrote? In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking.