Skip to content

Add a LICENSE file #1

Description

@nille

Thanks for building this. I have a PIXY on Arch and had basically written off the
motorised and AI features as Windows/macOS-only until I found PixyPilot — the vendor HID
work here is the part nobody else was going to do for me, and it works.

One thing that would make the project more useful to more people: there is currently no
LICENSE file in the repo, so GitHub reports no license and the default applies —
all rights reserved. That is fine for running it locally, which is what I am doing, but
it blocks a few things:

  • Distro packaging. I would like to put this in the AUR so other Arch users get the
    udev rule and desktop entry without hand-installing. Packaging requires a license the
    packager can point at; the AUR expects a license field and unlicensed software is
    not accepted.
  • Contributing. I have a couple of small Arch-specific patches (see below) and no
    clear terms under which to offer them, or for you to accept them.
  • Forks and downstream fixes. Anyone wanting to carry a fix while waiting on a
    merge currently has no right to redistribute their fork.

If you are open to it, MIT or Apache-2.0 are the usual choices for something like this
and both are a single file plus one line in the README. GitHub can add either from the
web UI in about thirty seconds: Add file → Create new file → type LICENSE → "Choose
a license template"
.

Worth noting that a permissive license makes the reverse-engineering documentation in
docs/ reusable too, which given how much of the credit chain in your README is people
reading each other's notes seems in the spirit of how this got built.

No obligation, and it is your project — just flagging it because it is cheap to fix and
currently the main thing standing between PixyPilot and being installable with one
command on more distros.


The Arch patches, for context

Happy to open these as PRs once there is a license, or you are welcome to just take
them — no attribution needed:

1. deploy/udev/70-pixypilot-hid.rules sets GROUP="plugdev", which does not exist
on Arch.
The rule silently fails there: udev applies a nonexistent group and the user
never gets access, with no error surfaced. The existing TAG+="uaccess" already covers
this case better — systemd-logind grants an ACL to the active-seat user on any
systemd machine, dynamically, with no group needed:

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="328f", ATTRS{idProduct}=="00c0", MODE="0660", TAG+="uaccess"

Result on Arch:

$ getfacl /dev/hidraw9
user::rw-
user:n:rw-

Could ship as a second file, or replace the current rule since uaccess works on
Debian and Ubuntu too — plugdev there is belt-and-braces rather than load-bearing.

2. config/pixypilot.yaml ships server.host: 0.0.0.0. That exposes the control
API and live preview to the whole LAN, and the README notes authentication does not
exist yet. 127.0.0.1 seems like the safer default, with a comment pointing at
0.0.0.0 for the Windows pcap-upload workflow that needs it.

3. Python 3.14 works. requires-python = ">=3.12" is accurate but conservative —
every dependency has a cp314 wheel and all 97 tests pass on 3.14.6. Might be worth
widening the claim if you want Arch and Fedora users to stop hesitating.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions