Distribution of binary
peter at digitalbrains.com
Thu Jan 3 12:25:52 CET 2019
On 03/01/2019 02:29, Jeremy Drake wrote:
> Also, with as long as this discussion of how to properly exercise
> freedom 2 of the essential freedoms  has gone on, I was beginning
> to wonder if this truly qualified as "free software" ;)
I'm happy with the outcome that there is an easier to use VID:PID for
the GnuK, but I feel this misrepresents the situation. Or in two words:
I disagree. I see the smiley there, but I'd still like to present a
First of all, it's the USB-IF that is causing problems here, not the
FSIJ or GnuK. The USB-IF has these unfree requirements on use of "their"
identifiers. I think I misphrased when I wrote "sullying the FSIJ", it
should have been "getting the FSIJ into trouble".
The GPL uses copyright law as the framework to shape the licence. I
think there are many jurisdictions where copyright law doesn't cover one
or two 16-bit identifiers, so I suspect you need to be well acquainted
with the law to exactly say how GPL interacts with identifiers.
Interoperability however /is/ partly about identifiers, and in several
jurisdictions you are allowed to make an interoperable implementation.
But if you want to go down that road, you need to sue the USB-IF over
their "licence" on the identifiers, because I'm sure in the current
situation they will not agree unless forced to do so by a court. I don't
think many people would be willing to spend the money and effort
required to go to court over this, so that's not likely to happen. I
also doubt a court would even be willing to rule against the USB-IF
But free software is also about intent and practical consequences and
spirit and not just the law.
That same page also mentions:
| Thus, it is acceptable for the license to require that you change the
| name of the modified version, remove a logo, or identify your
| modifications as yours.
Now this gets more into trademark than copyright, and we see that they
do allow you to limit redistribution of this type of data. It does
| As long as these requirements are not so burdensome that they
| effectively hamper you from releasing your changes, they are
| acceptable; [...]
and without an alternative to the FSIJ VID:PID, it indeed gets slightly
murky (but this unwelcome situation is forced by the USB-IF, not the
FSIJ or GnuK).
There are two conflicting rulesets here: on the one hand the contract
with USB-IF and on the other hand free software. If you believe free
software licences should extend to usage of VID:PID pairs, this quickly
leads to the stalemate that it becomes impossible to have a free USB
device when it is using the identifiers of a company still under
contract with the USB-IF. Note that the USB-IF doesn't condone the use
of the pid.codes range; they simply can't do much about it either. The
contract under which they were allocated is with a company that doesn't
In an ideal world, the whole industry would have agreed on a different
identification mechanism that uses identifiers that are not so tightly
controlled by an organization selling them. Either randomly generated
UUIDs or DNS labels (so you can create identifiers within the domain you
own) or something like that. Microsoft has done this for themselves
with the Microsoft OS Descriptor.
As I mentioned before, in an ideal world, this would have been the case
from the onset. But I think UUID's weren't that commonly used when USB
was originally developed, even though they already existed.
> Anyone who wants to distribute binaries (or by extension hardware)
> with different strings need only modify GNUK_USB_DEVICE_ID text file
> at the root of the source tree, IIRC.
Yes. Changing to a supported VID:PID is simply an argument to
./configure, this is checked for sanity (it's limited to the listed
IDs), and is part of the regular build process. But also changing the
associated strings requires editing GNUK_USB_DEVICE_ID in the source.
This requires providing access to this modified source when you
distribute. Other device strings would change as well: the revision
string (USB string descriptor 4 currently) changes to
"release/1.2.13-modified" or ""release/1.2.13-1-gabcdef0" (git commit
object) instead of "release/1.2.13". And just like this change is not
immediately evident, there might be more I'm not realizing.
The actual change to the file is small. But it has implications.
So that's why I think the better way to solve this if we were to suggest
using different strings for a VID:PID, would be to change the code such
that alternatives can be selected through ./configure.
> I believe that some software "knows" the 234b:0001 VID:PID, and should
> be taught that 1209:2440 should be treated the same. Off the top of
> my head, the udev rules which have already been mentioned, plus
> libccid  and OpenKeychain .
(234b:0001 is NeuG, you mean 234b:0000)
I agree, good point. I get the sense the 1209:2440 VID:PID hasn't
actually been used yet, it was still in the "we plan to do this" phase.
I could be wrong though. It would be good if consumers of these ID's get
to know about them by default. But the udev rule could also just match
on "An OpenPGP Token" without considering the VID:PID.
 Note that you can actually generate UUID's from DNS labels. They're
just not that human-readable anymore.
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Gnuk-users