In my opinion, any effect that the following amendment may have is sound with respect to the DFSG in any case: > Permission is not granted to distribute or redistribute this software, the > derivative works of this software, or any of its associated files that was > generated in any approach (including building machine learning models), for > any purpose, without attributing the source material by including its license.
A useful example to compare with is Debian's stance that the GNU Free Documentation License is non-free when a covered work exercises the option to designate "invariant sections" that shall not be removed from a work or its derivatives. What makes that situation exceptional is that such invariant sections are typically not used for retaining copyright or authorship information, but supplemental slogans or remarks that, from Debian's point of view, are much less important to be preserved verbatim. For example see GCC's front-cover and back-cover texts at https://gcc.gnu.org/onlinedocs/gcc/ (and note that requiring a downstream to preserve the phrase "A GNU manual", even when the manual has been substantially modified to depart from anything ever published by GNU, is potentially misleading to downstream readers). The amended paragraph being considered, as quoted above, is basically restating the following line from the MIT/Expat license more explicitly, except possibly with more broad scope with what's considered a derivative work: > The above copyright notice and this permission notice shall be included in > all copies or substantial portions of the Software. The biggest difference here is requiring authorship information to be preserved in copies and "substantial" portions; the amendment doesn't use the word "substantial" to limit the scope of which derivative works must include the license and copyright information. This is fine for us; requiring "non-substantial" derivative works (whatever that may mean) to include such info is okay. I also want to draw attention to this point by Soren Stoutner: > What makes this a little different is that it appears to claim that works > produced using the software must also attribute the original upstream project > and distribute a copy of the original upstream software license. It does > *NOT* say that works produced using the software must be *licensed* under the > original upstream license. > For example, if this license were applied to LibreOffice, it would require > that any *documents* produced by LibreOffice be distributed with an > attribution saying it was produced using LibreOffice and a copy of the > LibreOffice license. I don't share this reservation—if this is being inferred from the "or any of its associated files", I think the "associated files" is intended to refer to files associated with the work. This should be cleared up, but as I'll argue in a moment, this would still be DFSG-free for a couple of reasons. With respect to the FSF's stance and in the context of the GNU GPL, mere output from a program—like what would happen in the LibreOffice example—is not typically a derivative work of whatever program that made it. (Their rationale is outside the scope of this discussion, but is related to whether creative elements of the software—like any templating engine LibreOffice may use—feature in the output.) Parser generators like GNU Bison are the exception: large chunks of C code from Bison itself are included in its output, and so it is a derivative work: examination of the output by a skilled reader will recognize that it's a GNU Bison file by its structure. Even though the scope is quite different, the GNU Affero General Public License somewhat touches at this type of issue in saying that program interfaces or output exposed over a network is treated like a derivative work for the sake of abiding by conventional GNU GPL license requirements. The GNU AGPL is unambiguously conformant to the DFSG; so by a similar nature, it could be argued that requiring program output that is redistributed or modified to attribute the author of the software that made it is acceptable. In the case of this Qt library however it seems like this issue is moot; in fact this looks like a very small library just to tweak application behavior at runtime, and from a skim, to keep just one instance running at a time. So none of these concerns should really matter, but even if they did, the terms would probably be reasonable even if they could be construed as applying to some kind of "output data" or "products". In conclusion, the tweak that upstream made to the license terms today makes it free again and no longer discriminates against any fields of endeavor. It merely broadens the instances when attribution might be required, which to their defense helps to counter the MIT/Expat's limitation in scope to merely "substantial" portions of the software. Machine-learning models often take mere snippets, or it can be hard to assess what input data was used to arrive at some output, so in such cases this may actually be a material difference. Debian has always been sympathetic to maintaining integrity of authorship information when this is not burdensome. The new amendment is only effective for copies or duplicates, even if the definition of "duplicate" is broadened to more closely resemble one from the GNU (A)GPL.
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
