Dear digiKam Fans and Users,

A new year brings new goals—and this year, we’re taking on a significant challenge: migrating the old digiKam documentation from the DocBook format to a modern, easier-to-maintain architecture.

After 20 years of using DocBook, we have transitioned to the Sphinx/ReStructuredText framework. This new system is not only more intuitive for documentation writers but also streamlines the entire process of creating and updating content.

Two month ago, in October 2022, KDE's GitLab made me use a two-factor authentication (2FA). Without a second factor, I was no longer able to push code, comment on merge requests, or contribute anything meaningful on KDE Invent.

For a long time, I have known I should use two-factor authentication for my important accounts; especially for those accounts used to commit code other people are executing because they trust me. But I was too lazy to have everything prepared to use the second factor.

Thanks to Ben and the KDE infrastructure team, there were no more excuses and I had to set up a secure login.

Secure login, but don't lock yourself out 

Having a second factor, it is important that I am not locked out, if my second factor is left at home or broken. Here is what I did:

1. The first step is to choose the second factor. I decided against dedicated hardware like a Yubi key. I am familiar with one-time passwords on my mobile phone, thus, I decided to use Time-based one-time password (TOTP). This means a device or mobile app knows a secret to calculate a six-digit one-time password. The password is only valid for a couple of seconds, then a new one can be generated locally. I use Google Authenticator, but there are alternatives from less controversial vendors. Just scan the QR code and verify the secret by once entering a one-time code.
2. I installed Keepass to store the recovery codes in case my TOTP device is broken or stolen. As a side effect, I can now use more complex passwords for less frequently used passwords.
3. I made a backup including the Keepass database.
   
4. As a side-effect, I need to use tokens for checkouts and pushes. A great opportunity to have this aspect of secure development activated, too.
   

Remaining open questions

Some questions remain open for me. Time will tell, how much they bug me and where I need to adjust.

Currently, I only have my personal phone as a TOTP device. Maybe I want to add more phones or my iPad. I am also unsure whether I should install and use a TOTP software on my desktop like KDE Keysmith. It is a weighting of comfort, security, and reliability.

By-product: More security everywhere

Now that I have everything prepared on my side to use TOTP as my two-factor authentication, it was easy to use it for all the other accounts that deserve some extra protection: GitLab.com, GitHub, and independent GitLab instances hosted by FOSS projects similar to KDE Invent. Even my Google account is now protected by a TOTP mechanism and I no longer get text messages to my mobile phone. Further, I stored ten security codes from Google, just in case.

Having a security spree, I also wanted to use TOTP for my banking accounts. Unfortunately, my banks insist on the use of their own app. I think they could benefit from using open and established standards, but they decided to force us costumers to install and use their apps.

What is a vacation without a nice side project? – My small x-mas project was to get my RISC-V Allwinner D1 Nezha board finally into a state that it shows anything on the connected HDMI-port. Any, “yeah!!!”, it works:

This picture shows qmlscene rendering a rotating yellow rectangle at 2 fps (speed is limited due to yet missing HW acceleration support).

A few words about the board

Compared to other embedded boards that I have, this one is surprisingly well documented; given you find the right webpages (list at the end). The vendor page itself is in a rather typical state, where an online translator occasionally comes handy to translate Chinese into something I understand But then, there is the really nice sunxi community wiki with has all extra information that you need.

For the device itself, some months ago I decided to get this one mostly because of the reasons price and delivery date. However, it has a big disadvantage for me when I use it for testing the KDE Yocto layers: There is only a 2D GPU on the board (namely a “G2D” unit) for which also no Kernel drivers are present at the moment (except those from the Kernel source blob by the device vendor). However, for all other parts there is impressive community work. Most notably, coming with Kernel 6.2, there is finally the HDMI driver support that made the above picture possible.

The few steps left for me

As said, there is a really good documentation about compiling a close-to-mainline Kernel and u-boot for this board. Moreover, the meta-riscv Yocto layer provides recipes to build a full device image with Kernel 5.16 and a patched/hacked u-boot (using an older boot sequence) with a nice out-of-the-box experience.

So, to get graphics/HDMI working on the board, all that was left for me was following the wiki documentation and:

• switch to the latest Kernel fork based on 6.1 with all the relevant patches
• and adapt U-Boot to a more recent fork that can boot this more mainline Kernel fork.

The details are summarized in this PR for the meta-riscv layer. It essentially drops as much non-mainline tweaks as possible and adapts the recipes along the way. Simple as it looks, it was quite a fun ride down the rabbit hole until I got my first booting Kernel I really think that this tinkering around with hardware is the best way to learn its concepts. Even though I attended many talks in the past about the steps I did, it is so different when you are doing it yourself.

What comes next

Unfortunately, I do not expect any Plasma or KDE application running on the Nezha board in the sooonish future (at least not accelerated via the G2D chip)… Yet, if you recall, at FOSDEM 2019 Alistair already demonstrated Plasma running on a HiFive Unleashed board, using an expansion board for graphics. Finally, there is right now another very interesting and not too expensive RISC-V board becoming available with on-board 3D GPU and it is already on my shopping list… I am looking forward to 2023

Collected Links

• https://linux-sunxi.org/Allwinner_Nezha – General introduction and bring-up by the sunxi community
• https://linux-sunxi.org/U-Boot – flashing instructions by the sunxi community
• https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner – Fedora wiki for D1 support (note: it uses the “old” boot up)
• https://www.rvboards.org/mkdocs/en/nezha-d1/ – English documentation by the HW vendor
• https://github.com/YuzukiTsuru/OpenixCard – a nice tool that can convert Allwinner PhoenixCard images to default IMG files that can be flashed via dd on Linux (e..g when you want to test the vendor image)

It is a pleasure to announce that Kraft Version 1.0 was released last week.

What is Kraft?

Kraft is free software to create office documents like offers and invoices in an efficient way. It runs on the Linux desktop and suits small businesses of all kinds.

After countless releases with version numbers 0.x, Kraft finally goes with version number 1.0 with this release. It is in production at several companies since many years, and with this release it got many more improvements that make it a really mature product.

Highlights

Lets take a look on the highlights of of version 1.0.

AppImage Support

Installing software properly is still a challenge for many users. AppImage comes to the rescue there: Single file, easy to download and start with all dependencies included makes it easy for users. For the creator, it is just one-fits-all, which makes it easy to maintain.

The new Kraft AppImage was carefully reworked and has now really all dependencies included, has a complete own icon set and was tested thoroughly. It is ready for production now.

Giro Code

Kraft now can print the EPC QR Code on invoices easily. Users just have to configure the bank account data to use, and Kraft creates the QR code automatically to be included in the documentation template.

User Manual

