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.

▲

lmm 6 days ago | parent | next [-]

> 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 6 days ago | parent [-]

Right, as mentioned in 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 6 days ago | parent [-]

> 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 5 days ago | parent [-]

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.

	▲	lmm 5 days ago \| parent [-]
		> Is your position that the FSF is wrong? If so, why trust the licenses that the same FSF wrote? The FSF says a program that exchanges complex data structures with the covered program "can" be something that requires a license; they don't claim that it always or usually is. My position is that they're correct that it's possible (at least in some jurisdictions) but the risk is low in cases where you're not trying to do a technological end run around something you obviously need a license for. > In general, businesses acquire commercial licenses for proprietary software, which is a kind of derisking. Only if the license grants permission to do the thing you're doing! Otherwise you're no better off than if you had no license (and you're worse off than under the GPL, which at least permits you to prepare derivative works freely, only putting conditions on distributing them). Almost every commercial/proprietary license I've seen has a blanket prohibition on preparing or distributing derivative works.

▲

kstrauser 6 days ago | parent | prev [-]

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

▲

sunshowers 6 days ago | parent [-]

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 6 days ago | parent [-]

"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 6 days ago | parent [-]

> "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 4 days ago \| parent [-]
		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...