About OSF
 What We Do
 Who We Are
 Contact Info

 FIPS 140-2
 Data Archives

OpenSSL Software Foundation, Inc.

OpenSSL FIPS Object Module 3.0 "Truly Open or Bust" licensing

Selected parts of new FIPS module code are going to be temporarily released under an odd new license we're calling a "truly open or bust" license. This license will be an "anti-open source" license (or un-license) that basically says the code cannot be used in any practical commercial context. Formally this takes the form of the usual "all rights reserved" copyright statement in selected source code files as found in proprietary software:
© 2016 OpenSSL Software Foundation. All Rights Reserved.
However, source code is usually only seen by geeks and not lawyers, and there is some risk that coders may obliviously assume all OpenSSL related source code falls under the conventional OpenSSL open source license. So we embellish the one line copyright statement with some cautionary text:

/* ====================================================================
 * © 2016  OpenSSL Software Foundation.  All Rights Reserved.
 *                The "Truly Open or Bust" un-license
 * Redistribution and use in source or binary forms, with or without
 * modification, is expressly NOT permitted.
 * WARNING: the contents of this file are not available under the
 * OpenSSL open source license, and cannot be used without permission
 * of the copyright holder (which is not currently granted, see
 * http://openssl.com/fips/licensing.html for an explanation of the
 * reason for this restrictive "Truly Open or Bust" licensing).
 * ====================================================================

Bluntly put, the basic function of this "TOoB" license is to deliberately screw up the new FIPS module licensing, while the open source based validation of that code is pending. Once that's secure (or we give up or decide we want to for other reasons) that code will be moved under the same license (APLv2 or whatever) as the rest of the OpenSSL code.

We want to do this to prevent commercial vendors from grabbing the code, getting their own proprietary validations faster than we can (because they have more money to pour into it and because the Open Source Software (OSS) based validations are much harder, even for identically the same code), and then actively lobbying to block the still pending OSS validation. That is not just a theoretical risk; prior open source based validation met with some persistent and almost successful opposition by special interests. The FIPS module source code is not really "open" if it can't be used for its only useful purpose, deployment in an environment that requires FIPS 140-2 validated status. If the FIPS module source code is "open source" but only expensive proprietary validations based on that code are available, then it isn't "Truly Open".

By not releasing all of the new FIPS module code under an open source license until an open source based validation is available to everyone at no cost, we hopfully reduce the incentive for proprietary vendors to oppose that validation. That is the "or Bust" part of the license.

Note a commercial vendor would typically just keep such code as a trade secret. But we want the code to be public as it's written so that interested stakeholders can review and test it. We have already been in touch with a number of major stakeholders willing/eager to do that, under the "TOoB" license.

For previous validations we released the code as open source as we went, but each of those had one or more U.S. government sponsors advocating within the US government bureaucracy for a successful outcome. This validation will be the first without such political cover and patronage, and would likely fail (for us and the OSS community) without some other sort of counter-balancing factor. Vendors wanting to do proprietary validations can't (legally) just immediately clone our code for those validations and thus will have an incentive for the OSS validation to succeed (at which point we move everything under the OpenSSL license and they're welcome to do proprietary knockoffs as before).

Note the validation sponsor, SafeLogic, will be prevented along with everyone else from leveraging the new FIPS code until (and if!) the OSS validation succeeds, thus nicely aligning their incentives with ours. They run the non-trivial risk that they pay for development and attempted validation of code that never becomes available for their use (in practice we'd release the code once we were sure the OSS validation was an irretrievable dead end, but that would be entirely our choice and would doubtless take a long time).

It's an unusual strategy (and unusual sponsorship by SafeLogic), for sure.

This site Copyright © 2009-2016 OSF.