The Kraft user manual got great improvements again. It comes with even more and improved text, with much more screenshots and improved translations.

This is a community contributions that is so important for Kraft.

Many other Improvements

There were many other improvements: New functionality such as the new day counter for the number cycle templates (allows to have a counter in the document number that resets to 1 every day) or new modes for the watermark functionality to complete the generated PDF documents plus much more details (See Changelog).

How it continues

Kraft is up and running - and maintained. The plan is to keep the 1.0 as a kind of LTS in a stable branch, that only gets urgent fixes for stability.

For master, I am planning to do a couple of more intrusive changes that will take a bit longer.

See the roadmap discussion here.

Curious?

I hope you got a bit curious now about Kraft. Feel free to check it out using the AppImage.

If you find it an useful addition to the Linux application ecosystem that enables more users for Linux we’d very much appreciate your contribution!

Some more progress has been made on fixing my newest drawing tablet!

Fixing up the patch

So as described in the original post, I have to patch the uclogic HID driver. Let’s start by going through the process of submitting a patch upstream!

Before we even think about sending this patch upstream, I have to first - fix it. While the patch is mostly fine in it’s original form, there is one big issue I would like to tackle - which is the tablet frame buttons. Not even the original author seemed to figure out this issue, so I’m excited to jump in and figure it out.

First I want to set an end goal, which is to be able to set the tablet buttons through the new KDE Plasma 5.26 interface, like so:

Currently if you run my new uclogic patch, for some reason it is not considered a “Pad”:

Looking through the merge request shows.. nothing of interest. That’s because I actually needed to look at this KWin merge request which actually talks to libinput! Oh yeah, libinput - our old friend is here again. This MR mentions an event called LIBINPUT_EVENT_TABLET_PAD_BUTTON which is handled by evdev-tablet-pad.c in libinput. Huh, whats this?

...
static inline void
pad_button_set_down(struct pad_dispatch *pad,
		    uint32_t button,
		    bool is_down)
{
	struct button_state *state = &pad->button_state;

	if (is_down) {
		set_bit(state->bits, button);
		pad_set_status(pad, PAD_BUTTONS_PRESSED);
	} else {
		clear_bit(state->bits, button);
		pad_set_status(pad, PAD_BUTTONS_RELEASED);
	}
}
...

So this file seems to be handling “tablet pad” devices, which I didn’t even know were considered a separate device until now. Looking through the code reveals logic that libinput uses to decide what buttons reported by the device are meant for tablet pad usage:

...

static void
pad_init_buttons_from_kernel(struct pad_dispatch *pad,
			       struct evdev_device *device)
{
	unsigned int code;
	int map = 0;

	/* we match wacom_report_numbered_buttons() from the kernel */
	for (code = BTN_0; code < BTN_0 + 10; code++) {
		if (libevdev_has_event_code(device->evdev, EV_KEY, code))
			map_set_button_map(pad->button_map[code], map++);
	}

	for (code = BTN_BASE; code < BTN_BASE + 2; code++) {
		if (libevdev_has_event_code(device->evdev, EV_KEY, code))
			map_set_button_map(pad->button_map[code], map++);
	}

	for (code = BTN_A; code < BTN_A + 6; code++) {
		if (libevdev_has_event_code(device->evdev, EV_KEY, code))
			map_set_button_map(pad->button_map[code], map++);
	}

	for (code = BTN_LEFT; code < BTN_LEFT + 7; code++) {
		if (libevdev_has_event_code(device->evdev, EV_KEY, code))
			map_set_button_map(pad->button_map[code], map++);
	}

	pad->nbuttons = map;
}
...

So I created a list of valid pad inputs and used those to remap all of the pad buttons to valid inputs. This shouldn’t affect existing tablets (especially considering I don’t think anyone has used a tablet with this driver with more than a couple buttons).

...
/* Buttons considered valid tablet pad inputs. */
const unsigned int uclogic_extra_input_mapping[] = {
	BTN_0,
	BTN_1,
	BTN_2,
	BTN_3,
	BTN_4,
	BTN_5,
	BTN_6,
	BTN_7,
	BTN_8,
	BTN_RIGHT,
	BTN_MIDDLE,
	BTN_SIDE,
	BTN_EXTRA,
	BTN_FORWARD,
	BTN_BACK,
	BTN_B,
	BTN_A,
	BTN_BASE,
	BTN_BASE2,
	BTN_X
};
...
/*
* Remap input buttons to sensible ones that are not invalid.
* This only affects previous behavior for devices with more than ten or so buttons.
*/
const int key = (usage->hid & HID_USAGE) - 1;

if (key > 0 && key < ARRAY_SIZE(uclogic_extra_input_mapping)) {
        hid_map_usage(hi,
                        usage,
                        bit,
                        max,
                        EV_KEY,
                        uclogic_extra_input_mapping[key]);
        return 1;
}

And that’s pretty much the only major change I did to the original patch! You can see the patch in linux-input here.

However that isn’t the end of the story, as there’s one issue - libinput doesn’t think my tablet pad is a… tablet pad?

# libinput record /dev/input/event12
...
  udev:
    properties:
    - ID_INPUT=1
    - ID_INPUT_MOUSE=1
    - LIBINPUT_DEVICE_GROUP=3/28bd/91b:usb-0000:2f:00.3-4.1
...

Okay, that’s interesting - why is this a mouse? Uh oh, don’t tell me…

Fixing udev

So unfortunately before my tablet is fully functional, we have to touch another piece of critical Linux infrastructure - great. I want to dive into how libinput even decides device types, and I promise you it’s harder than it should be.

If you never touched the Linux input stack before (like I did before I started this project) you might think, “whats the big deal? the mouse says it’s a mouse, a keyboard says it’s a keyboard, whatever.” except it’s never that simple. If you’ve been reading my blog posts, you might think that’s just information evdev will hand over, which you’re wrong there too. All evdev tells userspace is what events the device will emit - that’s it². So who figures out what is what?

Unfortunately, it’s a guessing game. No you heard me right, udev guesses what devices are. So how do we tell what devices are which? Luckily systemd ships with a hardware database, which details stuff like id vendors and manual fixes for esoteric devices. This is actually what the original patch author did in order to fix udev classifying it as a mouse:

id-input:*:input:b0003v28BDp091Be0100*
 ID_INPUT_MOUSE=0
 ID_INPUT_TABLET=1
 ID_INPUT_TABLET_PAD=1
...

However I didn’t like this solution, and it would be a pain to find the modalias for every single tablet that ever existed, that udev mistakenly categorizes. Is there a better solution? Instead I changed the logic in src/udev/udev-builtin-input_id.c. Let’s take a look at the original code path:

