Hi Frank, Gary, community,
Vibrans, Frank wrote:
The Open Source Review Board of AMD has decided the upcoming release of Agesa and the chipset CIM modules for our Family14h CPU will be under a dual license: GPLv2 and BSD.
I think this is great news! AMD has consistently been the best hardware choice for systems where an open firmware makes a big difference and this development will make sure that the most modern AMD hardware will work exceptionally well with coreboot. I think this is very exciting indeed, and I want to express my appreciation and gratitude to the Board who made this possible! THANK YOU!
As the coreboot community, do you have any issue with this? If not, are there any specific coreboot requirements that must be met because of the dual license scheme? Thanks for your help.
I don't think requirements is the right word, but there are indeed some points to consider about cooperation between the coreboot community and the team(s) within AMD that are related to the codebase. This may warrant some discussion.
There are also some points about the licensing itself, though they are simpler to deal with because the licenses have clear requirements;
It is perfectly fine to include a code release into coreboot which is dual licensed GPLv2 and BSD. But it is important to remember that from the point that it is included in coreboot, the copy of the release that exists within coreboot will be licensed *exclusively* under GPLv2. As long as the code does not change, this is at most a technicality.
But if the released code that is included in coreboot is changed within coreboot, because the community sees some opportunities to improve coreboot overall by doing so, then those changes are also licensed exclusively as GPLv2. This means that those changes can not be included "back" into the original dual licensed codebase, or into any derivative which chose to use either the dual license or the BSD license.
This may or may not be a problem, for AMD and for the coreboot community, because in the worst case there could be a significant contribution which is under an open license, but which can not legally be included by some users of the original code release.
I guess it is up to AMD to decide, and I would not be at all surprised if this has already been considered by the Open Source Review Board.
Another result from changes made to the released code as included in coreboot is that the code included into coreboot might become a de facto fork of AMD's source code, depending on how AMD will continue to work on the code internally. This could also lead to a situation where an important improvement (by AMD) that has been based on the released code can not benefit coreboot, and others who include the released code and distribute it under GPLv2.
This is also only a potential problem, depending on the interfaces involved in including the released code into coreboot, and again on the way AMD will continue to improve the released code.
The above all assumes that the released code will be linked into coreboot. A file in CBFS with certain criteria for the interface between coreboot and the file is not considered linking today; e.g. payloads can have any license, like option ROMs, and files such as the VSA infrastructure for AMD Geode.
If the AGESA codebase is ran by AMD as an open source project of it's own, and there was a clear interface between coreboot and AGESA, then I believe the points I mention above would all be moot.
I hope I managed to add some useful thoughts here.
Rudolf Marek wrote:
Please do you know what kind of BSD license it is? The "two clause"/"three clause"?
This is a good question. Two clause/three clause/advertising clause refers to the number of conitions listed in the license.
"BSD two clause" is the most permissive license, with only two conditions:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
"BSD license" without further qualifiers usually means three-clause:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
And finally there's "BSD four clause", or "BSD with advertising clause":
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
I'm perfectly fine with GPLv2.
In fact this is the only choice if the code should be linked with coreboot.
However for dual licensing scheme some kind of policy of what changes are under what license must be adopted/developed.
See my points above. I believe that as soon as the released code is included into the coreboot project (if that is done! the code can also remain outside the coreboot project) that copy of the code can only be GPLv2 from then on.
Most likely we can assume what linux kernel folks are doing (and avoid kind of flame wars in this topic).
Yes, I hope we can ignore any flaming, but there are some things to discuss about how we all can and want to cooperate around this great contribution going forward.
How is the plan to integrate to code into Coreboot?
This is a very relevant question. I remember some mention of adding "hook points" to coreboot so that it will be able to call into AGESA. It can be problematic for us in the coreboot community to make changes in this area however, depending on how AMD proceeds, and on how important it is for us to continue to benefit from further work on the released code done outside of the coreboot community.
Thanks again! What a great way to start the weekend! :)
//Peter