Isn't that true? A compiler's output does include many portions which include creative effort of the compiler writers. Licenses for compilers thereby explicitly include a clause on giving up that ownership over the output of the compiler. In other words, the line of reasoning has always been true; perhaps you were unaware like most people who never actually read the license text.

GCC does not have such a clause. What it does have is a clause allowing a small library - the GCC Runtime Library - to be linked to and included in its output, provided certain conditions are met. The library is separate from the compiler input and not a result of it - it contains some core functions involving things like exception handling, arithmetic on some architectures, etc. It's held to be self-evident that compiler output that is a direct result of compiler input does not come under the license of the compiler.

GCC does not, but Autoconf and Bison for example do. GCC's templates are a handful of instructions long (at most) and are subject to plenty of transformations before they end up in assembly code; Autoconf and Bison literally copy hundreds of lines of code verbatim. You need a license that is separate from the GPL to use that output in a non-GPL-compatible derivative work.

That makes sense - if autoconf source is closer to a set of instructions "please include library functions A, E and G in this order" than C source, it's obvious that each function is under copyright and so the output would come under the terms of the license covering those functions.

This just to point out that it is considered self-evident in respect of GCC. This is based on how GCC works specifically, not compilers in general. There are certainly compilers/transpilers etc. and similar kinds of software out there where it is not self evident that the output is not a derivative of the tool, and some where the output very clearly is.

It has little to do with "creative output" and more to do with the license surrounding those components you use, and the components your "final product" uses. You seem to be insinuating it's ridiculous to apply this sort of "derivative work, by-way-of-library" logic to compilers, but it absolutely happens all the time. It happens especially with compiler-style things, in fact.

Just as the most obvious example, several large GPL libraries, parts of GCC such as libgcc, and more, run under the GPL linking exception -- this exception to GPL-licensed libraries means that programs using those libraries directly are not subject to the rules of the GPL, while normally they would be (under the "derivative work" logic). For example, every C program compiled by GCC links against libgcc, which is GPL. But you are not implicitly put under the terms of the GPL, just because you used GCC to compile something, and it happened to use libgcc. libgcc explicitly exempts this use case.

So, why does this exception exist, and why is it explicitly stated? Precisely because, just like those "template content libraries" from some random vendor, GCC links your code against components and libraries that have clear licensing terms. The licensing terms of those libraries absolutely impacts the licensing terms of the final, produced work, unless stated otherwise. (Have you ever noticed how even commercial software is required to maintain a copy of the BSD license? Well, it's legally required to, if you use BSD software. It says so, right on the tin.) This isn't some kind of legal 12-dimensional chess, it's a fairly obvious bump you encounter quite quickly. This is obviously especially important for compiler-style things, since in reality, their whole purpose is to generate "derivative works" of all sorts. Guile also has a GPL linking exception for some similar reasons, IIRC.

In all honesty, to me, the weird thing about this case isn't that they're making claims about "derivative works" or whatever, with regards to libraries. It's weird to me that they even need to make the argument at all -- most of the time, with a lot of software, the licensing situation surrounding components like this (and how you can use them) is pretty clear. It seems odd it wouldn't be strictly clear already, in a way.

They need to make the argument because the defendant is not a licensee. Their theory is that defendant has knowingly used a Chinese subcontractor that uses priate software to produce the output that they sell to their customers. So they go with contribution to copyright infringement and the output being a derivative work and the defendant's use (copying) therefore a violation of copyright.

And that's the real issue. The CAD company did suffer harm, however the idea of the output being copyright is wrong but it looks like that was the only angle they could go. Our system is pretty screwed up. I wonder if there chould be a case for a "corrupt practices act". If you can prove they knowingly outsourced to a company they knew was using pirated software how is that different then working through let's say a channel partner that pays bribes? I deal with partners all the time and under US law if I knowing I am doing business through a 3rd party that paid a bribe (my hands never touched it) I can be prosecuted because I knew.

Iirc the whole chain needs to be licensed and copyright transfered, that's to avoid issues with people laundering pirated items with a legit contract knowingly.

So the issue remains if they knew the wendir hadn't a license - that'd be necessary to know where to assign damages, but still they would not be able to use the output, as created without a license to begin with.

If the vendor had not a license to work with the software the output has been illegaly obtained, while claiming copyright on the output may not stick claiming a royalty along punitive damages is not that far fetched.

Not exactly. I think it would be closer to a languages stdlib being included with a compiler and the use of that stdlib plus the compiler (javac+jdk, for example) would be derivative work.

And libraries typically have their own license.

I wonder if these templates came with a license, or are considered part of the CAD software and not redistributable?

And processor's output is derivative work of creative work of processor designers

And processor design is derivative work of electronic engineers.

And electronic engineering work is derivative of physicists' work.

And physicists' work is derivative of mathematicians.

And mathematicians's work is derivative of Colombian coffee farmers.

More like:

And mathematicians's work is derivative of pharmaceutical companies that produce amphetamines

And pharmaceutical companies that produce amphetamines are derivative of chemists' work

And chemists' work is derivative of physicists' work, which gives us a nice loop

Colombian coffee farmers own everything, QED

All your base belong to us!

But seriously, all the compilers I've worked on did not make any copyright claims on the compiler output. The libraries either included a royalty-free license to distribute the result linked in with your product, or were Boost licensed so you could do whatever you wanted with it.

Doing anything else would result in exactly 0 users.