...
is_pointing_stick = test_bit(INPUT_PROP_POINTING_STICK, bitmask_props);
has_stylus = test_bit(BTN_STYLUS, bitmask_key);
has_pen = test_bit(BTN_TOOL_PEN, bitmask_key);
finger_but_no_pen = test_bit(BTN_TOOL_FINGER, bitmask_key) && !test_bit(BTN_TOOL_PEN, bitmask_key);
for (int button = BTN_MOUSE; button < BTN_JOYSTICK && !has_mouse_button; button++)
        has_mouse_button = test_bit(button, bitmask_key);
has_rel_coordinates = test_bit(EV_REL, bitmask_ev) && test_bit(REL_X, bitmask_rel) && test_bit(REL_Y, bitmask_rel);
has_mt_coordinates = test_bit(ABS_MT_POSITION_X, bitmask_abs) && test_bit(ABS_MT_POSITION_Y, bitmask_abs);

/* unset has_mt_coordinates if devices claims to have all abs axis */
if (has_mt_coordinates && test_bit(ABS_MT_SLOT, bitmask_abs) && test_bit(ABS_MT_SLOT - 1, bitmask_abs))
        has_mt_coordinates = false;
is_direct = test_bit(INPUT_PROP_DIRECT, bitmask_props);
has_touch = test_bit(BTN_TOUCH, bitmask_key);
has_pad_buttons = test_bit(BTN_0, bitmask_key) && has_stylus && !has_pen;
...
if (has_mt_coordinates) {
        if (has_stylus || has_pen)
                is_tablet = true;
        else if (finger_but_no_pen && !is_direct)
                is_touchpad = true;
        else if (has_touch || is_direct)
                is_touchscreen = true;
}

if (is_tablet && has_pad_buttons)
        is_tablet_pad = true;

if (!is_tablet && !is_touchpad && !is_joystick &&
        has_mouse_button &&
        (has_rel_coordinates ||
        !has_abs_coordinates)) /* mouse buttons and no axis */
        is_mouse = true;

To explain a little of context, udev has several “built-in” commands to decide what devices are what, and if any quirks or workarounds need to be applied. Notably, the input_id builtin handles classifying input types for devices if they are not already in the hardware database. If you turn on udev debug logging, you can actually see the built-ins it runs whenever you connect, say a usb device to your system. As you can see, evdev gives udev the supported event types of the device, and then udev has to figure out what the device actually is. Now let’s look at the supported event types by the tablet pad:

# libinput record /dev/input/event12
...
devices:
- node: /dev/input/event12
  evdev:
    # Name: UGTABLET 21.5 inch PenDisplay Pad
    # ID: bus 0x3 vendor 0x28bd product 0x91b version 0x100
    # Supported Events:
    # Event type 0 (EV_SYN)
    # Event type 1 (EV_KEY)
    #   Event code 256 (BTN_0)
    #   Event code 257 (BTN_1)
    #   Event code 258 (BTN_2)
    #   Event code 259 (BTN_3)
    #   Event code 260 (BTN_4)
    #   Event code 261 (BTN_5)
    #   Event code 262 (BTN_6)
    #   Event code 263 (BTN_7)
    #   Event code 264 (BTN_8)
    #   Event code 265 (BTN_9)
    #   Event code 266 ((null))
    #   Event code 267 ((null))
    #   Event code 268 ((null))
    #   Event code 269 ((null))
    #   Event code 270 ((null))
    #   Event code 271 ((null))
    #   Event code 272 (BTN_LEFT)
    #   Event code 273 (BTN_RIGHT)
    #   Event code 274 (BTN_MIDDLE)
    #   Event code 275 (BTN_SIDE)
    # Event type 2 (EV_REL)
    #   Event code 6 (REL_HWHEEL)
    #   Event code 8 (REL_WHEEL)
    #   Event code 11 (REL_WHEEL_HI_RES)
    #   Event code 12 (REL_HWHEEL_HI_RES)
    # Event type 4 (EV_MSC)
    #   Event code 4 (MSC_SCAN)
...

I encourage you to read through the original systemd code, as the bug (I think) is hilariously obvious. The tablet pad never emits any BTN_STYLUS events. In fact, my tablet is not even configured on a firmware level to ever emit any BTN_STYLUS events, because the attached log above is without my patch! Obviously this is bad, as that means possibly other tablets are wrongly accused of being mice, and we should fix that logic. That’s also what I didn’t want to simply shove a new entry into the hardware database, as this turns out to be a udev bug.

So I made a systemd PR fixing the logic, maybe that might fix your tablet too!

Tilt support

One more thing I wanted to tackle was tilt support for the pen, which the driver says it supported but I haven’t tested yet. Simple, right? (you already know the answer to that question)

The first thing to do is just evdev:

# evtest /dev/input/event11
...
Event: time 1672152523.926503, -------------- SYN_REPORT ------------
Event: time 1672152523.938496, type 3 (EV_ABS), code 0 (ABS_X), value 37529
Event: time 1672152523.938496, type 3 (EV_ABS), code 1 (ABS_Y), value 13166
Event: time 1672152523.938496, type 3 (EV_ABS), code 27 (ABS_TILT_Y), value 12
Event: time 1672152523.938496, -------------- SYN_REPORT ------------
Event: time 1672152523.952501, type 3 (EV_ABS), code 27 (ABS_TILT_Y), value 13
Event: time 1672152523.952501, -------------- SYN_REPORT ------------
Event: time 1672152523.956501, type 3 (EV_ABS), code 0 (ABS_X), value 37534
Event: time 1672152523.956501, type 3 (EV_ABS), code 1 (ABS_Y), value 13138
Event: time 1672152523.956501, type 3 (EV_ABS), code 27 (ABS_TILT_Y), value 14
Event: time 1672152523.956501, -------------- SYN_REPORT ------------
Event: time 1672152523.962497, type 3 (EV_ABS), code 27 (ABS_TILT_Y), value 15
...

So it looks like it’s reporting tilt events, that’s good. Let’s go one layer up, and check with libinput. Actually, instead of using debug-events or record, libinput actually has a handy tablet testing function called debug-tablet:

#  libinput debug-tablet
Device: UGTABLET 21.5 inch PenDisplay Pen (event11)
Tool: pen serial 0, id 0
libinput:
tip: up
  x:                 299.38 [-------------------------------------------------|-----------------------------]
  y:                 140.64 [-----------------------------------------|-------------------------------------]
  tilt x:            -54.53 [---------------|---------------------------------------------------------------]
  tilt y:             41.21 [---------------------------------------------------------|---------------------]
  dist:                0.00 [|------------------------------------------------------------------------------]
  pressure:            0.00 [|------------------------------------------------------------------------------]
  rotation:            0.00 [|------------------------------------------------------------------------------]
  slider:              0.00 [---------------------------------------|---------------------------------------]
  buttons:
