https://openpowerfoundation.org/final-draft-of-the-power-isa-eula-released/ this has been released, i'm writing an update about it. we need to go over this, get some eyes-on and insights. also i'd like to help OPF with some awareness of it.
https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/022_2020feb14_openpower_eula_released.mdwn;hb=HEAD
(In reply to Luke Kenneth Casson Leighton from comment #0) > https://openpowerfoundation.org/final-draft-of-the-power-isa-eula-released/ > > this has been released, i'm writing an update about it. we need to > go over this, get some eyes-on and insights. also i'd like to help > OPF with some awareness of it. read through the EULA, generally looks good to me! One part that I am a little worried about is that it specifically states that Power is not intended for safety-critical applications: > The products described in the Power ISA are NOT intended for use in > applications such as implantation, life support, or other hazardous > uses where malfunction could result in death, bodily injury, or > catastrophic property damage.
the part about safety-critical applications seems to be a standard disclaimer that is commonly found in manuals. everything else seems good to me, even if Limitation of Liability might be invalid in some jurisdictions. At least in Germany it is well known to be void.
(In reply to Luke Kenneth Casson Leighton from comment #1) > https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/ > 022_2020feb14_openpower_eula_released.mdwn;hb=HEAD Before releasing this, we should decide how we're going to spell Libre-SOC, for consistency's sake, since we still haven't decided between Libre-SOC, LibreSOC, and other alternatives. We should also change the website to consistently use whichever variant we decide on.
I thought we had decided to go with Libre-SOC over LibreSOC because of the unavailability of libresoc.org. My one concern with the EULA is with this paragraph: “OpenPOWER ISA Compliance Definition” means the validation procedures associated with architectural compliance developed, delivered, and maintained by OPF as specified in the following link: https://openpowerfoundation.org/?resource_lib=openpower-isa-compliance-definition. That link points to a compliance definition with IBM Power ISA Version 2.07 B. I was under the impression, perhaps erroneously, that the OpenPOWER ISA and associated compliance would be with Power ISA V3.0B Specification.
(In reply to Cole Poirier from comment #5) > I thought we had decided to go with Libre-SOC over LibreSOC because of > the unavailability of libresoc.org. So did I, but then other people apparently think LibreSOC is better because they keep using it everywhere, so apparently it's still undecided. > > My one concern with the EULA is with this paragraph: “OpenPOWER ISA > Compliance Definition” means the validation procedures associated with > architectural compliance developed, delivered, and maintained by OPF > as specified in the following link: > https://openpowerfoundation.org/?resource_lib=openpower-isa-compliance- > definition. I'm guessing that the EULA is specifying that the compliance definition is whatever is at that link, which will be updated as future versions come out, that way, they don't have to keep changing the EULA every time they update the spec. > > That link points to a compliance definition with IBM Power ISA Version > 2.07 B. I was under the impression, perhaps erroneously, that the > OpenPOWER ISA and associated compliance would be with Power ISA V3.0B > Specification. They probably didn't finish the compliance definition for V3.0B yet.
Thanks Jacob, that explanation about the eula compliance makes a lot of sense to me. Do we have a dedicated bug report or mailing list thread about the name of the project? I think it is reasonable to select the exact name and make it consistent across all aspects of the project by the end of the month (I am willing to do the labour of making the necessary modifications to the project’s materials once a final decision is made). If there is an existing mailing list thread or bug report, it is my thinking that we should create a new dedicated spot where all members can assent to the naming convention or dissent with the members then following the procedure set out in the charter for coming to a unanimous decision.
(In reply to Jacob Lifshay from comment #4) > (In reply to Luke Kenneth Casson Leighton from comment #1) > > https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/ > > 022_2020feb14_openpower_eula_released.mdwn;hb=HEAD > > Before releasing this, we should decide how we're going to spell Libre-SOC, > for consistency's sake, since we still haven't decided between Libre-SOC, > LibreSOC, and other alternatives. We should also change the website to > consistently use whichever variant we decide on. Other than Libre-SOC naming, the update draft looks good!
i am happy with the EULA itself. the next step would be, i guess, to confirm that we're happy to go with the dual ISA. then we can create some decoders. we really do need "proper" OPF approval for the escape sequencing to protect the extensions (ISANS/ISAMUX) however if we assume that is going ahead then it is not a major blocker to hitting the Oct 2020 tapeout deadline
(In reply to Luke Kenneth Casson Leighton from comment #10) > i am happy with the EULA itself. I agree. > > the next step would be, i guess, > to confirm that we're happy to > go with the dual ISA. then we can > create some decoders. Sounds good to me! > we really do need "proper" OPF > approval for the escape sequencing > to protect the extensions (ISANS/ISAMUX) We won't have many instructions that specifically manage ISANS, so we can just renumber them if we need to. > however if we assume that is going ahead > then it is not a major blocker to hitting > the Oct 2020 tapeout deadline :)
(In reply to Jacob Lifshay from comment #4) > (In reply to Luke Kenneth Casson Leighton from comment #1) > > https://git.libre-riscv.org/?p=crowdsupply.git;a=blob;f=updates/ > > 022_2020feb14_openpower_eula_released.mdwn;hb=HEAD > > Before releasing this, we should decide how we're going to spell Libre-SOC, > for consistency's sake, since we still haven't decided between Libre-SOC, > LibreSOC, and other alternatives. We should also change the website to > consistently use whichever variant we decide on. We should update the spelling in the Crowd Supply article to use Libre-SOC rather than LibreSOC.
Re: OpenPower EULA Released J Jason Self to lkcl 8 minutes agoDetails On Mon, 17 Feb 2020 22:42:05 +0000 Crowd Supply <no-reply@crowdsupply.com> wrote: > An update from the Libre RISC-V M-Class team. > > ------------------------------------------------------------------------------- > > # OpenPower EULA Released, FOSDEM, and More > > Several things in this update: the OpenPower Foundation released > their EULA (which is really exciting); we had a last-minute decision > to go to FOSDEM to meet NLNet (and meet lots of nice people including > someone from the EU Commission); we have new team members helping out > (and making really good progress). > > Read the full update here: > https://www.crowdsupply.com/libre-risc-v/m-class/updates/openpower-eula-released-fosdem-and-more I don't have an account on bugs.libre-riscv.org, don't want to make one, and there seems to be no way to submit feedback without making one so I am making this up. The Power ISA EULA is non-free. This is a non-exhaustive list of reasons. > 1. Grant of Rights > Solely for the purposes of developing and expanding the Power ISA and > the POWER ecosystem... To qualify as free it the grant of rights must be for any purpose, including those that to not develop or expand the Power ISA or POWER ecosystem. > 1.1 OPF grants to Recipient a nonexclusive, worldwide, perpetual, > royalty-free, non-transferable license under all copyrights licensable > by OPF and contained in the Power ISA to a) develop technology > products compatible with the Power ISA, and b) create, use, > reproduce, perform, display, and distribute Power ISA Cores. > 1.4 Notwithstanding Sections 1.1 through 1.3 above, Recipient shall > not have the right or license to create, use, reproduce, perform, > display, distribute, sell, or license the Power ISA Core in a > physically implemented chip (including a microprocessor, system on a > chip, or a field-programmable gate array (FPGA)) that is not Power > Compliant, nor to license others to do so. To qualify as free, you should be able to develop technology products that are incompatible with the Power ISA and to distribute them. In such a case, it would be acceptable for the EULA to require to change the name of it so that people don't think it is POWER, and/or to identify the modifications as yours, but they must be permitted. > 2.1 Recipient shall have the right to submit Contributions to the > Power ISA through a prospectively authorized process by OPF, but > shall not implement such Contributions until fully approved through > the prospectively authorized OPF process. To qualify as free you should also have the freedom to make such modifications to the ISA and to share them if desired. If they are shared, you should not be required to notify anyone in particular, or in any particular way. Just as with the last piece, it would be acceptable for the EULA to require to change the name of it so that people don't think it is POWER, and/or to identify the modifications as yours, but they must be permitted.
Re: OpenPower EULA Released J Jason Self to lkcl 8 minutes agoDetails On Mon, 17 Feb 2020 22:42:05 +0000 Crowd Supply <no-reply@crowdsupply.com> wrote: > An update from the Libre RISC-V M-Class team. > > ------------------------------------------------------------------------------- > > # OpenPower EULA Released, FOSDEM, and More > > Several things in this update: the OpenPower Foundation released > their EULA (which is really exciting); we had a last-minute decision > to go to FOSDEM to meet NLNet (and meet lots of nice people including > someone from the EU Commission); we have new team members helping out > (and making really good progress). > > Read the full update here: > https://www.crowdsupply.com/libre-risc-v/m-class/updates/openpower-eula-released-fosdem-and-more I don't have an account on bugs.libre-riscv.org, don't want to make one, and there seems to be no way to submit feedback without making one so I am making this up. The Power ISA EULA is non-free. This is a non-exhaustive list of reasons. > 1. Grant of Rights > Solely for the purposes of developing and expanding the Power ISA and > the POWER ecosystem... To qualify as free it the grant of rights must be for any purpose, including those that to not develop or expand the Power ISA or POWER ecosystem. > 1.1 OPF grants to Recipient a nonexclusive, worldwide, perpetual, > royalty-free, non-transferable license under all copyrights licensable > by OPF and contained in the Power ISA to a) develop technology > products compatible with the Power ISA, and b) create, use, > reproduce, perform, display, and distribute Power ISA Cores. > 1.4 Notwithstanding Sections 1.1 through 1.3 above, Recipient shall > not have the right or license to create, use, reproduce, perform, > display, distribute, sell, or license the Power ISA Core in a > physically implemented chip (including a microprocessor, system on a > chip, or a field-programmable gate array (FPGA)) that is not Power > Compliant, nor to license others to do so. To qualify as free, you should be able to develop technology products that are incompatible with the Power ISA and to distribute them. In such a case, it would be acceptable for the EULA to require to change the name of it so that people don't think it is POWER, and/or to identify the modifications as yours, but they must be permitted. > 2.1 Recipient shall have the right to submit Contributions to the > Power ISA through a prospectively authorized process by OPF, but > shall not implement such Contributions until fully approved through > the prospectively authorized OPF process. To qualify as free you should also have the freedom to make such modifications to the ISA and to share them if desired. If they are shared, you should not be required to notify anyone in particular, or in any particular way. Just as with the last piece, it would be acceptable for the EULA to require to change the name of it so that people don't think it is POWER, and/or to identify the modifications as yours, but they must be permitted. noname J Jason Self to lkcl 5 minutes agoDetails Also, this could have been a problem: > The products described in the Power ISA are NOT intended for use in > applications such as implantation, life support, or other hazardous > uses where malfunction could result in death, bodily injury, or > catastrophic property damage. If this were that it's not allowed to be used in those use cases, then that would be another reason for it to be non-free but I'm taking "not intended" to mean that it's not an absolute prohibition on those use cases and that they still can be.
"1.4 Notwithstanding Sections 1.1 through 1.3 above, Recipient shall not have the right or license to create, use, reproduce, perform, display, distribute, sell, or license the Power ISA Core in a physically implemented chip (including a microprocessor, system on a chip, or a field-programmable gate array (FPGA)) that is not Power Compliant, nor to license others to do so." I agree that this is overbroad. We might want to design our own cores with IP. I recommend that an exception of some sort be made for open-source projects. "7.1 Nothing contained in these terms shall be construed as conferring any right to use in advertising, publicity or other promotional activities any name, trade name, trademark or other designation of any Party hereto (including any contraction, abbreviation or simulation of any of the foregoing)." So if I sell a CPU with the power arch I can't say what's inside when advertising? Or did I misread this?
(In reply to doark from comment #15) > "7.1 Nothing contained in these terms shall be construed as conferring any > right to use in advertising, publicity or other promotional activities any > name, trade name, trademark or other designation of any Party hereto > (including any contraction, abbreviation or simulation of any of the > foregoing)." > > So if I sell a CPU with the power arch I can't say what's inside when > advertising? Or did I misread this? it's not saying "you *can't* use it", that would be worded as, "You are not permitted to use..." it's saying, simply, "when you agree to this EULA, please do not assume that by signing it that you are AUTOMATICALLY granted any ADDITIONAL rights beyond those permitted by Law" they could have made it clearer by adding "except as permitted by applicable law" at the front.