> The FSF has substituted the phrase “modified works” in place of “derivative works” in v3 of the license, yes, but not to narrow the definition - the intent was to broaden the definition to cover additional classes of modification.
Eben Moglen wrote a little about the intent here [0], I'll excerpt a little:
"This form of explanation was unfortunately unhelpful. It led to years of fruitless discussion about the role of “derivative works” doctrine (a US concept) in software (where US courts have largely failed to provide any guidance). So in GPLv3, we and our clients at the Free Software Foundation decided to drop all illustrative reference to US “derivative works,” returning to the base concept only: GPL covers the licensed work and all works based on the work, where “based on the work” is defined as any modification or combination with the licensed work that requires copyright permission to make."
I don't know if that broadens or narrows, but I think that's the point: case law on "derivative works" was pretty vague (I'm unfamiliar but I'll take Moglen's word). But, to me it sounds like an effort to be more concrete rather than an effort to broaden the conditions under which you have release obligations.
> From the FSF’s licensing FAQ: ...
A couple things.
First, this FAQ entry is about aggregation; the paragraph above what you quoted is this:
"An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them."
This isn't some kind of "I run a Kubernetes cluster" situation, it's a "I ship a Linux distribution on ISOs" situation.
Second, I was in a different GPL thread [1] discussing some similar things, but all contracts, licenses, statutes, and founding documents have ambiguity in them. I listed a couple reasons (authors can't/don't want to exhaustively enumerate every scenario, human language is imprecise) but I realized I omitted a third reason: times change. You generally want whatever you're authoring to last a little while, not only because legal fees are expensive, but also because relicensing isn't always easy (GPLs have clauses in them letting you additionally license them under any later version, I would assume this is why).
And finally, there's a real double standard--or at least cargo culting--when it comes to the GPLs here. Here's some ways other licenses are ambiguous or potentially unbounded in their coverage:
- Apache License version 2: refers to "derivative works", also: "'Object' form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types." (i.e. does minification count?)
- BSL: also refers to notoriously vague "derivative works"
- SSPL: defines propagation partially with the phrase "in some countries other activities as well."
It's true the GPLs are more complex and ambitious than something like the ISC license (the favorite comparison around here, I think) but that license is something like 100 words. It's not comparable.
[0]: https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL...
[1]: https://news.ycombinator.com/item?id=41277241