[Libre-soc-dev] IRC talos-workstation discussion

[Luke Kenneth Casson Leighton]

Jeremy_Rand_36C3> sadoon: any idea whether there would be a
legal/regulatory issue if someone whose $DAYJOB receives NLnet funding
wanted to send an earmarked donation to NLnet for a different project?
(Might possibly be interested in donating a bit to Libre-SOC but my
$DAYJOB is funded by NLnet, so I'm not sure if it would be a conflict
of interest or something.)
<gnucode> Jeremy_Rand_36C3: when do you think the libre-soc people
will release their first GPU/CPU?
<Jeremy_Rand_36C3> gnucode: beyond whatever is on their wiki, I have
no idea. As best I can tell, NLnet is sufficiently satisfied with
their progress that the money is still flowing, and my experience is
that NLnet generally wouldn't toss that much funding at a project
without due diligence.
<Jeremy_Rand_36C3> gnucode: there are a few Libre-SOC people in the
channel, you could ask them

<sadoon[m]> <Jeremy_Rand_36C3> "sadoon: any idea whether there..." <-
I have no idea, perhaps lkcl: can answer better
<sadoon[m]> Progress is going quite well btw, Debian bookworm already
has our patches for binutils to support the new vector extensions,
it's in binutils 2.40 iirc
<Jeremy_Rand_36C3> sadoon: what are the OpenPOWER rules for
introducing new extensions like that? Are you allowed to introduce
extensions without getting OpenPOWER buy-in? If not, I assume the
restrictions only apply to physical products and not FLOSS code?
<Jeremy_Rand_36C3> (kind of embarrassing that I don't know the basics
of how the POWER ISA license rules work...)
<sadoon[m]> Jeremy_Rand_36C3: That's ok, neither do I :p
<sadoon[m]> I'm strictly working on the distro porting side right now
so I don't really know about these rules tbh
<Jeremy_Rand_36C3> AFAIK the OpenPOWER license isn't actually
open-source under the standard definition (i.e. it puts restrictions
on what kinds of derivative works you can make)
<Jeremy_Rand_36C3> Which isn't necessarily a bad thing. AFAIK RISC-V
is under a much-closer-to-open-source license and it's resulted in
massive fragmentation problems.
<sadoon[m]> They're definitely working with OpenPOWER so I wouldn't
worry about it, toshywoshy: would know the exact answer you're looking
for
<Jeremy_Rand_36C3> sadoon: yeah it's not so much that I'm worried
you'll run into a license issue, more than I'm just curious what kinds
of things you guys are having to do in order to not run into a license
issue
<Jeremy_Rand_36C3> s/than/that/
<sadoon[m]> Basically what I'm doing as the first step is to build a
new triplet for powerpc starting with powerpc64le-sffs targetting
power9 without vectors and other things
<sadoon[m]> So
<sadoon[m]> -mcpu=power9 -mno-altivec -mno-vsx -mno-crypto -mno-htm
-mlong-double-64"
<sadoon[m]> This supports anything running 3.0 ISA
<sadoon[m]> Once that's built into the compilers then we can move to
targeting our specific chip
<sadoon[m]> If you do -mcpu=power7 you'd enable little endian support
on the e6500 but that's out of my scope of testing :)

