Location: United States

Given that copyright does not protect ideas

  1. Let's imagine app a and app b.
  2. These two apps are created by two different people.
  3. No patents are involved.
  4. The person that created app b had access to app a's full source code before working on app b.
  5. These two apps do the same thing.
  6. App a has 10 features.
  7. App b copied all 10 features from app a, but expressed all features in a different way where there is no substantial similarity.
  8. Would App b be copyright infringement?
  • 1
    Can you clarify "had access to app a"? Does that mean full source-code? Or just running the app, and seeing its features? The latter, is sometimes called Clean Room Design, and is used a lot by companies.
    – John C
    Jun 18 at 13:36
  • 1
    Sure. "had access to app a" = had full source code.
    – user45547
    Jun 18 at 13:42
  • 1
    It may be relevant, both to the findings on disputed facts and to other contractual considerations, to know if the implementer of B was an employee or similar at A.
    – Josiah
    Jun 18 at 20:19
  • Note that at some level, whether or not something is legally copyright infringement is irrelevant. If the entity that created app a has significantly more money than the entity that created app b, they can make life very unpleasant for the person who created app b. Or if the entity that created app b has significantly more money than the entity that created app a, they can probably outlast any copyright suit, although they'd also be a much more attractive target for a copyright infringement suit. Jun 18 at 21:10
  • There have been a lot of similar cases in the music industry. B gets accused of copying a song written by A; if it can be shown that B has heard the song written by A, even once, it's hard for B to prove that they didn't subconsciously copy it. Jun 19 at 21:29

7 Answers 7


The other answers get at this somewhat obliquely, but to be clear your assumption 7, that there is no substantial similarity, implies no infringement. Substantial similarity is an element of infringement. But it is also often a disputed element. On your fact pattern, it might even be the only disputed element in the case, and in a close case in a technical area such as this (where it would likely seem to a judge that it could go either way), a jury would simply vote on it. That is, no oracle of copyright doctrine would be consulted for "the answer" to the question of substantial similarity; a jury would just hear testimony from both sides and get some instructions from the judge on the applicable standard (which are rarely much, if any, help) and vote.

Substantial similarity - that is, similarity that appropriates "enough" of the original work to be actionable - is very difficult to assess in any objective manner. This aspect drives many creative people in copyright-intensive specialized disciplines (such as software and music) crazy. Often when people have expertise in an area, it may seem "obvious" to various individuals what ought to be actionable and what shouldn't. But it is rare to find complete conensus. (Most copyright infringement cases involving music - e.g. the one involving Katy Perry's "Dark Horse" or Robin Thicke's "Blurred Lines" - attract a lot of attention because juries end up voting on an issue that almost anybody who has heard two songs could form an opinion about, and maybe a strong opinion about.)

A loose analogy to your question would be in the criminal context, where the fact pattern is, so let's say A kills B, but didn't intend to, did A commit murder? In most jurisdictions the formal legal answer to that question would be "no, of course not, because intent is an element of the crime of murder." But in many murder cases intent is a highly disputed element (sometimes the only disputed element) and in close cases a jury just gets to vote on what they think from their understanding of the facts, or at least what is presented to them as the facts in court. (The standard of proof in criminal cases is formally different but in practice I am not sure it is at all different.) As another answer suggests, the fact pattern you describe sounds kind of "fishy," and while that does not doctrinally matter, let alone settle the issue, it might matter to a jury.

Two cases somewhat along these lines are Google LLC v. Oracle, Inc. (which involved basically this fact pattern, with Google in the role of "app b") and Lotus Dev. Corp. v. Borland Int'l., Inc. (with Borland in the role of "app b", although the copying that occurred was not at the level of source code). They were both ultimately decided on other grounds (and the relevant issues only got to a jury in one of them), but in a world where other statutory defenses had not been asserted they both could have been decided simply by jury vote.

  • 1
    The normal, full-length versions of Wikipedia URLs, without a trailing space, are strongly preferred Jun 20 at 1:37
  • @DavidSiegel Got it. They were an attempt to avoid the behavior by which SE does not include the period in typed-inline link that ends in a period, which can confuse Wikipedia (the Lotus link without a period redirects appropriately, but the Google link without the period redirects to a "did you mean..." page). I've since discovered that SE's editor has a hyperlinking function that allows one to fix this while still using the original URLs, and edited accordingly. Many thanks Jun 20 at 5:41
  • In the adnroid lawsuite, as far as I understood from groklaw, the final issue was that some parts were in fact a copy/paste and the question was whether these parts (the API specifications) are copyrightable. And here is the stupid decision at the end that it was copyrightable. Jun 20 at 9:39

