This is actually surprisingly interesting case. While I think most would agree that when software does purely "algorithmic processing" then the output would not be considered derivative work. But increasingly software suites include various templates and content libraries. When the output is then a composition of those templates and library content then I'd agree that there is an argument to be made that such output could be considered derivative work.
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.
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.
> 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
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.
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.
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.
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.
I like how they really grill the lawyer of the plaintiff. Frankly, her explanations - especially when trying to come up with a test to distinguish their software from Photoshop - are pitiful.
It gets slightly better later when she explains how some of the elements of the output is controlled by the CAD software, but it is still a very weak argument.
The defendant seems pretty scummy and deserving to be held accountable, but the plaintiff's strategy seems dead in the water. Judges are giving both a very good grilling.
On that note, the Ninth District YouTube account is pretty interesting if you're into legal arguments. I particularly enjoy the hearings with Judge Kozinski.
What I take from the description is that the defendant, Unigate Enterprise (UE), used the software (SDS/2) to produce drawings for its Chinese contractors. The drawings are in a proprietary file format that can only be viewed by SDS/2 (written by Design Data Corporation (DDC)).
Chinese contractors use illegal copies of SDS/2 to view the drawings. So yes, the Chinese have broken the law. It's Unigate's problem that they chose software that produces files that can't be openly shared.
In claiming that the output is copyrighted, DDC seems to be resorting to a last-ditch (and groundless) effort to sue their American client, UE, because they have little prospect of getting anything out of the Chinese.
Bottom line:
[1] Somebody broke the law.
[2] It has little to do with copyrighting a program's output.
Those are not the facts. UE didn't use SDS/2. They subcontracted work that requires the use of SDS/2 to a Chinese subcontractor who used an allegedly pirated copy of SDS/2 to do the work. It has to do with copyright in program output because that is what DDC is claiming. I would agree that the claim in this case is weak but it is before the 9th Circuit and their opinion is going to be very interesting either way.
> Judge Callahan and Judge Hurwitz were both troubled by the fact that UE had advertised on its site that it used the SDS/2 software. UE’s counsel answered that UE was counting on contractors to use it, but admitted that UE had never asked DDC if it was indeed true that the contractors were legally using the software.
It matters to the question of whether or not UE contributed to copyright infringement, not to the question of copyright in the output of the SDS/2 software.
> UE admitted that SDS/2 had been used to create files and drawings in five of its projects, but argued that they were made by contractors in China.
China piracy story time. I was talking to makers of a niche CAD type software package. It was niche enough that they simply knew all their customers pretty much by name. They went to a trade show to exhibit their software, and a group of Chinese engineers approached them, thanked them and told how much the love their software, it is the best really for what it does, etc, etc. So that was good, everyone was happy and smiling, except one thing - the company shown on their badges was not a client.
Well they had a problem. Their software was being pirated. There was talk of a selling a hardware dongle with it. But I am not sure what came of it, since I lost contact with them.
Here is what I wonder. Even if they lowered the price just for China, would there be a point where they would choose to pay for it or it would never matter a pirated copy would always be preferred.
I have done a few HW and a few SW startups. For the HW I would eventually help us move into all of Asia. For the SW I would help move into Asia, minus China.
At our company we did eventually end up with a hardware dongle. But it helped that it was a HW/SW solution anyway. We just added a few operations that needed to go through a hardware module. It was just enough hoops to jump through to hopefully dissuade the casual "pirate".
It was an interesting problem anyway. A lot of obvious solutions didn't seem to work, like say just checking a flag in an "if ... else" branch because that can be disassembled and bypassed with a patch. Some functional operations that are critical to the product had to actually go through the hardware... Now looking back we probably over-engineered the heck out of it.
Does it include future updates? Are they pushed out to clients automatically? Does it include product support? Is it at least as easy to use as the pirated version (i.e. no intrusive DRM)? Is it at least as easy to obtain?
If you can provide a service that can't easily be copied for less, generally people will pay for it.
If we're asking "should a user be able to continue using files created with a program beyond the point that they are paying from that program?" we're not that far from the practical effects of such a decision already.
I'd wager that a good 90% of the world's graphical/artistic material is locked up in Adobe-proprietary formats for which the only practical editing software has moved to a cloud licensing model. Dispute with Adobe? Say goodbye to all your company's assets...
// At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
// PSD is not a good format. PSD is not even a bad format. Calling it such would be an
// insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
// worked on this code for several weeks now, my hate for PSD has grown to a raging fire
// that burns with the fierce passion of a million suns.
// If there are two different ways of doing something, PSD will do both, in different
// places. It will then make up three more ways no sane human would think of, and do those
// too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
// that *these* particular chunks should be aligned to four bytes, and that this alignement
// should *not* be included in the size? Other chunks in other places are either unaligned,
// or aligned with the alignment included in the size. Here, though, it is not included.
// Either one of these three behaviours would be fine. A sane format would pick one. PSD,
// of course, uses all three, and more.
// Trying to get data out of a PSD file is like trying to find something in the attic of
// your eccentric old uncle who died in a freak freshwater shark attack on his 58th
// birthday. That last detail may not be important for the purposes of the simile, but
// at this point I am spending a lot of time imagining amusing fates for the people
// responsible for this Rube Goldberg of a file format.
// Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
// I had to apply to them for permission to apply to them to have them consider sending
// me this sacred tome. This would have involved faxing them a copy of some document or
// other, probably signed in blood. I can only imagine that they make this process so
// difficult because they are intensely ashamed of having created this abomination. I
// was naturally not gullible enough to go through with this procedure, but if I had done
// so, I would have printed out every single page of the spec, and set them all on fire.
// Were it within my power, I would gather every single copy of those specs, and launch
// them on a spaceship directly into the sun.
//
// PSD is not my favourite file format.
At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
PSD is not a good format. PSD is not even a bad format. Calling it such would be an
insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
worked on this code for several weeks now, my hate for PSD has grown to a raging fire
that burns with the fierce passion of a million suns.
If there are two different ways of doing something, PSD will do both, in different
places. It will then make up three more ways no sane human would think of, and do those
too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
that these particular chunks should be aligned to four bytes, and that this alignement
should not be included in the size? Other chunks in other places are either unaligned,
or aligned with the alignment included in the size. Here, though, it is not included.
Either one of these three behaviours would be fine. A sane format would pick one. PSD,
of course, uses all three, and more.
Trying to get data out of a PSD file is like trying to find something in the attic of
your eccentric old uncle who died in a freak freshwater shark attack on his 58th
birthday. That last detail may not be important for the purposes of the simile, but
at this point I am spending a lot of time imagining amusing fates for the people
responsible for this Rube Goldberg of a file format.
Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
I had to apply to them for permission to apply to them to have them consider sending
me this sacred tome. This would have involved faxing them a copy of some document or
other, probably signed in blood. I can only imagine that they make this process so
difficult because they are intensely ashamed of having created this abomination. I
was naturally not gullible enough to go through with this procedure, but if I had done
so, I would have printed out every single page of the spec, and set them all on fire.
Were it within my power, I would gather every single copy of those specs, and launch
them on a spaceship directly into the sun.
Haha, yeah - I remember that. Don't get me wrong, I'd hate to be the person to actually unlock the data in that format. My point was that it's not a great example in this context because it is "open".
That is a really poor comparison. Imagine you built a piece of software that had tens of thousands of man hours of industry specifications, templates, calculations, symbol libraries, and regulatory compliance built in. Now imagine an american company was 'offshoring' their piracy to Chinese subcontractors who used that software illegally to produce intelligent CAD files (i.e. not just a CAD drawing, but bills of materials, specs, and calculation tables) that literally could not be produced to the same standards without that software. And then sold those files in the US market for major profit, without ever having payed for any licenses of your software or tools.
I am all for open standards, and I don't really care about individual piracy. But a company should be held responsible for the ethical production of their products no matter if they subcontract the work or not.
What, it's not bad to scare off their own customers? After such claims, they'll ditch this vendor, and will go looking for more sane competitor who isn't a copyright freak.
I believe the parent meant that it's not a bad idea to reevaluate the usage of any software that is business-critical and may have similar repercussions should your license to use it expire.
Once again the dangers of proprietary software in the businesplace raise their heads. I wish people with the ability would work on contributing more to the open source cad projects, because at one point suffering under autodesks draconionan and expensive licensing I tried to get a business to start switching but the open source stuff simply isn't up to snuff in most cases.
There are thousands of CAD packages out there and most are proprietary because they do proprietary stuff for a niche market.
All the open source CAD packages are general purpose cad (i.e. Basically "drawing") software.
I make a package with 100 man years of dev time that might have a total global market of 2000 users. It's not exactly something that would reach critical mass on github.
Even if we based our software on one of the open source packages we'd still be a huge chunk of proprietary software written as an extension.
I use FreeCAD for my 3D printing designs. It works great on Windows and Ubuntu (not so great on Mac), but for designing enclosures for electronics projects and printing them, it has met my needs. I think it takes longer to learn than AutoCAD's maker apps, but I know i will always have access to my designs. It will be a shame if all of this open hardware for 3D printing, and CNC routers doesn't result in a feature rich CAD application. From what I can see, AutoDesk saw the risk and has inserted themselves with "fun and easy" web based and cloud apps.
I mean you won't find GNU projects doing stuff like this, but only in proprietary land do you find companies who think it's ok to copyright output. (which is a symptom of the bigger issue of culture around non-free software in general)
Actually, the output of Bison is GPL'd on the same grounds as presented in this case, that a significant portion of it includes code from Bison itself. You can't link and distribute a Bison-generated parser with a non-GPL parser generator (for other kinds of programs, the license contains an exception that allows linking).
What is hysterical about the title i.e. "When is the output of a copyright-protected software program itself protected by copyright?" ?. Seems very appropriated and balanced.
Many EULAs explicitly include a clause stating that the vendor does not hold any rights over the output of the program. (A common example is when you use a compiler to create a binary. Read what the license says.)
And many do not. I have negotiated software licenses for 15+ years and had to fix this issues many times. Just as many software licenses explicitly only license object code, but the licensed product turns out to contain quite a bit of source code, which if not addressed the licensee is not allowed to use (copy).
If you pirate the software, you certainly aren't agreeing to any EULA. It's actually an interesting case, more than you could think as a first impression.
Defendant in this case probably knows and purposely uses Chinese contractors to get around licensing expensive software. So not exactly someone to cheer for. But plaintiff also wants to set a pretty bad precedent.
I think they likely just look at the sub-contracting costs and see that the Chinese contractors are massively cheaper then don't ask too many questions.
It's pretty much business as usual to pirate CAD software in China so they probably knew what was happening though.
What's pathetic is that they actually did download the software, which will probably come back to bite them. Sounds like we can hope this is a case in which everybody loses :)
They appear to argue that the download was some sort of trial copy or at least that they thought it was. It appears undisputed that they never used the software.
It's not quite that. If the output of the program was a standard text file, then no, because nothing of the program was copied. If for example the output of the program included certain fonts or graphics (e.g. PDF), those are still copyrighted. To use those fonts, you'd need a licence, in this case the same licence you need for the program.
For niche CAD tools theres usually only one or two games in town and a lot of stickiness with old files, production workflows, user skill with the tool, etc.
Switching to a different solution may not be an option.
Unless they start suing all of their customers, they're probably fine.
Why not argue that because the external contractors in china are using an illegal copy, therefore there is no client that paid a license to use the software, and that DDC (software maker) should be able to assume the copyright of the output because they are the only viable and legal copyright holder of the software in use. AND therefore the only one with a valid license of the software and its output.
One of the judges actually start by disabusing DDC's counsel of the notion that one has anything to do with the other. You don't get to invent a new legal concept just because someone allegedly pirated your software.
The company is accused of pirating the software. If they had it lawfully, they wouldn't be in this fix. The question here is whether the program outputs from a pirated program are free of copyright restrictions.
No, the fact that they "pirated" the software is a separate claim, since the output files were not produced by their copy of the software. They would be in this fix even if they had never "pirated" it.