<lkcl> Jeremy_Rand_36C3, re donations i see no reason why not - send a
message to bob and michiel, you almost certainly know their email
addresses (PM me if you don't know bob's)
<lkcl> we have had sponsors in the past send donations (tax-deductible
contributions because of NLnet's Charitable Status)
<lkcl> but honestly, because it's "your money by the time you receive
it", that's now fire-breaked
<lkcl> but if you're getting taxed, and your country's Revenue
Authority allows you to offset Charitable Donations, then the puzzling
thing is, honestly, *why are not more people donating!* either to the
FSF, to NLnet, or *any* FOSS-related Foundation!
* lkcl waves to tpearson - been a while!
<lkcl> if anyone sees gnucode, do pass on that "Libre-SOC gets its
first ASIC out the door when Foundries stop requiring NDAs for PDKs".
which is not as insane as it sounds but puts Foundries as the
show-stopping blocker
<lkcl> *RED Semiconductor Ltd* on the other hand gets *its* first
Libre-SOC SoC out the door when VCs provide RED with sufficient money
to do so.
<lkcl> which neatly / starkly highlights the realistic difference
between "a FOSS Project" and "a commercial company using FOSSHW
designs even though they're exactly the same as what the FOSS Project
aims for"
 Jeremy_Rand_36C3 JTL jn jasonaowen jbowen jcajka jellydonut JSharp
<lkcl> Jeremy_Rand_36C3, here's the EULA for the Power ISA
https://openpowerfoundation.org/blog/final-draft-of-the-power-isa-eula-released/
<lkcl> subtlties (1) - Power ISA is *TRADEMARKED*, it is ***NOT*** a
free-for-all "Open do what you like"
<lkcl> it should be blindingly obvious that a free-for-all would be
absolutely catastrophically damaging
<lkcl> and by a happy coincidence Trademark Law is very very
specifically and precisely intended to cater for exactly this scenario
<lkcl> so not only should it not be a surprise that the Power ISA is
Trademarked, it should be *welcomed* that there is a Foundation behind
that Trademark - by both the FOSSHW community *and* by Commercial
Entities
<lkcl> obviously, people familiar with Trademarks in the FOSS
community know that to work-around a Trademark you must eradicate all
mention of the Trademark from your "fork". and you must do that
properly (which is where things get a little fuzzy for most FOSSHW
community members)
<lkcl> good examples: Redhat-eradicated-and-forking-as-PowerEL
<lkcl> Redhat-eradicated-and-forking-as-Fedora
<lkcl> Redhat-eradicated-and-forking-as-CentOS
<lkcl> so if you want to add custom extensions to the Power ISA, and
you want to experiment and do them "privately", you want Page xii of
the Power ISA v3.1 document.
<lkcl> The architecture sandbox consists of the following.
<lkcl>  The designated opcode sandbox is instructions
<lkcl> having a primary opcode of 22.
<lkcl>  The designated SPR sandbox consists of non-priv-ileged SPRs
704-719 and privileged SPRs 720-735.
<lkcl> etc. etc. you get the general idea
<lkcl> but the critical thing to note is: you *will* if you expect
those custom extensions to be "upstreamed" (because you are expecting
them - naively - to be "long-term-supported") you will be beginning to
"stomp on toes"
<lkcl> this is where i have been trying to get the OPF to understand
that by not properly policing *even the sandbox* under the Trademark,
they are potentially placing the Power ISA at risk in exactly the same
way that is presently happening - right now - with RISC-V
<lkcl> Xiantue 910 uses rogue custom public instructions from the
"custom opcode" space
<lkcl> N.E.Other Hardware manufacturer does the same thing
<lkcl> *even SI-Five* does exactly the same thing
<lkcl> with exactly the same custom opcode space
<lkcl> and binary interoperability just got shot to shit
<lkcl> this *could* happen to the Power ISA as well, but nobody wants
to prevent it because it risks placing "even more bureaucracy in the
way of adoption". sigh.
<lkcl> so the fragmentation problems you mention regarding RISC-V,
Jeremy_Rand_36C3, are *not* because of "strictness" - they're because
of a deep fundamental blindspot which i wasted *twelve months* of my
life trying to desperately get people to listen
<lkcl> (when i was under the deeply naive impression that people
within the RISC-V community are safe and respectful individuals, and
that abuse would not be tolerated in any way)
<lkcl> and my unheeded warnings have now taken hold and created
precisely and exactly the situation that has now been widely noted:
merry mayhem and unreconcileable binary non-interoperability
<lkcl> Power ISA *could* go exactly the same way (it has the exact
same "rigorous" Trademark-backed "rules" regarding its Sandbox custom
opcodes), and it's only the lack of uptake by multiple parties that's
prevented the exact same thing from happening
<lkcl> now, what you *absolutely must not* do is go blithely writing
extensions that utilise anything *other* than the Sandboxed
Architectural Allocations (Opcode 22, SPRs 704-709 etc. etc.)
<lkcl> IBM and other OPF Stakeholders *will* begin the immediate
process of evaluating whether your intended work could cause them
financial damage / loss due to the catastrophic effect your
disregarding of a Trademark License could do to the reputation of the
Power ISA
<lkcl> (whether you actually hear from them immediately or not -
whether you ever find out that they did such an evaluation - is
another matter)
<lkcl> but the decision will come down to, "if you start selling an
ASIC with rogue instructions - not in the Sandbox - and e.g. IBM's
customers hypothetically start demanding support for those
instructions, and they *lose the customer* because IBM's Lawyers have
to get involved and explain to said customer why it can't happen",
that's classed as "material damage" and they would be perfectly within
their rights to sue the f*** out of you
<lkcl> so please
<lkcl> *under no circumstances* if you are planning a commercial
product (volumes of 50,000 or above) do a custom ASIC using the Power
ISA that blatantly disregards the Trademark by using anything other
than the "Sandboxed" opcodes/resources.
<lkcl> and even then, bear in mind that should your commercial product
become long-term successful (10+ years), you could potentially cause
the exact same damage *in the Sandbox* area that RISC-V is currently
experiencing
<lkcl> bottom line, please please consider submitting ISA Extension
proposals through the OPF ISA WG's "External" Submissions Process
<lkcl> you don't even have to be a Member of the OPF to do it.
<lkcl> https://openpower.foundation/isarfc/
<lkcl> do just bear in mind that even by submitting the RFC, you're
agreeing to the Anti-Trust provisions, Inbound Patent Licensing, and
so on (see the bottom of that page)
<lkcl> but note one thing: what is *very much* not on that list is a
"Commercial Confidentiality" (secrecy, NDA) agreement.  you are *not*
bound by secrecy just by submitting the RFC
<lkcl> you have no rights on the *other side* (no right to vote, no
right to be part of the discussions of your RFC), but at least you can
make the submission
<lkcl> RISC-V *DEMANDS* that you join their Foundation.  if you do not
join, you are told, plain-and-simple, "well you can't submit RISC-V
ISA RFCs then".
<lkcl> that for us - from our funding remit through NLnet - was a
direct conflict-of-interest, because NLnet's funded us under their
"Privacy and Enhanced Trust" Programme, and their mandate (the
Foundation Charter) is "Works for the Public Good"
<lkcl> and if we abused their money by signing a Commercial Secrecy
Agreement, they would have been perfectly within their rights to
terminate our funding.
<lkcl> so it's *real* fortunate that the OPF has this submission route
to the ISA WG.
<lkcl> and you can use it too.  anyone can.
<lkcl> just... please... be mindful that it's a lot of work to review RFCs?
<lkcl> and Libre-SOC is currently stacking up *ONE HUNDRED*
instructions to be added to the SFFS Subset (!!)
<lkcl> https://bugs.libre-soc.org/show_bug.cgi?id=952
<lkcl> consequently if what you're thinking of is a bitmanip
instruction, or a... cryptographic biginteger instruction, or an
Audio/Visual acceleration instruction, or many others, chances are
really quite amazingly high that we've already designed something that
does the job

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68