Lawrence Rosen submitted a letter to the Federal Trade Commission in response to their request for comments for the upcoming Email Authentication Summit (see 69 Fed. Reg. 55632-36). The Summit isn’t until November 9-10, but written comments were due on September 30. He was kind enough to send me a copy and give me permission to share it with you.
In his letter, he helps the FTC to understand that no spam efforts can work if a goodly portion of the world is not able to use the solution. And if you wish to see some statistics about FOSS use, I heartily recommend reading David Wheeler's "Why Open Source Software/Free Software? Look at the Numbers!", which underlines Rosen's point.
Here is the letter as PDF. His submitted comment relates his experience representing the Apache Foundation, the Free Software Foundation, Open Source Initiative and others in the community in negotiations with Microsoft over the Sender ID licensing dispute, trying to arrive at license terms that would allow everyone to make use of Sender ID. He tells the FTC what the sticky wickets turned out to be that killed a successful resolution. He also explains clearly why open standards must be such that everyone, including the open source community, can use them in order for any effective anti-spam technology to be successful.
September 29, 2004
VIA EMAIL (email@example.com)
Federal Trade Commission
Room 159-H (Annex V)
600 Pennsylvania Ave., NW
Washington, DC 20580
RE: Email Authentication Summit - Comments
I recently attempted to negotiate revisions to Microsoft's patent license for their Sender ID technology on behalf of the Apache Foundation, the Free Software Foundation, Open Source Initiative1 and others in the open source community. My defined goal was to obtain license terms that would be compatible with open source licensing principles and would thus allow open source implementations of Sender ID. As of September 8, 2004, there were only two major issues separating us. (1) Microsoft was refusing to allow sublicensing of their patent license and (2) they were insisting upon separate execution of the Microsoft patent license by every distributor of Sender ID implementations.2 I was asked to remain available on the evening of September 9, 2004, because "management is reviewing a proposal."3 No such proposal came then or ever.
Two weeks later, following several requests for status, Microsoft declared the issue "moot by the working group’s decision to treat PRA and SPF both as optional alternatives and terminate the working group." 4 Microsoft’s statement is misleading and belies that company’s steadfast refusal to alter their patent license to allow implementations under the GNU General Public License (GPL), the Apache License and other important open source licenses.
I will explain why these licensing issues are show-stoppers for open source, and why the Federal Trade Commission should not treat them as moot.
Open source development is a continuous process of software modification and improvement by a worldwide community of developers. Companies and individuals anywhere can contribute code, and companies and individuals anywhere can become distributors and/or users of that code. Most open source licenses are expressly sublicenseable, and the rest are impliedly so. This is intentional. Sublicensing reduces friction in the development and distribution process by allowing each downstream user or distributor to rely exclusively on the grant of rights made by its immediate licensor without having to seek out additional licenses. For software as comprehensive and complex as Linux and Apache, as but two examples, requiring downstream distributors to negotiate additional intellectual property licenses would be impossibly burdensome.
Licensees of open source software expect that they have sublicensed the rights to all intellectual property necessary to make, use, sell, offer for sale, have made, import, or otherwise externally distribute that software, and the open source software market behaves accordingly.
The Apache License, for example, acknowledges that process by expressly stating that its copyright and patent grants are sublicenseable.5 Similar provisions are in the GNU General Public License (GPL), the IBM Public License, the Mozilla Public License and the Sun Public License, among many others.6 Of course, none of these licenses purport to grant rights to patent claims the licensor doesn’t own or control, and so unanticipated third party patent rights may ultimately take precedence over an open source license. But absent those suddenly-appearing third party patents, open source software is expected to be free of known intellectual property encumbrances that would limit or restrict the freedom for any open source licensee to make, use and distribute copies and derivative works.
The Academic Free License (AFL) and Open Software License (OSL) are even more explicit, offering a specific "warranty of provenance" that "the copyright in and to the Original Work and the patent rights granted herein by Licensor are owned by the Licensor or are sublicensed to You under the terms of this License with the permission of the contributor(s) of those copyrights and patent rights." 7
Microsoft’s proposed Sender ID patent license is incompatible with these open source licenses because it is not sublicenseable.
Proprietary software vendors are well aware of the value to their customers of obtaining sublicensing rights when they in-license software. For example, nobody would accept Windows or Microsoft Office if Microsoft’s authorized distributors had to seek out additional patent license rights from Microsoft’s suppliers.
Despite repeated requests that they do so, Microsoft has refused to provide any rationale for its refusal to allow sublicensing of their Sender ID patents. Microsoft has already agreed not to charge royalties, so there could be no direct financial motive. The limited scope of their license already protects them from uses broader than specified in their "Caller ID for Email" proposal, so they cannot possibly be afraid of anyone using their patents for purposes other than email authentication. Furthermore, since sublicensing does not nullify or render unenforceable the reciprocity and defensive termination conditions in Microsoft’s patent license, they will have no difficulty later taking action against companies that breach those license conditions, or alternatively, if and when the need arises, dealing with such companies as infringers.
The open source community cannot accept the insertion of additional licensing friction into the open source development and distribution process, particularly when there is no legitimate business purpose served by doing so.
Microsoft’s proposed Sender ID patent license unnecessarily distinguishes between "End Users" and "Distributors" of software. As I described above, this is inconsistent with open source principles which envision that anyone can become a user or distributor of open source software without seeking additional permission to do so.
Microsoft’s patent license then requires all Distributors, but not End Users, to execute Microsoft's license and thus to notify Microsoft of their intention to implement Sender ID applications.
This requirement to execute an additional license is expressly prohibited by item 7 of the Open Source Definition, which sets the rules for open source licenses: "The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties."8
Open Source Initiative has consistently rejected any proposed open source licenses that required licensees to notify a licensor of anything at all. The freedom to create and distribute copies or derivative works of open source software includes the right to do so in private.
Microsoft has provided no rationale for this requirement of their license.
In your notice of the Email Authentication Summit you identified several important reasons why effective spam control technology is in the national interest. The open source community concurs, and members of the Apache Foundation and others in our community have participated diligently in the IETF standard-setting process. But this technology will only be successful if it can be implemented in open source software consistently with open source licensing principles.
This requires an open standard, a term that should be reserved to describe standards that are available to everyone, including the open source community, to implement without royalty requirements or other unacceptable patent license terms and conditions.
Patent licenses, to be compatible with open source, must satisfy the following open standards principles. I note that Microsoft’s patent license for its Sender ID technology could easily satisfy these principles if that company allowed sublicensing and removed the unnecessary requirement for actual execution of a license. I sent them specific proposals for changed wording in their license to allow it to conform to these open standards principles, but they never sent me a new proposal of their own despite continual email correspondence with them for more than a month.
Open Standards Principles
1. Everyone is free to copy and distribute the official specification for an open standard under an open source license.
2. Everyone is free to make or use embodiments of an open standard under unconditional licenses to patent claims necessary to practice that standard.
3. Everyone is free to distribute externally, sell, offer for sale, have made or import embodiments of an open standard under patent licenses that may be conditioned only on reciprocal licenses to any of licensees' patent claims necessary to practice that standard.
4. A patent license for an open standard may be terminated as to any licensee who sues the licensor or any other licensee for infringement of patent claims necessary to practice that standard.
5. All patent licenses necessary to practice an open standard are worldwide, royalty-free, non-exclusive, perpetual and sublicenseable.
Lawrence E. Rosen
I currently serve as general counsel and secretary of Open Source Initiative and have represented many software companies and open source projects. This letter contains my own opinions and does not reflect the official positions of any of the organizations mentioned herein.
2 Emails between Michele Herman of Microsoft and Lawrence Rosen dated September 8, 2004.
3 Email from Michele Herman dated September 9, 2004.
4 Email from Michele Herman to Lawrence Rosen dated September 23, 2004.
5 Apache License, version 2.0, January 2004, sections 2 and 3.
6 The text of all open source licenses referred to in this letter are published at http://www.opensource.ort/licenses
7 Academic Free License (AFL) and Open Software License (OSL), version 2.1, section 7.
8 See http://opensource.org/docs/definition.php.