Discouraging Forks: Sun s SISSL

Discouraging Forks: Sun's SISSL

Sun Microsystems wanted a more robust way to prevent the standard from being forked. Forking is a colloquial term used in the open source community to describe what happens when a cooperative project splits into two or more uncooperative separate projects. The result is either an opportunity or a problem, depending partly on whether you're the project being forked from or to, and partly on the ultimate success of the forked project's software in the marketplace . One of the risks of permitting derivative works of industry standard specifications and test suites is that competitors may move away from the standard. As I just described, The Open Group Test Suite License avoided that by requiring notice and documentation of such changes, and it prohibited calling derivative works the Standard Version . But that's only partially effective. Companies can diverge from the standard, or add new requirements, without having to return those contributions to the open standard.

An open source license cannot prohibit forks. (Refer to Open Source Principle # 3, which mandates the freedom to create derivative works.) But the license can set conditions, including a reciprocity condition, on such derivative works.

The Sun Industry Standards Source License (SISSL) is patterned largely on the MPL, with its emphasis on files rather than the broader concept of derivative works. (The full text of the SISSL is available at www.opensource.org .) You will recognize much of the MPL's structure, with this interesting addition to the reciprocity condition.

The Modifications which You create must comply with all requirements set out by the Standards body in effect one hundred twenty (120) days before You ship the Contributor Version. In the event that the Modifications do not meet such requirements, You agree to publish either

(i) any deviation from the Standards protocol resulting from implementation of Your Modifications and a reference implementation of Your Modifications or

(ii) Your Modifications in Source Code form, and to make any such deviation and reference implementation or Modifications available to all third parties under the same terms as this license on a royalty free basis within thirty (30) days of Your first customer shipment of Your Modifications. ( SISSL license section 3.1.)

Like all reciprocity provisions in open source licenses, the SISSL requires no more of the licensee than the licensor already gave. It permits forks of the standard, but any Modifications that break compatibility with the standard will be available on a reciprocal basis for all to adopt. It also imposes timing constraints on the creation of derivative works that allow the standards organization ”in this case Sun Microsystems ”an opportunity to react to attempted forks.

Sun uses the SISSL license for the file format and application programming interface specifications of its version of Open Office software, and the GPL for the Open Office software itself.