evdev:
  ABS_X:           29952.00 [-------------------------------------------------|-----------------------------]
  ABS_Y:           14077.00 [-----------------------------------------|-------------------------------------]
  ABS_Z:               0.00 [|------------------------------------------------------------------------------]
  ABS_TILT_X:        -55.00 [----|--------------------------------------------------------------------------]
  ABS_TILT_Y:         41.00 [-----------------------------------------------------------------|-------------]
  ABS_DISTANCE:        0.00 [|------------------------------------------------------------------------------]
  ABS_PRESSURE:        0.00 [|------------------------------------------------------------------------------]
  buttons: BTN_TOOL_PEN

Alright that’s good, it looks like libinput is recording the tilt too. How about inside of Krita, which has tilt support? Uhhh… let’s check the tablet tester:

Wait, there’s no way to check for tilt here! That was a really weird omission, so I fixed that in Krita 5.2. Then I thought there was no way that no developer in Krita somehow didn’t have tilt information debugged somewhere, so after a bit searching I found a tool for Tablet Event Logging activated by CTRL+SHIFT+T. Using that, we can find if Krita has picked up the tilt from our pen:

$ krita
...
krita.tabletlog: "[BLOCKED 2:] MouseMove        btn: 0 btns: 0 pos:  828, 515 gpos:  859,2778 hires:  858.956, 2777.95 Source:2"
krita.tabletlog: "[       ] TabletMove       btn: 0 btns: 0 pos:  828, 516 gpos:  859,2779 hires:  859.281,    2779 prs: 0.000000 Stylus Pen id: 0 xTilt: 0 yTilt: 0 rot: 0 z: 0 tp: 0 "
krita.tabletlog: "[BLOCKED 2:] MouseMove        btn: 0 btns: 0 pos:  828, 516 gpos:  859,2779 hires:  859.281,    2779 Source:2"
krita.tabletlog: "[       ] TabletMove       btn: 0 btns: 0 pos:  828, 517 gpos:  859,2780 hires:  859.441, 2779.72 prs: 0.000000 Stylus Pen id: 0 xTilt: 0 yTilt: 0 rot: 0 z: 0 tp: 0 "
krita.tabletlog: "[BLOCKED 2:] MouseMove        btn: 0 btns: 0 pos:  828, 517 gpos:  859,2780 hires:  859.441, 2779.72 Source:2"
krita.tabletlog: "[       ] TabletMove       btn: 0 btns: 0 pos:  829, 517 gpos:  860,2780 hires:  859.562, 2780.25 prs: 0.000000 Stylus Pen id: 0 xTilt: 0 yTilt: 0 rot: 0 z: 0 tp: 0 "
...

Huh? No tilt information at all? That’s slightly worrying. However, there is a layer in-between Krita and libinput, that being the compositor - in my case KWin. I actually didn’t know until now, but KWin has a handy debug tool available by searching KWin in KRunner:

Using that, we can check for the input events that it records:

Well that’s a nice consolation, it looks like KWin is picking up the tilt information from libinput too, so at least it’s not throwing it out. But why does Krita still not receive anything? For some reason, Krita receives tilt information on X11.

To explain, Krita does not interface with KWin directly. Instead, it uses standard protocols - either X or Wayland to communicate with the server or compositor respectively. So why does tilt work when Krita is running under X11 and not when running under Wayland? The trick is that it doesn’t matter, currently Krita is always running under X since it disables Wayland support for some reason. However, XWayland is still technically a Wayland client, so naturally the next place to look is how KWin sends Wayland events. That takes us to the class KWaylandServer

The protocol we care about here is the unstable “tablet” Wayland protocol, currently on version 2. It supports tilt events, so what’s the problem here? In reality, KWin was never sending the events in the first place:

...
const quint32 MAX_VAL = 65535;
tool->sendPressure(MAX_VAL * event->pressure());
tool->sendFrame(event->timestamp());
return true;
...

I actually came across this function when searching through relevant KWin merge requests, notably !3231 which has the unrealistic goal of complete tablet support in just one merge request! I cleaned up the relevant tilt support part, and submitted a new merge request which means pen tilt/rotation is supported under KDE Wayland now! Yay!

Dials

All is well and good now, right? That’s what I thought, until I realized my dials don’t work! I was so entrenched in everything else, that I completely neglected these little do-dads. To explain, these seem to be XP-PEN specific and are just glorified scrollwheels:

However, these are not Wacom rings. Rings on a Wacom tablet (to my knowledge) are actual rings, which report absolute positioning like a wheel. These dials are not those, but are sending relative “scroll” events. I had considered remapping this to buttons on the evdev layer, which was a bad idea since that meant that complicated things further up. Another option was to instead, emulate a Wacom ring by disguising the relative events and turning those into EV_ABS. I also threw that idea away, because that also seems to hide the problem.

If you’re curious, the dials actually worked without my patches - because remember that udev was classifying the pad as a mouse - so libinput thought no further. But now that it’s considered a real tablet pad, it rejects scroll wheel events.

Honestly the best way to solve this issue is to - unfortunately - touch every single bit of the input stack to accommodate these devices. Again.

• The Wayland tablet protocol must be changed to add a few new properties for dials on pads. Tracking via !122.
• Libinput must be modified to expose these dials and correctly map them. Tracking via !845.
• KWin must be modified to support sending dial events in support of the tablet protocol changes. Currently not tracking.
• These dials (and we should also include rings and strips too) should be exposed in the Tablet Settings KCM too. Currently not tracking either.

As you can see, it’s going to be a complex process to support these stupid little circles, but I’m going all in. Luckily, with the rest of my patches going through - everything except for dials on the XP-PEN Artist 22R Pro device should be well supported now. In the coming months, I hope to make headway in supporting dials in KDE.

So I bought an art tablet this year, the XP-Pen Artist 22R Pro which comes with a pen. This pen does not work under Linux, sometimes.

While almost every part of the tablet works, only one of the two stylus buttons is functional. One button is middle mouse click, and the other one is right mouse click. For some reason, only the first stylus button works! This is obviously troublesome, so where do we begin to fix this issue? Let me take you on a journey, if you have no experience with how input works on Linux - well that makes two of us!

Figuring Out The Problem

I work in Krita, so the first place to check is Krita’s tablet testing tool first. Looking at the log yields us something like this:

...
Stylus move X=120.37 Y=129.63 B=4 P=0.0% S=0.0 (DRAW)
Stylus release X=120.37 Y=129.63 B=0 P=0.0% S=0.0
...

According to the legend, we only care about the section named B which tells us which button is pressed. On my pen it’s:

