Re: Packaging of the RISC-V ecosystem?
Hi!
2016-11-11 15:46 Karsten Merker:
[... leaving only some bits, but replying to the whole message ...]
Other trademarked architecture names could in principle be as
problematic as RISC-V, but there are two points which make
RISC-V a bit different:
- The other names are in use for years with the trademark owners
clearly knowing of the uses and not doing anything against
that. As far as I know, in many jurisdictions trademarks have
to be actively defended, i.e. if the the trademark owner
knowingly tolerated the use of his mark for a certain purpose
for a prolonged time, he can lose the right to interfere with
the further use of the mark in those cases. RISC-V is a new
platform, so this argument of defense wouldn't be valid for
RISC-V.
- RISC-V has an explicit trademark policy which expressly limits
the uses of the RISC-V trademark.
Also IANAL and wasn't even aware of this before you mentioned it, but
most people of the board are aware of the Debian port (and of the Fedora
port, etc), and even encourage it, so I don't think that they plan to
use it against Debian or other FOSS projects.
Maybe we can ask them explicitly just in case, or try to get an
exemption from them, which should help if this issue gets back to us a
few years down the line?
In my limited understanding of the issue, and since there's no business
involved (in my porting efforts and Debian in general, anyway), I also
don't see what they could do other than requiring to stop using the
name? But if one technology is interoperable with another, and this is
usually encouraged by law, I guess that one should have a way to mention
it ("this library implements the X protocol, etc." or "This version of
Debian can be installed in computers implementing Arch"). Otherwise I
don't know how any software vendor could have survived all this decades,
claiming compatibility against trademarked OS names and
computers/devices?
Note also that riscv64 is an arch name that they use in the toolchain
identifiers, e.g. __riscv64 and the arch name that Linux returns
(riscv*), so in that case all major FOSS projects would be in danger of
any recent or future trademarked arch... and in fact Debian even uses
"amd64" and "arm64" instead of the more "technical" equivalents "x86_64"
or "aarch64".
I believe that this outcome is probably not what many of the
original RISC-V developers had intended, but this is the current
legal situation as I see it and this will probably be cemented by
the legal structure of the RISC-V foundation which controls the
trademark.
I think that the best think to do then, is to get in touch with them to
explain this issue. If you have time available now please go ahead... I
cannot start this at the moment, I've been trailing behind for weeks and
didn't even follow the main mailing lists due to misc. life issue.
Maybe they are amenable to add "research, academic or FOSS projects" or
something to that effect?
Therefore I definitely want to avoid the use of "riscv" as the
base for the Debian architecture name, in particular as an
architecture name isn't something that can be easily changed once
we have had a formal Debian release with it.
If the situation in the future really means that they will try to stop
FOSS implementations using riscv* at all, something that I find hard to
believe, maybe it's not worth to even embark in this adventure... but I
don't think that this is so serious right now.
>So how about the following naming convention:
>
> RV<optional "BE" big-endian identifier><WIDTH><LIST_OF_ISA_EXTENSIONS>
>[...]
>
>Examples for possible architecture names following this naming
>convention could be: RV64G, RV32IMA, RVBE64G
If BE/LE is optional and G is optional as well (being the "default"), we
would have rv64 or riscv64, and then rv64imfac for example.
But in that case, if G is ommitted for being the default, it would not
serve as a good guide/example for future "flavours", with examples as
you mention (armhf in Debian and Raspbian).
You probably misunderstood me - in my proposal the "G" is _not_
optional and cannot be omitted. The architecture name always has
to contain an ISA specifier, so only "rv64" wouldn't be allowed as
architecture name.
Nope, I understood fine but probably didn't express myself properly --
dropping the "g" was a possibility / proposal from my side.
The reason why I didn't think about adding G explicitly it's because, as
a baseline, I don't know if it's worth adding at least for 64 bits.
I am not sure if anyone will create a 32-bit flavour of Debian for
RISC-V [1], and in that case it's not so clear if chips will implement G
or only e.g. IMA, Pulpino for example is not even fully rv32
compliant... but I think that for 64 bits it's clear that G is the bare
minimum -- other options don't make much sense in today's world, IMO.
There's the question of whether the Compressed extension would be
[almost] universally implemented as well. But my idea was mostly to
have a baseline able to run in all of them, and then consider other
ports / ABIs if there's enough demand for it. But I expect rv64g to be
the one which can always be run in any device (if they ever become
available) at least for the next decade or so, that's why I see the 'G'
as baseline / optional, not adding much info over riscv64.
Other than that, I see more useful your proposal of naming things like
*QX for Q and X extensions, rather than adding names like "rv64-lowrisc"
for the "lowRISC" brand of devices/chips.
(It's also unclear to me if the possible devices coming to market will
coalesce around a few set of extensions or if all of them will spin
their own custom extensions, etc -- maybe there will never be any device
implementing any standard extension beyond "G" which are not
super-specialised instructions that only this device implements).
[1] One never knows if there's going to be a new RPi-like project with
rv32 that will sweep the whole technology field, but in principle
32-bits is only sustained now for general purpose OSs because of
older hardware, not for things that are yet to come. So I don't
think that we will see rv32 Debian ports.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: