updates/022_2020feb14_openpower_eula_released.mdwn

   1 # Intro
   2
   3 Several things in this update: the OpenPower Foundation released their EULA;
   4 we had a last-minute decision to go to FOSDEM to meet NLNet; we have new
   5 team members helping out and making really good progress.
   6
   7 # OpenPOWER Foundation releases the Power ISA EULA
   8
   9 This is a big deal: the
  10 [EULA](https://openpowerfoundation.org/final-draft-of-the-power-isa-eula-released/)
  11 for anyone wishing to create a Power ISA compatible processor, it's been
  12 designed to be "libre-friendly".  We will need to do a full review,
  13 and would appreciate feedback on it, via
  14 [this bugreport](http://bugs.libre-riscv.org/show_bug.cgi?id=179).
  15 A very quick read (like, right now): the really interesting bit is the
  16 combination of a royalty-free grant in combination with "if you initiate
  17 patent litigation, you lose all rights immediately".  This provides an
  18 extremely strong disincentive for patent trolls to "try it on".  It also
  19 actively encourages contributors to make sure that their work becomes an
  20 "official" part of Power, because that then gets them under the
  21 "umbrella" of protection as part of this EULA.
  22
  23 My only concern - long-term - is the warning about Custom Extensions
  24 potentially being incompatible.  We remember the Altivec clash very
  25 well, citing it as a historic lesson "How Not To Manage An ISA",
  26 because both Altivec's vector extension and the one it clashed
  27 with became high-profile public wide-spread common-usage extensions,
  28 and it damaged Power ISA's entire reputation and viability as a result.
  29
  30 With our extensions being designed *knowingly* in advance to be
  31 high-profile, public, wide-spread and common-usage, we absolutely have
  32 to submit them as "official" extensions, or to work with the Open Power
  33 Foundation to create an official "escape-sequence" namespace system
  34 (ISAMUX/ISANS).  As mentioned previously: anyone familiar with c++,
  35 we need a hardware version of "using namespace", in its entirety.
  36
  37 First preliminary reading however, as Hugh kindly said privately to me,
  38 there's really nothing controversial, here, and it actually looks really
  39 good and extremely well-designed.
  40
  41