I have done a thorough IP review on my own project in 2007. You can find some info about this project in this slide deck: Startup Legal and IP. I encountered many situations that are similar to what you describe, although none of them were "criminal." These are some examples.
Example 1: code that was proprietary to SUN, later open source by SUN under a friendly license.
In my project, I was using code originally developed at SUN. Some classes of th source code contained comments sections saying This code is confidential and proprietary information of Sun Microsystems, Inc. etc. The code as a whole was released, also by SUN, under a friendly sample license. In short: the code was released with the best of intents, but it accidentally contained conflicting information referring to the original, more strict license.
Verdict of the IP lawyers: it's better to be safe than sorry. I had to remove the code.
Example 2: The RC4 algorithm used to be a trade secret. Then it was anonymously published.
I used the code that implemented the algorithm that was anonymously published. It was considered as part of the public domain, so I was allowed to continue to use it. However, I used a parameter named RC4_ENCRYPTION
, and although it was OK to use the code, I was not allowed to use the name RC4 in a parameter name because the name RC4 was trademarked.
Verdict of the IP lawyers: as I was using the Alleged RC4 algorithm, I had to change the name of the parameter to ARC4_ENCRYPTION
.
Example 3: IntHashtable
by ACME versus IntHashtable
from Apache.
I was using the IntHashtable
class from ACME.com. This class mentioned: This class is 90% based on JavaSoft's java.util.Hashtable. Because JavaSoft's class wasn't available under a friendly license, I was not allowed to use that class. However, I found an IntHashtable
class in Apache-commons that was 99% similar to ACME's IntHashtable
.
Verdict of the IP lawyers: as the IntHashtable
class from Apache was available under the ASL, I was allowed to use it. I replaced the ACME class by the Apache class. It was 99% similar, but the former wasn't acceptable from a legal point of view, whereas the second got the approval from the lawyers.
Example 4: I used a Quick-and-Dirty XML Parser example from a JavaWorld article.
I didn't read the fineprint that said:
All contents of JavaWorld, including text, programs, applets, source code, and images are copyrighted and owned by IDG or the copyright holder specified, all rights reserved. No material may be reproduced electronically or in print without written permission.
In this situation, JavaWorld was like your ACME company, and I was like your Han, although I had no criminal intentions: I was just ignorant. I took copyrighted code from a magazine example, and I released it as open source software. I should have asked permission before I did this.
Verdict of the IP lawyers: ask and get permission. This was a no-brainer. Permission was granted immediately, both by JavaWorld and the author of the article and the code sample.
Summarized:
In your example, Han is doing something that is not allowed: he is publishing copyrighted work as if it were open source software. He can be sued and he will have to pay for all the damages that arise from distributing the code as open source software.
If somebody else, for instance Luke, downloads that software and starts using it, he is doing so in good faith. Usually, Luke won't be sued (or if he's sued, he'll win because he can prove that he didn't know he was doing anything wrong), but this doesn't mean that Luke can continue using that software. Acme can demand that he either stops using the software, or that he gets a license. I'm pretty sure that Luke can also sue Han for the damages, for instance if Luke suddenly has to start paying Acme for his use of the software.
In my case, I removed some code from my code base entirely (see example 1), I made small adjustments (see example 2), I refactored my code (see example 3) or I asked and received permission (see example 4). There is no general rule. It depends from case to case.
Morale: Don't use open source software of which the origin is shady. Try to establish a business relationship with the open source vendor distributing the code. That way, you are protected against situations like this.