Friday, July 21, 2006
OSI and the Eiffel Forum License
The Open Source Initiative is "a non-profit corporation dedicated to managing and promoting the Open Source Definition". One of the things they do is to certify software licenses as open-source, which means that the license complies with OSI's Open Source Definition.
OSI certification became important for getting software accepted into open source software distributions such as Debian Linux. Although the Eiffel Forum Freeware License pre-dated OSI by a few years, it became desirable to get them to certify the EFFL as an open-source license. This took a few years of bureaucratic haggling with OSI, but we got there in the end.
Later, the Eiffel Forum License version 2 was created. It was more liberal than the EFFL, so that EFL2-licensed software could be incorporated into GPL-licensed projects. Unlike the EFFL, the EFL2 is pretty similar to the liberal MIT and BSD licenses. The Free Software Foundation confirmed that the EFL2 was GPL-compatible, and OSI certified it as "open source".
For the last year or so, OSI has been pondering the proliferation of open source software licenses. One downside of having so many licenses is that it can hinder software re-use. There are two reasons for this. The first reason is that licenses sometimes have incompatible terms, and software covered by them cannot be legally combined.
The second problem hindering re-use of software covered by many difference licenses is that many organizations are cautious by nature and feel unable to use software under a new license until their lawyers have checked it out at great expense. Clearly, this problem is compounded by the sheer volume of open source licenses that now exist.
It's no surprise that OSI has concluded that the ELF2 license is redundant. This doesn't mean that the EFL2 will lose its open-source certification, it just means that OSI thinks the license is not a useful alternative to other more popular licenses.
Berend de Boer has opened a discussion about this on the NICE-Discuss mailing list. He writes:
OSI certification became important for getting software accepted into open source software distributions such as Debian Linux. Although the Eiffel Forum Freeware License pre-dated OSI by a few years, it became desirable to get them to certify the EFFL as an open-source license. This took a few years of bureaucratic haggling with OSI, but we got there in the end.
Later, the Eiffel Forum License version 2 was created. It was more liberal than the EFFL, so that EFL2-licensed software could be incorporated into GPL-licensed projects. Unlike the EFFL, the EFL2 is pretty similar to the liberal MIT and BSD licenses. The Free Software Foundation confirmed that the EFL2 was GPL-compatible, and OSI certified it as "open source".
For the last year or so, OSI has been pondering the proliferation of open source software licenses. One downside of having so many licenses is that it can hinder software re-use. There are two reasons for this. The first reason is that licenses sometimes have incompatible terms, and software covered by them cannot be legally combined.
The second problem hindering re-use of software covered by many difference licenses is that many organizations are cautious by nature and feel unable to use software under a new license until their lawyers have checked it out at great expense. Clearly, this problem is compounded by the sheer volume of open source licenses that now exist.
It's no surprise that OSI has concluded that the ELF2 license is redundant. This doesn't mean that the EFL2 will lose its open-source certification, it just means that OSI thinks the license is not a useful alternative to other more popular licenses.
Berend de Boer has opened a discussion about this on the NICE-Discuss mailing list. He writes:
Minimising licenses is obviously a good goal and it helps code sharing. On the other hand everyone knows the Eiffel Forum License and many in the Eiffel community use it.You may wish to hop over there to post your comments.
posted by Roger Browne @ 12:17 
Comments:
<< Home
There are pros and cons. For the Eiffel community it is better to have the Eiffel Forum License because it is easier to identify itself.
On the other hand some people have mentionned in the past that having Eiffel as part of a library name is not a good thing because it shows it has been made in Eiffel rather than showing the quality of the library. Could it be the same with the license?
On the other hand some people have mentionned in the past that having Eiffel as part of a library name is not a good thing because it shows it has been made in Eiffel rather than showing the quality of the library. Could it be the same with the license?
Adamsits: see the links to the "MIT" and "BSD" licenses in the article above. They are both corporate-friendly open source licenses like the EFFL2.
Also note that SmartEiffel has recently switched from its own library license to the MIT license for all of its libraries (the compiler remains GPL).
Also note that SmartEiffel has recently switched from its own library license to the MIT license for all of its libraries (the compiler remains GPL).
Roger,
In your opinion, do the MIT or BSD licenses resolve the issue of the C code being a derived work that must maintain the same license?
In your opinion, do the MIT or BSD licenses resolve the issue of the C code being a derived work that must maintain the same license?
adamsits, I think originally the Eiffel license was just branding. And note we made a change between version 1 to 2 to make it OSI compatible.
So perhaps originally it wasn't equal to BSD, and perhaps unintentionally so. When we moved to version 2 it became equal to BSD.
To me, at this moment the Eiffel Forum issue is just branding. That could be a good enough reason to keep it.
So perhaps originally it wasn't equal to BSD, and perhaps unintentionally so. When we moved to version 2 it became equal to BSD.
To me, at this moment the Eiffel Forum issue is just branding. That could be a good enough reason to keep it.
Brian,
The MIT license completely solves the licensing problems associated with distributing a C page produced by an Eiffel compiler from MIT-licensed Eiffel source code.
That's because the MIT license only requires the copyright notice to be included "in all copies or substantial portions of the software". Clearly, the translated C code is a derived work, not a "copy of the software".
On the other hand, the BSD license is not so clear on this point. It requires you to include the copyright notice in redistributions of source code (with or without modification). If the license had referred to "redistributions of the source code" rather than "redistributions of source code" I think we would be OK with the BSD license too.
The problem of course is that an Eiffel compiler (such as SmartEiffel) does not include the copyright text when it generates a C package. You could cut-and-paste this yourself, but it's simpler just to use the MIT license.
The SmartEiffel team kindly switched to the MIT license to help me out here, and I encourage anyone else who wants to see maximum use of their software to also use the MIT license (dual-licensed with another license if they like).
The MIT license is also shorter and more readable than the BSD. I'm not aware of any reasons to prefer the BSD.
The MIT license completely solves the licensing problems associated with distributing a C page produced by an Eiffel compiler from MIT-licensed Eiffel source code.
That's because the MIT license only requires the copyright notice to be included "in all copies or substantial portions of the software". Clearly, the translated C code is a derived work, not a "copy of the software".
On the other hand, the BSD license is not so clear on this point. It requires you to include the copyright notice in redistributions of source code (with or without modification). If the license had referred to "redistributions of the source code" rather than "redistributions of source code" I think we would be OK with the BSD license too.
The problem of course is that an Eiffel compiler (such as SmartEiffel) does not include the copyright text when it generates a C package. You could cut-and-paste this yourself, but it's simpler just to use the MIT license.
The SmartEiffel team kindly switched to the MIT license to help me out here, and I encourage anyone else who wants to see maximum use of their software to also use the MIT license (dual-licensed with another license if they like).
The MIT license is also shorter and more readable than the BSD. I'm not aware of any reasons to prefer the BSD.
Berend,
Branding was not a driving force behind the original Eiffel Forum license; interoperability was.
It was a fine balance between library authors who used liberal licenses such as MIT/BSD, and those who felt they tipped the balance too far in favour of commercial users of libraries.
The compromise was the Eiffel Forum Freeware License with its provision that if you distribute binaries whose source includes EFFL-licensed code, then you must redistribute any modifications you made to that EFFL-licensed code.
In that regard, the EFFL had a similar effect to the LGPL, but we couldn't find a sensible way to apply the LGPL to the Eiffel compilation model (the LGPL talks about object libraries, header files, etc).
The EFFL was a great success, because from that point on most Eiffel library authors used it for their releases.
Although the EFFL was drawn up with the intention of being GPL-compatible, the Free Software Foundation didn't feel that it was. The "mandatory source redistribution" requirement was stronger than the corresponding requirement in the GPL.
So the EFL2 was drawn up. The FSF was satisfied, and the EFL2 in turn became a successful license.
But in the process, the EFL2 had become virtually equivalent to MIT/BSD.
I wouldn't want to keep a distinct license just for "branding". In my opinion, "obvious interoperability" offers greater benefits than branding.
Branding was not a driving force behind the original Eiffel Forum license; interoperability was.
It was a fine balance between library authors who used liberal licenses such as MIT/BSD, and those who felt they tipped the balance too far in favour of commercial users of libraries.
The compromise was the Eiffel Forum Freeware License with its provision that if you distribute binaries whose source includes EFFL-licensed code, then you must redistribute any modifications you made to that EFFL-licensed code.
In that regard, the EFFL had a similar effect to the LGPL, but we couldn't find a sensible way to apply the LGPL to the Eiffel compilation model (the LGPL talks about object libraries, header files, etc).
The EFFL was a great success, because from that point on most Eiffel library authors used it for their releases.
Although the EFFL was drawn up with the intention of being GPL-compatible, the Free Software Foundation didn't feel that it was. The "mandatory source redistribution" requirement was stronger than the corresponding requirement in the GPL.
So the EFL2 was drawn up. The FSF was satisfied, and the EFL2 in turn became a successful license.
But in the process, the EFL2 had become virtually equivalent to MIT/BSD.
I wouldn't want to keep a distinct license just for "branding". In my opinion, "obvious interoperability" offers greater benefits than branding.
Google just announced their free project hosting service (a kind of streamlined SourceForge):
http://code.google.com/hosting/
The only licenses they allow are Apache, Artistic, GPL, LGPL, MIT, MPL, BSD.
Maybe it's time to encourage EFL2 users to switch to (or dual-license with) MIT.
http://code.google.com/hosting/
The only licenses they allow are Apache, Artistic, GPL, LGPL, MIT, MPL, BSD.
Maybe it's time to encourage EFL2 users to switch to (or dual-license with) MIT.
BTW, the full report is here: http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:11636:200607:nknhhdligldemhkfbhpd
See legal feedback on new post:
http://teameiffel.blogspot.com/2006/08/feedback-from-osi-legal-affairs.html
Post a Comment
http://teameiffel.blogspot.com/2006/08/feedback-from-osi-legal-affairs.html
<< Home