• 0 is released (not pressing on the screen)
• 1 is drawing (pressed on the screen, it doesn’t count hovering)
• 4 is the “middle mouse” button
• The nonfunctional button does not show up at all of course.

So that at least means Krita isn’t the root cause, also testing it on the desktop or any other application yields the same result - the button is non-functional. In some cases, I’ve found the button to actually turn off the stylus entirely, but I’m not sure why yet.

How does tablet input on Wayland actually function? Let’s move down a layer and look at KWin, the Wayland compositor for KDE Plasma.

On Wayland, input is typically handled using libinput, and now even recent X versions have a libinput driver. Digging through the libinput backend on KWin doesn’t reveal anything particularly exciting, so we’ll assume KWin isn’t at fault either for now. Luckily, libinput has a built-on logging utility we can use to check what it sees!

First we want to check what devices libinput sees:

# libinput list-devices
...
Device:           UGTABLET 21.5 inch PenDisplay Mouse
Kernel:           /dev/input/event11
Group:            5
Seat:             seat0, default
Capabilities:     pointer
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      disabled
Nat.scrolling:    disabled
Middle emulation: disabled
Calibration:      identity matrix
Scroll methods:   button
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   flat *adaptive
Rotation:         n/a

Device:           UGTABLET 21.5 inch PenDisplay Keyboard
Kernel:           /dev/input/event12
Group:            5
Seat:             seat0, default
Capabilities:     keyboard
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   n/a
Rotation:         n/a

Device:           UGTABLET 21.5 inch PenDisplay
Kernel:           /dev/input/event13
Group:            5
Seat:             seat0, default
Size:             477x268mm
Capabilities:     tablet
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      identity matrix
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   none
Rotation:         n/a

So it looks like the device we’re interested in is/dev/input/event13. We can now view the debug event log:

# libinput debug-events --verbose
...
 event2   POINTER_MOTION          +25.044s       -1.66/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.045s       -1.66/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.046s       -1.87/  1.87 ( -1.00/ +1.00)
 event2   POINTER_MOTION          +25.047s       -1.87/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.049s       -1.38/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.050s       -1.38/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.051s       -1.66/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.053s       -1.38/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.055s       -1.11/  0.00 ( -1.00/ +0.00)
 event2   POINTER_MOTION          +25.057s       -1.11/  0.00 ( -1.00/ +0.00)
...

Oh right, there’s a lot of junk in there. We can slim it down to the only device we care about though:

# libinput debug-events --verbose --device /dev/input/event13
...
event13  TABLET_TOOL_AXIS        +9.455s               371.93*/88.01*  tilt: 8.06/15.12        pressure: 0.00
event13  TABLET_TOOL_AXIS        +9.545s               371.67*/88.07*  tilt: 8.06/15.12        pressure: 0.00
event13  TABLET_TOOL_BUTTON      +9.549s       331 (BTN_STYLUS) pressed, seat count: 1
event13  TABLET_TOOL_AXIS        +9.607s               371.38*/88.37*  tilt: 8.06/15.12        pressure: 0.00
event13  TABLET_TOOL_AXIS        +9.627s               371.38/88.56*   tilt: 8.19*/15.12       pressure: 0.00
...

As you can see, whenever I press the first stylus button it reports BTN_STYLUS, but when I press the second one it instead reports itself as BTN_TOUCH (not shown in the snippet).

Now before we go further, I just wanted to confirm whether or not the pen actually worked at all so I booted up Windows real quick to test. And it does work as expected, darn.

Going Deeper

Now it’s easy to assume libinput is the culprit and the one to be fixed, like I did. At first, I wrote up a quick patch to remap the wrong BTN_TOUCH inputs and inject proper BTN_STYLUS2 events but honestly that’s dirty. So what is beneath libinput? evdev!

So now that we know the (possible) culprit, we need to dig deeper into libinput. Like a good software project, libinput has developer documentation for us to look at.

Let’s check the event device that Linux gives us, using the handy evtest:

# evtest /dev/input/event13
...
Event: time 1671823416.485402, -------------- SYN_REPORT ------------
Event: time 1671823416.517402, type 4 (EV_MSC), code 4 (MSC_SCAN), value d0045
Event: time 1671823416.517402, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 0
Event: time 1671823416.517402, type 1 (EV_KEY), code 320 (BTN_TOOL_PEN), value 0
Event: time 1671823416.517402, type 3 (EV_ABS), code 26 (ABS_TILT_X), value 0
Event: time 1671823416.517402, -------------- SYN_REPORT ------------
...
Event: time 1671823416.825414, -------------- SYN_REPORT ------------
Event: time 1671823416.835640, type 4 (EV_MSC), code 4 (MSC_SCAN), value d0045
Event: time 1671823416.835640, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1671823416.835640, type 3 (EV_ABS), code 26 (ABS_TILT_X), value 29
Event: time 1671823416.835640, -------------- SYN_REPORT ------------

Uh oh, the same bug appears here too. So it’s time to sigh look deeper into the stack. Unfortunately, going deeper means stepping into the kernel. What is actually handling the input?

# lsusb -t
...
    |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/2p, 480M
        |__ Port 1: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 3: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 3: Dev 9, If 1, Class=Human Interface Device, Driver=usbhid, 12M
            |__ Port 3: Dev 9, If 2, Class=Human Interface Device, Driver=usbhid, 12M
...

It looks like the “usbhid” driver which makes sense, this is a USB HID device after all. However at this point is where I got stuck, because as far as I know there is no way to extract the specific HID driver in use (unless you know the actual module name). This is annoying, so I went digging inside of the kernel source tree for any mention of my device ID (0x091b). Nope. So in turn we can assume it’s using the generic HID driver, which is actually kind of impressive.

So what is the proper HID driver for this device? Well after some research it turns out to be uclogic which handles a bunch of UGTablet, Huion and other misc Asian tablet devices. Unfortunately, they haven’t added any support for this model but someone has.

Digimend Project

Luckily there is a project dedicated to upstreaming device drivers for these tablets, and Aren Villanuvea (also known as “kurikaesu”) known for userspace-tablet-driver-daemon has reverse engineered the tablet already. Better yet, he even implemented most of the work in uclogic already! You can see the PR here.

Now that’s where the story ends, yay - except that my device still doesn’t work. That’s because the PR never made it into Digimend, and it was closed by the author without explanation. And because it never made it into Digimend, it never landed upstream. It looks like Aren has decided it was a better use of his time to implement it into userspace instead.

The daemon is nice and all, but I would prefer kernel support for this device for numerous reasons. And what’s worse is that it’s so close to being complete that it sucks that the work hasn’t continued. Oh well…

Kernel Hacking

