The most important issue is buried in the middle. Patent exhaustion applies to one specific instance of a patented item. The idea is that, when you sell a physical product, it should flow through the stream of commerce unencumbered by any patent rights held by the seller of the item. (Hence the landmark case Lexmark v. Impression Products, which held that contractual arrangements between the seller and buyer could not limit the scope of the exhaustion as to downstream purchasers of that item.)
When applied to software, the question is what is the "item" to which exhaustion applies? In the closely related context of first-sale doctrine for digital files, the Second Circuit has held that the first sale doctrine does not apply to digital copies: https://en.wikipedia.org/wiki/Capitol_Records,_LLC_v._ReDigi.... By analogy, patent rights might be exhausted as to a copy of the software downloaded from the patent holder. But it wouldn't apply to copies of that copy, or to derivative works. (And that makes sense--the point of exhaustion law is to give you unfettered right to use and resell the thing you bought; not recreate it distribute it to more people.)
Open source licenses add an interesting wrinkle to that: what if making copies and derivative works is authorized by the copyright license? Does the exhaustion follow those copies? The article makes a case for "yes," and I'll make the case for "no." A copyright license is a contract.Lexmark v. Impression Products tells you that the contractual arrangement between the patent holder and first buyer does not affect the scope of exhaustion. That's a double-edged sword. You can't limit the scope of exhaustion through license restrictions. (E.g. "you can only use this software for personal use" may be enforceable as a matter of contract, but exhaustion probably applies to the first buyer even if they use that copy for commercial use.) But on the flip side, you can't broaden the scope of exhaustion--making it "viral"--through the copyright license either.
since it's my article, I'll strengthen the case for "yes". I won't get into contract vs licence because that's also highly controversial, but I can argue without settling that.
The question you're asking is how the unexhausted patent right to exclude manufacture interacts with the copyright rights to reproduce (copy) and derive. I made a couple of arguments for this in the article, but I think the strongest one is public policy. If you can restrict copying and derivation using the patent right to restrict manufacture then we have a huge problem in the copyright ecosystem because patents have no fair use doctrine. That means every copy you make, including from your software disk to your hard drive and every time you load the bits from your hard drive into memory requires a new permission to manufacture under the patent. That gives patent holders carte blanche to hold software purchasers to ransom. This would be a huge disruption to an existing area of well settled law.
The same goes for the copyright right to derive. If that requires a patent licence, then even after I licence a patent for some proprietary SW purpose, I'm required to pay again for every change I make, including bug fixes which are some of the most common things software is updated for. Not quite as huge, but still a disruption to a well settled area of law.
A contract obviously can't contradict the law, but can grant rights that don't contradict the law. If the contract grants rights to copy, modify and distribute, then they are granted (usually irrevocably), the grant of rights doesn't contradict law.
Of course, as a matter of contract law, you can grant a license to use your patents to anyone who uses your open source product under the terms of your chosen license. The question here is whether, by making your software available as open source, your patent rights are exhausted in any copies of that software, even in the absence of such a patent license.
What Impression Products says is that the contractual arrangement between buyer and seller doesn't matter. Exhaustion is something that arises by virtue of patent law when a specific item is sold into the stream of commerce. In theory, that should work both ways. You can't use the software license to narrow the scope of patent exhaustion, and by the same token, just because the license gives you a broad right to copy the software, that shouldn't have any bearing on the scope of exhaustion.
(* This is all assuming that exhaustion even applies to software. Impression Products has an interesting line, where it distinguishes patent licenses, where you can impose restrictions on the scope of the license, from sales of patented products, where you cannot: "Because the patentee is exchanging rights, not goods, it is free to relinquish only a portion of its bundle of patent protections." Patent exhaustion is really bound up in this ancient idea of the law disfavoring "restraints on alienation." That is to say, you can't sell someone a piece of land, but only on the condition that the land can't be resold. Software, however, is generally licensed and not sold, and that includes software under open source licenses. The GPL v.2, for example, states:
> However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.
If receiving a copy of GPL'ed software as considered a "sale" the above wouldn't be true. Under the first sale doctrine, you are entirely free to modify a purchased copy of a copyrighted work free of any further restrictions from the copyright owner. E.g. cases have upheld the right of buyers of art to create a derivative work by cutting it up and mounting the pieces on tiles. And, in theory, you should be able to resell your modified copy of the work too.
Impression Products strongly suggests that, where you're talking about receiving licenses to use, copy, and create derivative works of software, rather than sale of a physical good including software, there is no patent exhaustion.)
Exhaustion has too narrow scope anyway, you can safely assume that patent rights are not exhausted for the purpose of open source. But in addition to rights you have obligations per the contract, and if the contract grants rights to the consumer, those rights are guaranteed.
> The precedent for Open Source is quite clear: Patents cannot be used to impose onward conditions that the copyright licence doesn’t.
Does this mean that MongoDB and others who have changed their licenses to be "everyone but cloud providers can do this for free" is not able to do that because the work has been presumably licensed?
I'm currently working on an externally modular keyboard with standardized modules. It relies on the open source Arduino IDE, Visual Studio Code (Open Source), and the electrical designing was entirely done in KiCAD, but the mechanical bits themselves were designed in Solidworks and Inventor. Is patenting my work okay? What parts? The individual parts themselves are nothing new (RS-485, microcontrollers, Cherry switches [patent expired], NeoPixels, and a ton of adapted example code). I like the idea of Open Source, but at the same time I don't want to get stuck maintaining the code forever without profiting from it (I would love to do it for free, but like the analogy of paid-for LiveCD's, I still need a truck to move the sand around in, and lunch would be nice. What do I do?
Sell the hardware for profit, give away the design files under an open source license. Assembled ready-to-run hardware is a serious value add on top of an open-source hardware design. A strongly built brand should also be valuable in such a niche. So I'd look mostly towards trademarking of the brand as IP protection mechanism for such a project.
In hardware, the design alone may be worth next to nothing. The ability to produce something at volume with a constant quality often depends on knowledge, experience, tooling or other resources that are not present in any design documentation. Sometimes, it is not even possible to replicate these things.
You are right that manufacturing is tricky. Supply chain management and Quality Assurance are complex topics that alone can be full-time jobs to stay on top of, and can take a lot of work to replicate for potential competitors. It is an area that is vastly underestimated by most Kickstarters.
At least those that don't operate in a very similar space, and have already invested this time.
But even then parts are often designed for a particular manufacturing process or supplier (though it is said that best practice is to always have multiple suppliers for any given part).
However for the PCB part of electronics, this has become a lot simpler the last 5 years. There are now many excellent and very affordable manufacturers that will do between 10-1000 boards (assembled & tested), available by just registering an account online.
But manufacturing of enclosures, cables/interconnects, final assembly is still a tedious, hands-on process for the buyer.
PCBs and CNC milled or 3d printed parts are a bit of an exception in that the processes and services are stadardized enough that replication is not that hard unless something really crazy is going.
But everything that relies on more traditional mass production methods (injection molding, casting, ...) is much more dependent on the actual execution of the manufacturing process and the part designs will generally accomodate that, for example by avoiding certain geometries or incorporating ways to account for manufacturing tolerances during assembly.
I am not an engineer myself, but I had to work with mechanical engineers occasionally and I learned that the amount of work that goes into making some seemingly simple parts manufacturable at scale and at cost can be surprising.
I'll reply on the assumption you posted the above in good faith. The article is talking about patents, not copyright and it's important to distinguish between the two. I didn't read the article in detail, but basically it's saying that if you allow Alice to use a patent in a piece of software and you allow Alice to distribute that software to Bob, that you can't now come after Bob for using the patent in the piece of software -- because the patent has "exhausted". I'm not entirely sure this will hold up of Bob makes a derived work of the software, but I suppose it might. It's an interesting thought.
Anyway, on to your questions, which seem to have little to do with the article: "Does this mean that MongoDB and others who have changed their licenses to be 'everyone but cloud providers can do this for free' is not able to do that because the work has been presumably licensed?"
No. They can make any kind of copyright license they want. There is no exhaustion for copyright. Just because I grant Alice a license to the software doesn't mean that I have to allow Alice to give it to Bob. In fact, I can make a license that forbids Bob explicitly, but allows Cathy to get a copy. I can even write a license that disallows people who look like Bob (unless that is discrimitation in a protected category) from getting a licence from Alice.
Incidentally, I could do that with a patent as well, but the situation they are talking about is Open Source licenses. Open Source licenses are, by definition, licences that do not allow you to restrict who Alice can distribute the software to. MongoDB people would like to redefine what Open Source means, but until they do, their license is not Open Source.
Question 2: [I am building a hardware/software project that relies on Open Source software]. "Is patenting my work okay? What parts?"
You can patent any parts of your project that you want. However, some of the software included in Arduino contains a patent licence. Your software may or may not use that software. Pay attention to the license that you use for your software. If you are using a license like the GPLV3, then you are granting a patent license with the software. So this means that if the software contains patented parts, you are granting a license to the downstream user for that patent. If you don't want to do that, then don't choose that license. If you are choosing that license because you it allows you to cheaply use software that other people have written, then too bad for you. You'll have to write that software yourself. That's the price of the software: take it or leave it. It's your choice.
Now, with respect to the suggestion in the article: if you choose to write your software using an Open Source license that does not have a patent grant, will you end up essentially giving a patent grant due to patent exhaustion. Maybe. I'm not a lawyer, but it's an interesting possibility. Again, same advice: if you don't want to, then don't. But don't complain that your non-Open Source options are too expensive.
When applied to software, the question is what is the "item" to which exhaustion applies? In the closely related context of first-sale doctrine for digital files, the Second Circuit has held that the first sale doctrine does not apply to digital copies: https://en.wikipedia.org/wiki/Capitol_Records,_LLC_v._ReDigi.... By analogy, patent rights might be exhausted as to a copy of the software downloaded from the patent holder. But it wouldn't apply to copies of that copy, or to derivative works. (And that makes sense--the point of exhaustion law is to give you unfettered right to use and resell the thing you bought; not recreate it distribute it to more people.)
Open source licenses add an interesting wrinkle to that: what if making copies and derivative works is authorized by the copyright license? Does the exhaustion follow those copies? The article makes a case for "yes," and I'll make the case for "no." A copyright license is a contract. Lexmark v. Impression Products tells you that the contractual arrangement between the patent holder and first buyer does not affect the scope of exhaustion. That's a double-edged sword. You can't limit the scope of exhaustion through license restrictions. (E.g. "you can only use this software for personal use" may be enforceable as a matter of contract, but exhaustion probably applies to the first buyer even if they use that copy for commercial use.) But on the flip side, you can't broaden the scope of exhaustion--making it "viral"--through the copyright license either.