A hard problem

Simon Phipps proposes a hard problem: expanding the definition of "open source" to include patents.

The easy part is dealing with any patents that are actually licensable by the person or company who is licensing the code. To get to a new "definition" you could say that copyright licenses that don't also grant a patent license must be accompanied by a patent license grant.

If you want an "open source definition" for patent grants, you can start with an approved software license and work out from there: an approved patent grant is one that permits any activity permitted by the software license. See the RTLinux patent license for a good example.

Now comes the hard part: patents that belong to someone other than the copyright holder of the software. You could license your own work under an unambiguously free license and still have patent problems and make patent problems for others. For example, at least one open source implementation of PPP included BSD compression, which infringed the now-expired Unisys LZW patent.

It would be great to have a set of guidelines that would reduce the risk from monkey business with patents. But drawing those guidelines means you have to think about the same kinds of use cases that a standards organization has to think about when setting its patent policy. You can't just copy the W3C, though, because you can't just allow implementation in compliance with one or more standards.

Here are a few open source and patent interactions that the guidelines would have to address.

Patent holder A allows a patent to be used in software that implements a standard. Developer B releases code, under an approved license, that implements A's patented technique and complies with the standard. Developer C borrows B's code, and in compliance with B's license, develops software that does something different, not covered by A's patent grant. Distributor D redistributes C's code, and A sues D for patent infringement. Should a new "definition" require B or C to disclose A's patent, if they're aware of it?

Patent holder E does not license a patent. Developer F writes software that implements E's patented technique, but F works and hosts code in a jurisdiction where E's patent is not enforceable, for whatever reason. If F is aware of the patent, but distributes the code to users in a juridiction where it applies, would F's software still fall within the new "definition?"

G releases a patent under a permission letter that ceases to apply if the user sues G for anything. H writes a program that implements G's patented technique. J holds a patent that it implements in GPL software, making it available under an implied license. Can H implement J's patent in the same software that implement's G's patent?

The trademark problem is different. On one hand, you have the spyware clowns, who would release privacy-violating contaminated copies of "Firefox®" for Microsoft Windows if they got a chance. The software license lets them do it. All that's preventing it is that they're not allowed to call it "Firefox." On the other hand, you have Debian, which is run by free software nit-pickers who won't release software without permissions to modify that the Firefox trademark holder won't give because of the spyware clowns.

Debian's license nit-picking is a strength from the point of view of developers who rely on it. Using something that's been through the arguments on debian-legal means it's less likely to come back to bite you if you make some unpredictable use of it later. And giving the Mozilla Corporation the right to take down spyware-infected copies of Firefox helps with the goal of making a reliable direct-download product for people who don't get all their software by apt-get from a cryptographically verified source.

Two incompatible goals, so we will never have "open source trademarks."