[libre-riscv-dev] formal verification

[Luke Kenneth Casson Leighton]

On Wed, Mar 20, 2019 at 6:44 AM <ogurksjnv at firemail.cc> wrote:
>
> I think it's crucial to have compliance with the RISC-V specs.
> If some day Simple-V get into production level, it is necessary
> to have it. Some links:

that would require the RISC-V Foundation's Directors to have an
understanding of Trademark Law, which they do not.

Trademark Law requires and places an obligation on the licensor to
respond to requests in a FAIR, REASONABLE and NON-DISCRIMINARY (FRAND)
fashion.

they have consistently and repeatedly failed to respond to all and any
efforts at communication.

i have repeatedly and consistently demonstrated a willingness to talk
about how this project may participate in the *innovation* and
*evolution* of RISC-V.

they genuinely and falsely believe that it is acceptable to force
participation to be channeled solely and exclusively through RISC-V
Membership.

given that such membership forces us to participate in secretive and
closed doors discussions, and given that this is incompatible with the
goals of the project AND OUR APPLICATIONS FOR FUNDING which REQUIRE
FULL TRANSPARENCY, this incompatibility qualifies as DISCRIMINATION
under Trademark Law.

to make that clear: the applications for funding, being a Privacy and
Enhanced Trust Grant, specifically requires us to be fully transparent
about the development of this project.  to then engage in secret and
closed doors communications would not only be a direct violation of
the trust that end-users could expect, it would also likely be treated
as a fraudulent Grant Application, which could result in CRIMINAL
PROSECUTION.

the RISC-V Foundation's failure to respond having been presented with
REASONABLE arguments as to why we may not sign the RISC-V Membership
Agreement may be seen as UNREASONABLE, as well as UNFAIR and
DISCRIMINATORY.

therefore, the burden is on the RISC-V Foundation Directors to
respond, and to permit us to participate in *innovation*... WITHOUT
SUCH DISCRIMINATION.

they have not provided a response.

therefore, it is very simple: due to their repeated failure to
respond, the RISC-V Foundation has not met its full obligations under
Trademark Law, and we are therefore under no obligation to seek
compliance as far as the *innovation* of what we are developing is
concerned, and, furthermore, as far as this *innovation* is concerned,
we may still claim RISC-V compatibility.

now, as far as "compliance" is concerned, if there is no *need* to be
incompatible, for example, in areas such as running standard RISC-V
applications, we may *NOT*, i repeat, *NOT* step outside of the bounds
of RISC-V compatibility and interoperability.

for the sake of a simplistic example, if we decided to change the
meaning of the RV64 FABS instruction, with no notification, no
consultation, no explanation and no interaction of any kind with the
RISC-V Foundation, and we then tried to claim "interoperability", we
would indeed be in *direct* violation of Trademark Law.

we have absolutely no intention of doing something that stupid (not
least, it would place a heavy burden onto us to maintain an entire
hard fork of the entirety of the debian and fedora packages, as well
as a hard fork of the toolchains).

to be absolutely, absolutely clear about that: it is ONLY where we
have a CLEAR and UNEQUIVOCABLE business case for stepping outside of
the bounds of RISC-V interoperability, such as *INNOVATION* which is
CLEARLY required for a 3D GPU (and for a VPU) that has NOT been
considered or discussed or included in any RISC-V Standard, and where
the RISC-V Foundation has SPECIFICALLY falied in its obligation to
allow us to interact with other RISC-V Members for the purposes of
expressing and developing that innovation, that we may proceed, and
ONLY after REPEATED REQUESTs to be permitted to do so, and ONLY after
those repeated requests have been ignored.

i hope and trust that that helps clarify that i have a full and active
understanding of Trademark Law and the obligations of compliance.
this comes from having to research Certification Marks, as i am a
Certification Mark for and Copyright holder of the EOMA68 Standard.

l.