So now I’m trying to upstream the uclogic patch! Oh how I wish it was a bug in a higher layer… I’ll be taking over Aren’s work and trying to clean up the patch and reduce it down to just supporting the 22R Pro, since that’s the only tablet I own. Here’s what works:

• Both stylus buttons work!
• Pen pressure works.
• Both dials work, although the right one is registered as horizontal scroll which is odd - that might have to be re-mappable on a higher layer.
• The tablet buttons “work” but some of them are not registered properly as there’s more buttons than HID definitions for buttons. I might have to split this up into two devices, or something.

Now here’s my to-do list:

• Hopefully receive Aren’s blessing to release the patches with his original ownership.
• Figure out a fix with the tablet buttons, and contact Nicolas Fella (who is working on the re-mappable tablet buttons in 5.27) to see what needs to be done so they’re re-mappable in the new GUI.
• Choose whether or not to contribute it directly to upstream (slow?) or back to Digimend.

If anyone is familiar with kernel contributions in the HID subsystem, or know the right people (like the ones mentioned in the article, hi!) I would love to get in contact!

I’m happy to announce the release of Tokodon 22.11.2 (and 22.11.1 who I released earlier this month and forgot to properly announce). These releases contain mostly bug fixes but also some welcome interface improvements.

First this adds an account switcher (similar to the one Tobias Fella implemented in NeoChat). Very usefully when you need to manage multiple accounts and want to quickly switch between them.

This also change the image preview from appearing in a separate full screen window to be contained inside the window. This follow the similar change from from James Graham in NeoChat.

Joshua Goins improved the loading of media attachment and made it possible to now hide sensitive image by default using the blurhash effect. This is also using the already existing implementation of blurhash from Tobias in NeoChat and you might start to see a pattern in this release. ;)

Finally I added support for custom emojis in many places inside the UI. Perfect if you want to show you true verified checkmark in your profile :)

Aside from the nice new improvements, I improved the spacing in the app and while not perfect yet, I hope this makes Tokodon more enjoyable to use. Joshua Goins has also made various improvements to our internal networking code and this should offer better reliability and less prone to crash code. And I fixed an important crash on start-up that was affecting a lot of users

Finally I started adding unit tests in Tokodon and added the infrastructure to mock a Mastodon server. We now have reached 12% unit tests coverage and I hope this number will grow after each release.

Packager section

You can find the package on download.kde.org and it has been signed with my GPG key.

Day 0

Day 1

• Building the Future of Qt, Together: What have happened in The Qt Project during the last two years
• Goals old and new! : What are Goals that were the focus of the community for the next year
  
  
• A Brief History of Terminals, and what the future holds for Konsole: Moto was "Trying to sell konsole to non kde users". I am not a KDE user and I really liked some cool stuff you can do with terminal
• Full Steam ahead! :Seen how Plasma fits into the Steamdeck and what aspects of KDE made us the right choice for their new userbase

Day 2

• Launching an application - How hard can it be? It was what I wanted actually since we are going to launch an application with the Open Source Team of our Univeristy.
• Healthy Mind, Healthy Code : Maybe this was my favourite talk

This blog post was not easy to write as it started as a very simple thing intended for developers, but later, when I was digging around, it turned out that there is no good single resource online on copyright statements. So I decided to take this stab at writing one.

I tried to strike a good balance between 1) keeping it short and to the point for developers who just want to know what to do, and 2) FOSS compliance officers and legal geeks who want to understand not just best practices, but also the reasons behind them.

If you are extremely short on time, the TL;DR should give you the bare minimal instructions, but if you have just 2 minutes I would advise you to read the actual HowTo a bit lower below.

Of course, if you have about 20 minutes of time, the best way is always to start reading at the beginning and finish at the end.

TL;DR¶

Use the following format:

SPDX-FileCopyrightText: © {$year_of_file_creation} {$name_of_copyright_holder} <{$contact}>

SPDX-License-Identifier: {$SPDX_license_name}

… put that in every source code file and go check out (and follow) REUSE.software best practices, published by the FSFE.

E.g. for a file that I created today and I released under the BSD-3-Clause license, I would use put the following as a comment at the top of the source code file:

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

Introduction and copyright basics¶

Copyright is automatic (since the Berne convention) and any work of authorship is automatically protected by it – essentially giving the copyright holder¹ exclusive power over their work. In order for your downstream to have the rights to use any of your work – be that code, text, images or other media – you need to give them a license to your work.

So in order for you to copy, implement, modify etc. the code from others, you need to be given the needed rights – i.e. a license² –, or make use of a statutory limitation or exception³. And if that license has some obligations attached, you need to meet them as well.

In any case, you have to meet the basic requirements of copyright law as well. At the very least you need to have the following two in place:

• attribution – list the copyright holders and/or authors – especially in jurisdictions which recognise moral rights (e.g. most of EU) it is important to keep the names of authors, if they are listed;
• license(s) – since a license is the only thing that gives anybody other than the copyright holder themself the right to use the code, you are very well advised to have a notice of the the license and its full text present – this goes for both for your outbound licenses and the inbound licenses you received from others by using 3^rd party works, such as copied code or libraries.

The good news is that attribution is a discretionary right that can be exercised by the author should they choose to. And you are obliged to keep the attribution notices only insofar as the author(s) made use of that right. Which means that if the author has not listed themselves, you do not have to hunt them down yourself.

Why have the copyright statement?¶

Which brings us to the question of whether you need to write your own copyright statement⁴.

First, some very brief history …

The urge to absolutely have to write copyright statements stems from the inertia in the USA, as it only joined the Berne convention in 1989, well after computer programs were a thing. Which means that before then the US copyright law still required an explicit copyright statement in order for a work to be protected.

Attribution is practically unavoidable, because a) most licenses explicitly call for it, and if that fails b) copyright laws of most jurisdictions require it anyway.

And if that is not enough, then there is also c) sometimes you will want to reach the original author(s) of the code for legal or technical reasons.

So storing both the name and contact information makes sense for when things go wrong. Finding the original upstream of a runaway file you found in your codebase – if there are no names or links in it – is a huge pain and often includes (currently still) expensive specialised software. I would suspect the onus on a FOSS project to be much lower than on a corporation in this case, but still better to put a little effort upfront than having to do some serious archæology later.

How to write a good copyright statement and license notice¶

Finally we come to the main part of this article!

A good copyright statement should consist of the following information:

• start with the © sign;
• the year of the first publication – a good date would be the year in which you created the file and then do not touch that date anymore;
• the name of the copyright holder – typically the author, but depending on the circumstances might be their employer or if there is a CLA in place the legal entity or person they transferred their rights to;
• a valid contact to the copyright owner

As an example, this is what I would put on something I wrote today:

© 2020 Matija Šuklje <matija@suklje.name>

