Location: United States
Given that copyright does not protect ideas
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.
"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.
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.
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.
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.
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.