"Does B infringe copyright" is not really of any interest. The interesting question is "Can A convince a court that B infringes copyright". Normally, if you plan to write software B that behaves similar to A, you will make absolutely sure that there is nobody on your team with access to the A source code. Because if you are taken to court, you can then state "we didn't infringe A's copyright. Even if we had wanted to, we couldn't have done it, because nobody was in any position to copy any of A's code". That is a very convincing argument that you didn't copy anything.

Remember that A doesn't have to prove copyright infringement beyond reasonable doubt, only that illegal copying is more likely than no copying. If anyone on your team had access to all of A, then you obviously could have copied. And we know that any good company wouldn't let that person on their team, for exactly that reason, so it looks likely that B intended to copy. And we know that any decent developer can take a bit of existing code and make it look different. So if A finds an expert witness who declares that B's code could have been created by copying and modifying A's code, then B is in trouble. Because under the circumstances it looks very like that copyright infringement has happened. Not "beyond reasonable doubt", but likely enough to get B declared liable in a civil court.

  • 4
    The approach you describe is called clean room design. Worth linking this: en.wikipedia.org/wiki/Clean_room_design or similar as it backs up the answer showing that this is a de facto standard for copying functionality without infringing copyright of lines of code. Jun 19 at 9:10
  • 3
    @NeilSlater: It is and it isn't. If you are deliberately setting out to make code that "works like X," then yeah, sometimes clean-room design is a reasonable way of accomplishing that. But realistically, software engineers read and write a lot of code. Nobody seriously contends that source code somehow "corrupts" the engineer and makes all of their works derivative of it, automatically and by operation of law. Imagine if such a standard were applied to novelists! It's a gray area, and requires judgment and a measure of common sense on the part of the engineer and their management.
    – Kevin
    Jun 20 at 8:10
  • 1
    "And we know that any decent developer can take a bit of existing code and make it look different." From my experience, it's usually obvious when a developer has done this, though. Making a substantial amount of code appear fundamentally different (so that one does not look like it came from the other) seems just as hard to me as making one fictional story appear fundamentally different from another. Of course, code in any language will almost always incorporate common elements (scènes à faire), so these need to be excluded from the analysis.
    – Brandin
    Jun 20 at 8:50

The answer to your question highly depends on the level of "expressed all features in a different way".

If B only renamed all variables => not enough

If B re-designed every algorithm of each non-trivial feature => enough

But do notice that it will only be enough to ensure that there is no copyright/plagiarism involved from source-code point of view.

This particular set of feature (in particular their graphical presentation) , if not mainstream in the domain, may constitute an element of design by itself.

As you mentioned copyright is not about idea, but rather about purpose and intent, hence if this particular set of feature serves a purpose it becomes an element of intellectual property by itself.


Copyright is all about expression so, if you mean the same thing by that term as copyright lawyers mean when they use it, there is no copyright issue, almost by definition.


A strategy for avoiding copyright infringement while copying the features is clean-room design, if used in the right manner.

The person that created both apps can be secure if they don't work on any part of the app B's specific expression such as code and media. For instance, Company B may hire a developer of App A as a product manager - writing the feature requests, but not having access to the code repository.

If people from App A's coding team have also been coding App B, they will only have good defense against copyright infringement if no substantially similar code fragments are discovered. Design can also be considered expression.

If large similarities are found, the court will weigh on a balance of probabilities. To a layman, similar code will likely look like copying. An expert witness will be able to tell boilerplate code like "void main(void)" from actual copying.

Coding App B in a language different from App A will likely sway the court against infringement. However, keep in mind that unauthorized translations between human languages do infringe on copyright, so it would have to differ in more than syntax.

  • 3
    It is worth noting that a clean room design only works if the copyrightable elements are not part of the specification conveyed between the reverse engineering team and the implementation team. Otherwise it is just copying with extra steps.
    – Josiah
    Jun 18 at 20:17
  • 2
    Clean room design does not guarantee non-infringement, no does lack of clean room design prove infringement. Using it is good practice, and is often good evidence of lack of intent to infringe, and of lack of infringement on the source code. But is is not a magic talisman. Jun 18 at 23:20

If the statements in the question are all accurate, then there is no copyright infringement here. But note that statement 7:

App b copied all 10 features from app a, but expressed all features in a different way where there is no substantial similarity.

includes a legal conclusion, and often a key point in issue in a copyright case. Whether there is or is not "substantial similarity" is ultimately a question for the court to decide. A court may find "substantial similarity" even in the clear absence of source-code copying, provided that the display and interface are sufficiently original to warrant copyright protection.

Indeed since substantial similarity is an essential element of copyright infringement, statement 7 is legally equivalent to saying that "app b does not infringe on app a."

In *Arica Institute, Inc. v. Helen Palmer and Harper & Row Publishers, Incorporated, 970 F.2d 1067 (2d Cir. 1992) the second circuit court of appeals wrote:

Since direct evidence of copying is rare, a court may infer it upon a showing that defendant had access to the copyrighted work, and that the allegedly infringing material bears a substantial similarity to copyrightable elements of plaintiff's work. Folio Impressions, Inc. v. Byer California, 937 F.2d 759, 765 (2d Cir. 1991); Warner Bros., Inc. v. Am. Broadcasting Cos., 654 F.2d 204, 207 (2d Cir. 1981); 3 Nimmer, Nimmer on Copyright § 13.01 [B] at 13-8 n. 26.3. Two works are substantially similar where "the ordinary observer, unless he set out to detect the disparities, would be disposed to overlook them, and regard [the] aesthetic appeal [of the two works] as the same," Peter Pan Fabrics, Inc. v. Martin Weiner Corp., 274 F.2d 487, 489 (2d Cir. 1960). Accordingly, summary judgment may be appropriate "either because the similarity between the two works concerns only 'non-copyrightable elements of the plaintiff's work,' or because no reasonable jury, properly instructed, could find that the two works are substantially similar." Warner Bros. Inc. v. Am. Broadcasting Cos., 720 F.2d 231, 240 (2d Cir. 1983) (citations omitted); Hoehling v. Universal City Studios, Inc., 618 F.2d 972, 977 (2d Cir.), cert. den. 449 U.S. 841, 101 S. Ct. 121, 66 L. Ed. 2d 49 (1980).

In the Arica case the Second Circuit Court did find substantial similarity of certain aspects of the alleged source work, and thus that some copying had occurred that was sufficiently extensive to constitute infringement. But it found that many of those aspects were factual in nature, and thus not copyrightable. The remaining aspects, court found, were a valid fair use of the original.

In Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992) the US Second Circuit Court found that non-literal elements of software, including the structure, sequence and organization of the software, could be protected by copyright, and devised the Abstraction-Filtration-Comparison test. This three step test, as the Wikipedia article about it states, "has been widely adopted by United States courts and recognized by courts outside the United States as well."

Recent copyright cases have tended not to find infringement where similar look-and-feel are produced by significantly different underlying code, particularly where a clean-room design method has been used. But look-and-feel, or interface, where significantly original, may still be protected.

Thus in the case described in the question, one would need to apply the Abstraction-Filtration-Comparison test. One would also need to consider if a significantly original interface had been copied, even if differently implemented. Such analysis can be complex and fact-driven, perhaps more so than the OP realizes.

  • "statement 7 ... includes a legal conclusion" - Which part is the legal conclusion? The "copied" or the "there is no substantial similarity"?
    – Brandin
    Jun 20 at 14:01
  • @Brandin the part about there being "no substantial similarity", Whether or not there is "substantial similarity" is often the very thing a court must decide in a copyright infringement case. If there is none, there is no infringement by definition. Jun 20 at 14:07

The problem here lies in step 4, “The person that created app b had access to app a's full source code.” What real-world software engineers do to avoid getting sued is the opposite of this, “clean-room engineering.”

The classic example of this was Phoenix Technologies reverse-engineering the BIOS (Basic Input-Output System) of the IBM PC in 1984. A market for cheaper IBM-compatible PCs had developed, and Microsoft would happily license a version of MS-DOS for the manufacturer, but to be 100% IBM-compatible, the machines also needed to duplicate the BIOS. IBM had published the full source code of this software in the Technical Reference Manual for its PC model 5150, and successfully sued several companies that had copied this code for their clones (forcing the other companies to settle on terms favorable to IBM). Apple had previously sued other companies successfully for copyright infringement of their BIOS.

What Phoenix Technologies did was have one group of engineers write up a full set of specifications for the BIOS, based on the source code. Then, a different group of engineers, who—crucially—had never seen IBM’s source code, wrote their own new implementation. The first group then checked to see that they hadn’t duplicated any copyrighted code by accident.

As David Siegel correctly notes, if you omit the “Chinese wall” from this process, you are very likely to end up in court, with your lawyers and their lawyers spending years trying to convince a jury that’s never seen a line of source code before in their lives that your software is or is not substantially similar. Whenever you are in that situation, you’ve already lost.

  • All this is true if and only if there is a decent case for substantial similarity. I there is not substantial similarity, then clean-room technique does not matter. The problem is that it is hard to be sure what a court will regard as substantial similarity. But if one applies the Abstraction-Filtration-Comparison test and it comes out negative, that strongly suggests no substantial similarity, and therefor no infringement, clean-room or not. Jun 20 at 21:04
  • 1
    @DavidSiegel You could still win the case, but the purpose of a clean room is that you can often get the lawsuit dismissed.
    – Davislor
    Jun 20 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.