While you are at it, it would make a lot of sense to also notify everyone which license you are releasing your code under as well. Using an SPDX ID is a great way to unambiguously state the license of your code. (See note mentioned below for an example of how things can go wrong otherwise.)

And if you have already come so far, it is just a small step towards following the best practices as described by REUSE.software by using SPDX tags to make your copyright statement (marked with SPDX-FileCopyrightText) and license notice (marked with SPDX-License-Identifier and followed by an SPDX ID).

Here is now an example of a copyright statement and license notice that check all the above boxes and also complies with both the SPDX and the REUSE.software specifications:

SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>

SPDX-License-Identifier: BSD-3-Clause

Now make sure you have these in comments of all your source code files.

Q&A¶

Over the years, I have heard many questions on this topic – both from developers and lawyers.

I will try to address them below in no particular order.

If you have a question that is not addressed here, do let me know and I will try to include it in an update.

Why keep the year?¶

Some might argue that for the sake of simplicity it would be much easier to maintain copyright statements if we just skip the years. In fact, that is a policy at Microsoft/GitHub at the time of this writing.

While I agree that not updating the year simplifies things enormously, I do think that keeping a date helps preserve at least a vague timeline in the codebase. As the question is when the work was first expressed in a medium, the earliest date provable is the time when that file was first created.

In addition, having an easy way to find the earliest date of a piece of code, might prove useful also in figuring out when an invention was first expressed to the general public. Something that might become useful for patent defense.

This is also why e.g. in Liferay our new policy is to write the year of the file creation, and then not change the year any more.

Why not bump the year on change?¶

I am sure you have seen something like this before:
Copyright (C) 1992, 1995, 2000, 2001, 2003 CompanyX Inc.

The presumption behind this is that whenever you add a new year in the copyright statement, the copyright term would start anew, and therefore prolong the time that file would be protected by copyright.

Adding a new year on every change – or, even worse, simply every 1^st January – is a practice still too wide-spread even today. Unfortunately, doing this is useless at best, and misleading at worst. Needless to say, if you do this as part of your build process, this is extra wrong. For the origin of this myth see the short history above.

A big problem with this approach is that not every contribution is original or substantial enough to be copyrightable – even the popular 5 (or 10, or X) SLOC rule of thumb⁵ is legally-speaking very debatable.

So, in order to keep your copyright statement true, you would need to make a judgement call every time whether the change was substantial and original enough to be granted copyright protection by the law and therefore if the year should be bumped. And that is a substantial test for every time you change a file.

On the other hand copyright lasts at least 50 (and usually 70) years⁶ after the death of the author; or if the copyright holder is a legal entity (e.g. CompanyX Inc.), since publication. So the risk of your own copyright expiring under your feet is very very low.

But, honestly, how likely is it that 50 years from now the same (unaltered) code would still be (commercially) interesting?

… and if it turns out you do need to bump the year eventually, you still have, at worst, 50 years to sort it out – so, ample opportunity to mitigate the risk.

In addition to that, as typically a single source code file is just one of the many cogs in a bigger piece of software, what you are more concerned with is the software product/project as a whole. As the software grows, you will keep adding new files, and those will obviously have newer years in them. So the codebase as a whole work will already include copyright statements with newer years in it anyway.

Why not use a year range?¶

Similar to the previous question, the year span (e.g. 1990-2013) is basically just a lazy version of bumping the year. So all of the above-mentioned applies.

A special case is when people use a range like {$year}-present. This has almost all of the above-mentioned issues⁷, plus it adds another dimension of confusion, because what constitutes the “present” is an open – and potentially philosophical – question. Does it mean:

• the time when the file was last modified?
• the time it was released as a package?
• the time you downloaded it (maybe for the first time)?
• the time you ran it the last time?
• or perhaps even the ever eluding “right now”?

As you can see, this does not help much at all. Quite the opposite!

But doesn’t Git/Mercurial keep a better track?¶

Not reliably.

Git (and other VCS) are good at storing metadata, but you should be careful about it.

Git does have an Author field, which is separate from the Committer field. But even if we were to assume – and that is a big assumption⁸ – Git’s Author was the actual author of the code committed, they may not be the copyright holder.

Furthermore, the way git blame and git diff currently work, is line-by-line and using the last change as the final author, making Git suboptimal for finding out who actually wrote what.

And ultimately – and most importantly – as soon as the file(s) leave the repository, the metadata is lost. Whether it is released as a tarball, the repository is forked and/or rebased, or a single file is simply copied into a new codebase, the trace is lost.

All of these issues are addressed by simply including the copyright statement and license information in every file. REUSE.software best practices handle this very well.

Why the © sign?¶

Some might argue that the English word “Copyright” is so common nowadays that everyone understands it, but if you actually read the copyright laws out there, you will find that using © (i.e. the copyright sign) is the only way to write a copyright statement that is common in copyright laws around the world⁹.

Using the © sign makes sense, as it is the the common global denominator.

While the © sign is a pet peeve of mine, from the practical point of view, this is the least important point here. As we established in the introduction, copyright is automatic, so the actual risk of not following the law by its letter is pretty low if you write e.g. “Copyright” instead.

Why leave a contact?¶

A contact is in no way required by copyright law, but from practical reasons can be extremely useful.

It can happen that you need to access the author and/or copyright holder of the code for legal or technical question. Perhaps you need to ask how the code works, or have a fix you want to send their way. Perhaps you found a licensing issue and want to help them fix it (or ask for a separate license). In all of these cases, having a contact helps a lot.

As pretty much all of internet still hinges on the e-mail¹⁰, the copyright holder’s e-mail address should be the first option. But anything really goes, as long as that contact is easily accessible and actually in use long-term.

What if there are many authors or copyright is held by a legal entity?¶

There will be cases where the authorship will be very dispersed or lie with a legal entity instead. In those cases, it might be more sense to provide a URL to either the project’s or legal entity’s homepage and provide useful information there. If a project lists copyright holders in a file such as AUTHORS or CONTRIBUTORS.markdown a permalink to that file (in the master) of the publicly available repository could also be a good URL option.

What if I added code to an existing project?¶

A major benefit of FOSS is that people collaborate on the same project, so it is inevitable that several people will be touching the same file. If that file already includes a copyright statement, this is a good question.

If there are only a handful of people who wrote that file, it would be fine to just add a new line with your copyright statement, as such:

SPDX-FileCopyrightText: © 2018 Matija Šuklje <matija@suklje.name>
SPDX-FileCopyrightText: © 2021 Master Hacker <mh@example.org>

But if there are many authors that would need to be added that way, to avoid clutter, it would make sense to instead create an AUTHORS.* or CONTRIBUTORS.* file as described in the question above.

What about public domain?¶

Public domain is tricky.

