One disturbing trend is the posting of FOSS modules without licenses. Simon Phipps focused on this problem in his recent blog, particularly on the problems raised by the terms of service at Github. James Governor, the founder of analyst Red Monk, is quoted by Simon as stating: “”younger devs today are about POSS - Post open source software. f*** the license and governance, just commit to github” http://www.infoworld.com/d/open-source-software/github-needs-take-open-source-seriously-208046. Ironically, this approach will undercut the major desire of most FOSS developers: the broad use of their code. The lack of a license ensures that the software will be removed from any product meant to be used by corporations. Corporations are very sensitive about ensuring that all software that they use or which is incorporated in their products is properly licensed. I have worked on hundreds of FOSS analysis and the response to software without a clear license is almost always “rip it out”.
One other consequence not mentioned by Simon is that the failure to include a license also means the developer (and distributor) have potential liability in the United States under Article II of the Uniform Commercial Code (“UCC”). Article II of the UCC provides that if certain warranties are not “disclaimed” then the distributor (“seller” in UCC language) automatically gives those warranties. These warranties are disclaimed in all FOSS licenses, generally in capital letters and are the source of the provisions using obscure terms such as “merchantability” and “fitness for a particular purpose”. The developer would be liable for these warranties: merchantability (the product is of average quality in the trade), fit for a particular purpose (if the developer or distributor knows of the use by the licensee, then the software will be fit for such purpose) and indemnity (an indemnity for intellectual property infringement such as copyrights and patents). And if such warranties are breached the developer would be liable for “consequential damages” which includes lost profits. While it is unlikely that such suit would be brought, the potential liability for the developer will continue.

In a major change in the law, the Court of Appeals for the Federal Circuit (”CAFC”) held in Transcore v. ETC found that covenants not to sue have the same effect on patent exhaustion as a patent license (i.e. a sale permitted under the covenant not to sue would “exhaust” the patent) http://www.cafc.uscourts.gov/opinions/08-1430.pdf.  

Consequently, a first sale that falls within the scope of a patentee’s covenant not to sue is considered “authorized” and exhausts the patent with respect to downstream customers and users. This holding is dramatically different from the assumptions of most lawyers.  In fact, lawyers frequently use a convenant not to sue rather than a patent license to avoid patent exhaustion. 

This issue is very important for software licensors, both commercial and open source,  because they must now rethink their approach to patent licensing.  For example,  Red Hat used covenants not to sue in its Firestar settlement to cover certain parts of its ecosystem http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf. This decision means that lawyers need to review their existing agreements to see how this change will effect the rights of their clients. They also need to be much more careful about drafting patent agreements. 

Another troubling aspect of the Transcore decision is its finding the covenant not to sue applied to a patent not yet issued at the time of the settlement on the basis of the theory of “legal estoppel.”