Licensing question

[Vibrans, Frank]

Hi All,

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.  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.

Frank Vibrans

[Rudolf Marek]

Hello Frank,

Thanks for the great news! Please do you know what kind of BSD license it is? 
The "two clause"/"three clause"?
> 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. 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'm not aware of any issues so far. I'm perfectly fine with GPLv2. However for 
dual licensing scheme some kind of policy of what changes are under what license 
must be adopted/developed. I can tell now only "I don't know/I cannot think out 
any implications out of that"

I hope others will jump in eventually with some ideas how to handle that. Most 
likely we can assume what linux kernel folks are doing (and avoid kind of flame 
wars in this topic).

As a side note, I would like to ask about the permissions for example to 
redistribute the VGA ROM images/EC images/Microcode is this covered somehow in 
the release also?

How is the plan to integrate to code into Coreboot?

I hope other developers share some ideas too (especially if I missed something)

Thank you,
Rudolf

[Peter Stuge]

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

[Patrick Georgi]

Am Samstag, 18. Dezember 2010, um 02:07:50 schrieb Peter Stuge:
> 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.

It's up to the developer of the change to decide the license of their changes. 
That is, a change could be added with the explicit statement (eg. in the 
commit message) that it's licensed both under GPLv2 and BSD-l, and it could be 
taken for BSD-l only uses (while originating with coreboot).
The only thing to keep in mind is that the combined work of coreboot+AGESA 
will be GPL only - this only affects distributors of coreboot+AGESA binaries 
who will have to treat their changes to AGESA (as delivered with coreboot) as 
licensed under GPLv2 only (unless a clean calling interface is defined as 
described in your mail that would separate coreboot and AGESA sufficiently).

Patrick

[David Hendricks]

On Fri, Dec 17, 2010 at 5:07 PM, Peter Stuge  wrote:
> 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.

Disclaimer: I am not a lawyer.

It seems to me that it is most beneficial overall for AMD to release the
code as BSD only for the reason you mention here. For AMD to see maximum
benefit for their contributions here, and for the technical advantages of
reducing diffs between AMD and Coreboot sources (good for everyone), the
Coreboot community should make it easy for AMD to port changes back into
their tree.

I like the GPLv2 and all, but I think BSD is more practical and will be most
beneficial for all parties in this case. Unless there is a heavy burden
placed on Coreboot developers by using BSD-licensed AGESA code that I am not
seeing here?

</my $0.02>

[Scott Duplichan]

-----Original Message-----
From: coreboot-bounces+scott=[e-mail] [mailto:coreboot-bounces+scott=[e-mail]] On Behalf Of Rudolf
Marek
Sent: Friday, December 17, 2010 06:08 PM
To: Vibrans, Frank
Cc: Simpson, Gary; [e-mail]
Subject: Re: [coreboot] Licensing question

]Hello Frank,

]Thanks for the great news! Please do you know what kind of BSD license it is? 
]The "two clause"/"three clause"?
> 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. 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'm not aware of any issues so far. I'm perfectly fine with GPLv2. However for 
]dual licensing scheme some kind of policy of what changes are under what license 
]must be adopted/developed. I can tell now only "I don't know/I cannot think out 
]any implications out of that"

]I hope others will jump in eventually with some ideas how to handle that. Most 
]likely we can assume what linux kernel folks are doing (and avoid kind of flame 
]wars in this topic).

]As a side note, I would like to ask about the permissions for example to 
]redistribute the VGA ROM images/EC images/Microcode is this covered somehow in 
]the release also?

Yes, I was supposed to ask about this but have not done so yet. The last
time I saw it, the family 14h agesa already included the SMU binary image
(F14NbSmuFirmware.h) and microcode patch images (F14MicrocodePatchxxx.c).
Adding the video option rom (vbios) image and EC image using the same
license would be most helpful. It is possible that AMD has already done this.

A related request is for microcode patch and vbios images for older platforms.
Coreboot does include some licensed family 10h microcode patches, but I am
not sure that they are current. It is awkward to ask each coreboot developer
to extract vbios and/or microcode patch binaries from his production BIOS.
It would be useful to have a better way for a coreboot developer to obtain
vbios and microcode patch binaries for the AMD family 10h platforms.

]How is the plan to integrate to code into Coreboot?

AMD has already done the integration. I wouldn't be surprised if coreboot+
seabios is booting Windows on the reference board now. Everyone needs to
set aside some money for purchase of an AMD family 14h netbook when they
go on sale in a few weeks. Putting coreboot on these units should be
fairly easy.

Thanks,
Scott

]I hope other developers share some ideas too (especially if I missed something)

]Thank you,
]Rudolf

[Rudolf Marek]

Hello Frank,

Please can you have a look into this thread to see what it has brought.

Nice would be to get answers for questions regarding the redistribution of 
ROMs/Firmware.

Additionally I would like to consult some undocumented bit which is documented 
in SB600 but not SB710. Maybe it is a documentation issue. Maybe not.

More info [coreboot] [PATCH] RFC AMD powernow generation for pre fam 0fh

Thanks,
Rudolf
> Thanks for the great news! Please do you know what kind of BSD license
> it is? The "two clause"/"three clause"?
> > 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. 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'm not aware of any issues so far. I'm perfectly fine with GPLv2.
> However for dual licensing scheme some kind of policy of what changes
> are under what license must be adopted/developed. I can tell now only "I
> don't know/I cannot think out any implications out of that"
>
> I hope others will jump in eventually with some ideas how to handle
> that. Most likely we can assume what linux kernel folks are doing (and
> avoid kind of flame wars in this topic).
>
> As a side note, I would like to ask about the permissions for example to
> redistribute the VGA ROM images/EC images/Microcode is this covered
> somehow in the release also?
>
> How is the plan to integrate to code into Coreboot?
>
> I hope other developers share some ideas too (especially if I missed
> something)
>
> Thank you,
> Rudolf

[Robinson Tryon]

On Fri, Dec 17, 2010 at 2:53 PM, 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.  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 believe that coreboot is GPLv2+, so for maximum license
compatibility, all AMD code would preferably be GPLv2+ (and not just
GPLv2).

Thanks,
--R

[Peter Stuge]

Hello,

Robinson Tryon wrote:
> I believe that coreboot is GPLv2+,

No, coreboot is licensed under GPLv2 only.

Thanks!

//Peter