Slashdot Mirror
After 20 Years, OpenSSL Will Change To Apache License 2.0, Seeks Past Contributors (openssl.org)
After nearly 20 years and 31,000 commits, OpenSSL wants to change to Apache License v2.0. They're now tracking down all 400 contributors to sign new license agreements, a process expected to take several months. Slashdot reader rich_salz shares links to OpenSSL's official announcement (and their agreement-collecting web site).
"This re-licensing activity will make OpenSSL, already the world's most widely-used FOSS encryption software, more convenient to incorporate in the widest possible range of free and open source software," said Mishi Choudhary, Legal Director of Software Freedom Law Center and counsel to OpenSSL. "OpenSSL's team has carefully prepared for this re-licensing, and their process will be an outstanding example of 'how to do it right.'"
Click through for some comments on the significance of this move from the Linux Foundation, Intel, and Oracle.
Click through for some comments on the significance of this move from the Linux Foundation, Intel, and Oracle.
- "The Linux Foundation is excited to see the OpenSSL project re-licensing under the Apache License. Using a standard and well-understood license is a huge benefit when incorporating a FOSS project into other projects and products... this license move will further help to ensure it remains one of the most important and relied-upon open source projects in the world."
-- Nicko van Someren, Chief Technology Officer, the Linux Foundation
- "Oracle is proud to extend its collaboration with the OpenSSL Foundation by relicensing its contributions of elliptic curve cryptography. OpenSSL is a critical component in both Oracle products and the infrastructure of the Internet, and we strongly believe the increased use of cryptography fostered by OpenSSL will benefit the entire enterprise software community."
-- Jim Wright, Chief Architect of Open Source Policy, Strategy, Compliance and Alliances, Oracle
- "Intel is thrilled to see OpenSSL moving to the standard Apache 2.0 license, improving license compatibility within the Open Source ecosystem. This will help defragment the open source cryptography ecosystem, leading to stronger and more pervasive use of crypto to improve privacy and security in the global technology infrastructure."
-- Imad Sousou, Vice President and General Manager of the Open Source Technology Center, Intel
What was the old license model?
Some of the contributors are upset about the way that this license change is being pushed through. See
http://marc.info/?l=openbsd-tech&m=149028593819547
If you get enough, you can rewrite the remaining bits.
...They're now tracking down all 400 contributors to sign new license agreements...
From what I read, OpenSSL are saying that if you have contributed, and you don't respond to their request to change the license on the code you contributed, OpenSSL will take your code and change the license on your code without your explicit permission.
.
I really hope I am reading it incorrectly, because I would expect better behavior from a security-oriented project. Far better behavior.
It's why the FSF is so very careful that the GPL grants licenses to existing users, and are transitive so that changes are _also_ under GPL and free for publication and modificaiton. It's also why various "you must advertise our name on this software" or "you may not make any changes to this software" have repeatedly proven confusing and dangerous to use.
Of course it won't happen. What's the likelihood that all 400 are still alive and mentally competent after a couple of decades?
Have you ever read the OpenSSL code? I don't think lack of mental competency has ever stopped anyone from contributing in the past.
There are lots of dups in there. So far I've received four different requests to OK the license change under different IDs.
> I'm pretty sure both common law and civil law jurisdictions would side with a contributor who objects after the fact, even if they did get the notice.
If they got the notice, estoppel by acquiescence may apply. "Estoppel by acquiescence" means one may not sue later if you were given a clear opportunity to object and chose to not object in any way. Georgia v. South Carolina is a well-known case. Georgia had legal claim to certain land based on a treaty. For many years, South Carolina treated it as part of South Carolina, levying taxes in the area, etc.Georgia did not object during these many years. Later Georgia attempted to assert their claim to the area. The court ruled that Georgia's failure to object for many years barred the action - their silence was basically implied permission.
A related concept is laches. Laches means you have to assert your rights in a reasonable time frame, or not at all - an author who files suit regarding the license change ten years from now will probably be barred by laches.
How the hell do you re-write something like that? An "if" statement keys on the value of a single variable and conditionally executes a function. There are some things for which there is only one solution. Someone might suggest "just cold-room it!" But how are they supposed to do that?
You mean cleanroom. Copyright protects one particular expression (implementation) not the underlying idea (functionality), so the point is not necessarily to come up with a different solution but to document that it has been done independently. Yes, that means they must find an "untainted" developer to write the new code but you can in great detail describe the functionality as long as you don't impose a particular implementation. It's even been done "after the fact" as evidence:
The court relied heavily on evidence NEC presented that compared a "clean room'' program with both the V20/30 and Intel 8086/88 microcode. NEC hired an independent engineer (Gary Davidian) to develop a set of microcode for the V20/30 without access to any other microcode. Because Davidian's version of the microcode was similar in many regards to both the Intel and NEC microcodes, the court found it likely that those similarities were dictated not by copying of Intel's microcode, but rather by functional constraints of the hardware, the architecture, and the need for 8086/88 compatibility.
The documentation is a pain in the butt, but the legal reasoning around it isn't so bad.
Live today, because you never know what tomorrow brings