In general the public domain are works to which the copyright term has expired¹¹.

While in some jurisdictions (e.g. USA, UK) you can actually waive your copyright and dedicate your work to public domain, in most jurisdiction (e.g. most of EU member countries) that is not possible.

Which means that depending on the applicable jurisdiction, it may be that although an author wrote that they dedicate their work into public domain this does not meet the legal standard for it to actually happen – they retain the copyright in their own work.

Unsurprisingly, FOSS compliance officers and other people/projects who take copyright and licensing seriously are typically very wary of statements like “this is public domain”.

This can be mitigated in two ways:

• instead of some generic wording, when you want to dedicate something to public domain use a tried and tested public copyright waiver / public domain dedication with a very permissive license, such as 0BSD for code or CC0-1.0 for non-code; and
• include your name and contact if you are the author in the SPDX-FileCopyrightText: field – 1) because in doubt that will associate you with your dedication to the public domain, and 2) in case anything is unclear, people have a contact to you.

This makes sense to do even for files that you deem are not copyrightable, such as config files – if you mark them as above, everyone will know that you will not exercise your author’s rights (if they existed) in those files.

It may seem a bit of a hassle for something you just released to the public to use however they see fit, without people having to ask you for permission. I get that, I truly do! But do consider that if you already put so much effort into making this wonderful stuff you and donating it to the general humanity, it would be a huge pity that, for (silly) legal details, in the end people would not (be able to) use it at all.

What about minified JS?¶

Modern code minifiers/uglifiers tend to have an optional flag to preserve copyright and licensing info, even when they rip out all the other comments.

The copyright does not simply go away if you minify/uglify the code, so do make sure that you use a minifier that preserves both the copyright statement as well as the license (at least its SPDX Identifier) – or better yet, the whole REUSE-compliant header.

What is wrong with “All rights reserved”?¶

Often you will see “all rights reserved” in copyright statements even in a FOSS project.

The cause of this, I suspect, lies again from a copycat behaviour where people tend to simply copy what they so often found on a (music) CD or in a book. Again, the copyright law does not ask for this, even if you want to follow the fullest formal copyright statement rules.

But what it does bring, is confusion.

The statement “all rights reserved” obviously contradicts the FOSS license the same file is released under. The latter gives everyone the rights to use, study, share and improve the code, while the former states that all of these rights the author reserves to themself.

So, as those three words cause a contradiction, and do not bring anything useful to the table in the first place, you should not write them in vain.

What if I work for a company, NGO, university?¶

In many jurisdictions if you are in an employment relationship (at least full employment), your employer would be the one holding the relevant rights.

If the revelant jurisdiction is Slovenian (as an EU example), ZASP §101 (unofficial English translation) says the following:

(1) When copyright work is created by an employee in the execution of his duties or following the instructions given by his employer (copyright work created in the course of employment), it shall be deemed that the economic rights and other rights of the author to such work are exclusively assigned to the employer for the period of ten years from the completion of the work, unless otherwise provided by contract.

(2) On the expiration of the term mentioned in the foregoing paragraph, the rights mentioned in the foregoing paragraph revert to the employee, however, the employer can claim a new exclusive assignment of these rights, for adequate remuneration.

If the relevant jurisdiction is USA this would fall under “work for hire” and the employer would be the copyright holder of any work their employee makes that are within the scope of their employment. There are also other cases where “work for hire” kicks in, but the sloppy rule of thumb is that if the closer the work’s creation was controlled by the employer/hiring party, the more likely it would be the copyright holder.

In any case, if your contract says you are transferring the rights to your employer or the other party, then they would be the copyright holder (e.g. in USA) or at least the exclusive rights holder (e.g. most of EU).

On a similar note, an author / copyright holder / exclusive right holder can transfer the rights they have to another person by written agreement.

What if I want to stay anonymous?¶

Whether you want to sign your work with your legal name, a pseudonym¹⁴ or even not at all is your own decision as author.

But do take into consideration that if you want to stay anonymous, you will have a much harder time proving you are the author of that piece of code later. For this reason, it would make sense to release your anonymous code under a “public-domain-like” license such as CC0-1.0 or Unlicense.

In any case, unless you have good reasons not to (e.g. for your personal safety), it would be really useful to use the copyright tag to at least include a contact. In case you want to just use a pseudonym, that should not be much of an issue. But in the case you want to stay anonymous, the contact could be simply the URL to the project’s homepage and instead of your name you could state the name of the project, or leave it empty.

My project uses DCO. Does this conflict with it?¶

Not at all. Quite the opposite!

When signing the DCO 1.1, you state that you are contributing under the license as stated in the file. If the file you contributed (to), includes an SPDX license tag, that supports the DCO.

While signing the DCO typically requires you to use git commit --signoff when you commit, so it stores your agreement with DCO in the repository history, if a file is copied outside that git repository that information, along with your authorship information is lost. So it makes sense to include your copyright statement and contact in each file even if you sign a DCO.

How do I find out the date of file creation?¶

If you are creating a new file, this is trivial, as you just need to enter the current year (e.g. with date +Y).

But if you are adding your copyright statements to your existing software, that might indeed be a bit more tricky.

Luckily, if your project uses a VCS and all its history is tracked in it, you can find the date of the first commit for each file. If using Git, the following command will output you the year the file was first authored:

git log --follow --format=%as {$path} | tail -n1 | cut -c-4

Failing that, you could check with your filesystem (e.g. for EXT4), but this can be of very questionable quality, if you know the file landed on your disk at a later date, you changed disks etc.

If even that is not a viable possibility, just use your best judgement.

Do legal entities even have right to attribution?¶

That is a tricky question, and probably depends on the jurisdiction in question.

This analysis tries to answer those questions from the Slovenian jurisdiction.

What about if I merge or split a file or just use a snippet?¶

In case you copy just a part of a file (assuming that part is copyrightable) into another file, you can put retain/copy its licensing metadata by wrapping its SPDX/REUSE tags between an SPDX-SnippetBegin and an SPDX-SnippetEnd tag. For more details see the Snippet tags format annex of the SPDX specification.

An example would se as follows:

# SPDX-SnippetBegin

# SPDX-FileCopyrightText: © 2020 Matija Šuklje <matija@suklje.name>
# SPDX-License-Identifier: BSD-3-Clause

...
import sense
lots_of_cool_code()
...

# SPDX-SnippetEnd

You can use this also when e.g. concattenating different JS files into one.

In any case, unless you are the copyright holder, do not remove or alter other people’s copyright statements. You can always add a new one, if it is needed.

hook out → hat tip to the TODO Group for giving me the push to finally finish this article and Carmen Bianca Bakker, Robbie Morrison, as well as the Legal Network for some very welcome feedback