By that line of reasoning, your compile's output is derivative work of the creative effort of the compiler writers.

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.

Right, but usually the licensing around libraries/templates is quite clear? At least it should be.

Here's specifically what they're claiming copyright over:

"DDC’s counsel answered that DDC is focused on expressive content that is not in the actual design of the component, such as the font or the colors used, the shape of a comment box, or the placement of certain components around the design which appear in the design file, but which are not the design itself."

Which seems very weak. Clearly they really would want to go after the Chinese sub-contractor but know this is too hard.

Only way round this I can see is new legislation that means you can be held responsible for copyright violations of sub-contractor if you can reasonably expected to know they are violating copyright.

Going after copyright on the output files is daft and dangerous.

> Right, but usually the licensing around libraries/templates is quite clear?

I think it would have been clear if UE had used legitimate licensed version of the software. In that case I'd imagine they would have gotten license to the auxiliary content too. But if they were using unlicensed pirate version of the software then they would not have had proper license to the content and so the output files would have been infringing too.

This case isn't about libraries/templates. If it were I think it would be a clearer copyright violation.

> the font or the colors used, the shape of a comment box, or the placement of certain components around the design which appear in the design file, but which are not the design itself

Sounds a lot like a description of a template to me

Agree that it should be clear. Reality unfortunately in my experience is a lot less so.

It seems plausible to me that the author of _some_ software would have copyright of that software's output. For example I assume the authors of a 100% non-interactive, real-time rendered audio-visual art piece (c.f. demo scene) would own the copyright of the output (e.g. a movie file), even if someone else runs the software.

Another example would be an interactive game. Here the player / user contributes a certain creative input, but still some game developers retain the right to stream gameplay (=distribute the output of the software which uses certain copyrighted assets?).

I guess a game like Minecraft might "cross the line" to where some of the output (any elaborately voxel constructions) might plausibly be owned by the player.

The boundary for transformation is established in several areas of media.

Recorded samples from the line out of a synthesizer are owned by the author of the recording, even if they're factory presets. Likewise, bitmap conversions of a vector font are the property of the game developers who made them.

In contrast, sample data copied from the ROM of a synthesizer is still under copyright, and original vector font files are owned by their authors.

Actualy, generally in the US, bitmap fponts are not copyrightable, nor are any pure image representations of the glyphs in a font. Truetype fpnts generally are copyrightable because they are small programs that generate the desired glyphs, and it's the program itself that is protected.

That is an interesting point.

Moreover, I am wondering, just for cases like these, if a company could make their output copy-writable on purpose. They could insert code or content in the output just to be able to claim copyright on the output not because they need to.

Think of a nightmare scenario if say Java compiled code would not include just bytecode but bits of JVM meshed together with the bytecode. Then Oracle could come after everyone compiling and selling java programs.

> Then Oracle could come after everyone compiling and selling java programs.

... without a license from Oracle to redistribute those bits. The point in the lawsuit of this post is that the software was pirated.

I was talking in general about making output of programs a copywrite of programs' owners. That is what they tried to claim ultimately here in a desperate attempt.

The other side of it is that refusing to offer reasonable licenses to users of the software will tend to cause them to stop being users.

Only in a market with competition. Especially healthy competition. I don't know CAD market that well, but for example my dad did it for 20 years and only liked 1 program. Doubt he could have switched easily with so much work in one format.

I agree that the question is interesting and the result in other cases (e.g. code generation tools) might surprise many, but this doesn't appear to be a obvious example of output being a derivative work.