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.

Ah, working with more than one screen, nice and convenient, but always has been the scourge of usability, due to broken hardware and software, on every platform you can imagine. And yes, on Plasma we are notorious to have several problems with regard to multi screens, which spurred many bug reports.

TL;DR

For Plasma 5.27 we did a big refactor on how the screens are managed (and how they are mapped to desktops and panels) which hopefully should solve many of those issues, creating a much more predictable experience, both for “fixed” multi screen setups (like a setup at your desk) and “on the go” (like attaching a projector at a conference).

• No more default empty desktops after connecting a screen that you already connected in the past
• No more desktops, wallpapers, widgets and panels lost after restart
• No more different sets of desktops between X11 and Wayland
• Better experience when using USB-C based docks

UI wise on the Systemsettings module nothing will change in the most common case, when you have one or two screens, where you will be presented with the usual “primary” checkbox.

When you have 3 or more screens, instead of s simple “Primary” checkbox, you will be presented with a dialog where you can rearrange the screens in a logical order, so that you can say: “This is my screen number one, this is my screen number two etc.”

This will map exactly to what “screen number one, two etc” are for the Plasma shell, so that whatever desktops, wallpapers, widgets and panels are on the “screen number one” will always be on the “screen number one”, never disappearing again, same for each screen, giving a completely predictable, and stable multiscreen setup.

For 5.27 I worked mostly on the Plasmashell part, but many thanks and shouts to Ivan for his work on KScreen and to Xaver for his work on the KWin and Wayland protocol parts.

Long story: the moving parts

I would like to do a semi-technical but still quite high level description on how our multiscreen infrastructure works, and what did we change.

When you have multiple monitors connected, assuming the kernel and drivers will do the right thing (which… doesn’t always happen), either X11 or Wayland (so in our case the KWin Wayland compositor) will see the screens and have info about them we can enumerate and manage.

KScreen

In Plasma we have a daemon/library to manage the screens, called KScreen. It will save a configuration for each combination of screens it encountered. each screen is identified uniquely by its EDID, and when this fails for the above reasons, the connector name the screen is connected to (under X or libdrm they will have names like HDMI-A-1, DP-2, eDp1 and so forth). connector names are also not optimal, but is the best that can be done in case of a bad monitor (For 5.27 Xaver fixed a quite big issue on this fallback path which likely caused several of the reported bugs).

The user then can chose with the Systemsetting module how the screens are arranged, their resolutions, which is the primary and what not. When a screen is connected or disconnected, KScreen will search for an existing configuration for this set of screens and restore that one.

Plasma

The Plasma shell also has to be aware of multiple screens arrangement, because you want the desktops with their wallpapers, widgets and icons to be on the screen you expect it to, as well all the panels to be always on the “proper” screen you expect it to. And that’s where we had a lot of problems in the past, and various approaches have been attempted.

Current

Currently, up to 5.26 Plasma relied on two concepts for working out which screen a desktop and panel should be. Combining a single primary monitor and using screen connectors names for disambiguate second and third screens. In theory …

There are a couple of things that can go wrong with this: between X11 and Wayland, connector names tend to be different (for instance HDMI-1 vs HDMI-A-1 on my system).

Another problem is related to the the USB-C based docks that have video outputs (such as the Steamdeck one, but is common to any other model and brand). They dynamically create and delete the outputs and connectors when they are plugged and unplugged, but the connector name is not stable between different plugs/unplugs: sometimes after re-plugging the old names are not recycled, but increased (so for instance if those were DP-2 and DP-3, they may become all the sudden DP-4 and DP-5). Since we used to store those names, we have a problem: each time a new connector name is encountered is treated as a completely new thing, giving its new empty default desktop and no panels, causing many wtf moments.

Plasma Containments (technical name of the desktops and panels) always had a screen property associated to them which is just an integer: 0 for the primary screen and then 1,2,etc for the others.

5.27

The new approach builds on a single design, extending the primary monitor concept to multiple monitors, which cleans up the codepaths even for the two monitor case.

So we now dropped this association map between screen number integers and connector names, and we go with this ordered list all the way down, so now Plasma, KWin and KScreen agree exactly who “Screen 1” is.

We have a new Wayland protocol for screen ordering (as well an X11 counterpart) for KScreen and KWin to agree to which one is the real logical ordering of the screens, so Plasmashell will now follow this without attempting to identify monitors by itself, removing a very big failure point.

As said, When your system has only 2 screens, in the Systemsettings module you’ll see exactly the UI it had: just a checkbox to select which one is the “Primary”, so no surprises here. When you have 3 screens or more then you are presented with a dialog where you can visually reorder the screens, to decide which is the first, which is the second etc.

In this way, you’ll always be sure that whichever screen was set as “first” will have your “main” set of panels and desktop widgets, that you will never lose, also whichever you set as “second” will always have the desktop and panels you set it and never change and so on.

At KDE we have multiple levels of quality assurance ranging from various degrees of a humans testing features to fully automated testing. Indeed automated testing is incredibly important for the continued quality of our software. A big corner stone of our testing strategy are so called unit tests, they test a specific piece of our software for its behavior in isolation. But for many aspects of our software we need a much higher level view, testing pieces of Plasma’s application launcher in isolation is all good and well but that won’t tell us if the entire UI can be easily navigated using the keyboard. For this type of test we require a different testing approach altogether. A couple months ago I’ve set set out to create a testing framework for this use case and I’m glad to say that it has matured enough to be used for writing tests. I’d like to walk you through the technical building blocks and a simple example.

Let us start of by looking at the architecture at large. So… there’s Selenium which is an incredibly popular, albeit web-oriented, testing framework. Its main advantages for us are its popularity and that it sports a server-client split. This means we can leverage the existing client tooling available for Selenium without having to write anything ourselves, we only need to grow a server. The server component, called a WebDriver, implements the actual interaction with UI elements and is generic enough to also apply to desktop applications. Indeed so thought others as well: there already exists Appium - it extends Selenium with more app-specific features and behaviors. Something for us to build upon. The clients meanwhile are completely separate and talk to the WebDriver over a well defined JSON REST protocol, meaning we can reuse the existing clients without having to write anything ourselves. They are available in a multitude of programming languages, and who knows maybe we’ll eventually get one for writing Selenium tests in QML ;)

That of course doesn’t explain how GUI testing can work with this on Linux. Enter: AT-SPI. AT-SPI is an accessibility API and pretty much the standard accessibility system for use on Linux. Obviously its primary use is assistive technologies, like the screen reader Orca, but to do its job it essentially offers a toolkit-independent way of introspecting and interacting with GUI applications. This then gives us a way to implement a WebDriver without caring about the toolkit or app specifics. As long as the app supports AT-SPI, which all Qt apps do implicitly, we can test it.

Since all the client tooling is independent of the server all we needed to get GUI testing going was a WebDriver that talks to AT-SPI.

That is what I set out to write and I’m happy to announce that we now have an AT-SPI based WebDriver, and the first tests are popping into existence already. There is also lovely documentation to hold onto.

So, without further ado. Let us write a simple test. Since the documentation already writes one in Python I’ll use Ruby this time around so we have some examples of different languages. A simple candidate is KInfoCenter. We can test its search functionality with a couple of lines of code.

First we need to install selenium-webdriver-at-spi, clone it, cmake build it, and cmake install it. You’ll also need to install the relevant client libraries. For ruby that’s simply running gem install appium_lib.

Then we can start with writing our test. We will need some boilerplate setup logic. This is more or less the same for every test. For more details on the driver setup you may also check the wiki page.

  def setup
    @appium\_driver = Appium::Driver.new(
      {
        'caps' => { app: 'org.kde.kinfocenter.desktop' },
        'appium\_lib' => {
          server\_url: 'http://127.0.0.1:4723',
          wait\_timeout: 10,
          wait\_interval: 0.5
        }
      }, true
    )
    @driver = @appium\_driver.start\_driver
  end

The driver will take care of starting the correct application and make sure that it is actually running correctly. Next we’ll write the actual test. Let’s test the search. The first order of business is using a tool called Accerciser to inspect the AT-SPI presentation of the application. For more information on how to use this tool please refer to the wiki. Using Accerciser I’ve located the search field and learned that it is called ‘Search’. So, let’s locate it and activate it, search for the CPU module:

  def test\_search
    search = driver.find\_element(:name, 'Search')
    search.click
    search.send\_keys('cpu')

Next let us find the CPU list item and activate it:

    cpu = driver.find\_element(:class\_name, '\[list item | CPU\]')
    assert(cpu.displayed?)
    cpu.click

And finally let’s assert that the page was actually activated:

    cpu\_tab = driver.find\_element(:class\_name, '\[page tab | CPU\]')
    assert(cpu\_tab.displayed?)

To run the complete test we can use the run wrapper: selenium-webdriver-at-spi-run ./kinfocentertest.rb (mind that it needs to be +x). If all has gone well we should get a successful test.

Finished in 1.345276s, 0.7433 runs/s, 1.4867 assertions/s.

1 runs, 2 assertions, 0 failures, 0 errors, 0 skips
I, \[2022-12-14T13:13:53.508516 #154338\]  INFO -- : tests done
I, \[2022-12-14T13:13:53.508583 #154338\]  INFO -- : run.rb exiting true

This should get you started with writing a test for your application! I’ll gladly help and review your forthcoming tests. For more detailed documentation check out the writing-tests wiki page as well as the appium command reference.

Of course the work is not done. selenium-webdriver-at-spi is very much still a work in progress and I’d be glad for others to help add features as they become needed. The gitlab project is the place for that. <3

The complete code of the example above:

#!/usr/bin/env ruby
# frozen\_string\_literal: true

# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2022 Harald Sitter <sitter@kde.org>

require 'appium\_lib'
require 'minitest/autorun'

class TestKInfoCenter < Minitest::Test
  attr\_reader :driver

  def setup
    @appium\_driver = Appium::Driver.new(
      {
        'caps' => { app: 'org.kde.kinfocenter.desktop' },
        'appium\_lib' => {
          server\_url: 'http://127.0.0.1:4723',
          wait\_timeout: 10,
          wait\_interval: 0.5
        }
      }, true
    )
    @driver = @appium\_driver.start\_driver
  end

  def teardown
    driver.quit
  end

  def test\_search
    search = driver.find\_element(:name, 'Search')
    search.click
    search.send\_keys('cpu')

    cpu = driver.find\_element(:class\_name, '\[list item | CPU\]')
    assert(cpu.displayed?)
    cpu.click

    cpu\_tab = driver.find\_element(:class\_name, '\[page tab | CPU\]')
    assert(cpu\_tab.displayed?)
  end
end

It’s a Plasma widget that visualizes what’s going on on your system, music-wise that is. I’ve started this project years ago but only recently found the motivation to get it to a somewhat acceptable state. It’s pretty amazing to have bars flying across the screen to Daft Punk’s `Touch`.

https://store.kde.org/p/1953779

Qt 6 introduced a new way to access platform specific objects and functionality in the QNativeInterface namespace. Starting with Qt 6.5 it will be possible to obtain handles to wayland object handles this way. Let’s look at what’s new and how it improves on the past method.

In Qt 5 there were to two options to access platform-specific API and native handles of the current platform. If you were lucky, your platform had an ‘Extras’ module like Qt Max Extras, Qt X11 Extras or Qt Android Extras. However these were removed for Qt 6 and if you ever needed something that was not exposed this way or the platform had no ‘Extras’ module (like Wayland), it was also possible to access functionality via QPlatformNativeInterface. An example usage of would look like this:

QPlatformNativeInterface *nativeInterface = QGuiApplication::platformNativeInterface();
if (!nativeInterface) {
    return;
}
auto seat = static_cast<wl_seat*>(nativeInterface->nativeResourceForIntegration("wl_seat"));
auto surface = static_cast<wl_surface*>(nativeInterface->nativeResourceForWindow("surface", window));
if (!seat || !surface) {
    return;
}
// do something with seat and surface

The snippet shows multiple problems of this API. One is that it is not type safe, the nativeResourceFor... functions return void*. I could easily have forgotten to change the type in the second cast with further implications down the line. The second problem is that it is not obvious at all what is available, no header file will tell you. One has to either already know or read the implementation. Additionally any typo in the string will break the functionality.

Qt 6 solves this with the interfaces in the QNativeInterface namespace. They provide type safe access to the platform specific parts. Using the new interfaces for Wayland in Qt 6.5 we can rewrite the above:

auto waylandApp = qGuiApp->nativeInterface<QNativeInterface::QWaylandApplication>();
auto waylandWindow = window->nativeInterface<QNativeInterface::Private::QWaylandWindow>();
if (!waylandApp || !waylandWindow) {
    return;
}
auto seat = waylandApp->seat();
auto surface = waylandWindow->surface();
if (!seat || !surface) {
    return;
}
// do something with seat and surface

Much nicer. The nativeInterface functions check that the interface is available on the object and from there on usage is straightforward. It’s obvious what’s available by looking at the header or the documentation. For example through QWaylandApplication it’s possible to access the wayland objects that Qt is using internally as well as the input serial of the last user action which is sometimes required to pass in other wayland protocols.

The astute reader might have noticed that in the snippet QWaylandWindow is in the nested QNativeInterface::Private namespace for now. The interface chosen here is being evaluated and a bit experimental (due to the need of signalling surface creation and destruction, it’s the first native interface inheriting from QObject!) and as I wanted to get this into Qt 6.5 I followed the precedent of QWindow native interfaces of the other platforms also being private for now. QWaylandOutput also resides next to its cousins in QNativeInterface::Private. Still I hope they don’t need to stay too long there and can be made public soon.

As you may know KDE consists of many different subprojects, where some projects depend on other projects. Most KDE projects depend on some KDE Frameworks, but other dependencies are also possible, e.g. plasma-desktop depends on plasma-workspace. To be able to automate building projects (for the CI system or tools like kdesrc-build) you need a machine-readable source of dependency information.

For a long time this information has been available in a set of files in repo-metadata. To declare for example plasma-desktop’s dependency on plasma-workspace one would write the line

kde/workspace/plasma-desktop: kde/workspace/plasma-workspace

to the relevant file.

Since most projects depend on a lot of KDE Frameworks, and specifying each of the frameworks manually is somewhat cumbersome, a virtual frameworks/kf5umbrella project that depends on all frameworks was introduced. By default all projects depend on this helper project. This metadata was used both by the Jenkins-based build.kde.org CI and kdesrc-build.

The approach worked well enough, but had some drawbacks. First of all most projects don’t actually depend on all frameworks, so kdesrc-build would build projects that you don’t actually need, which is wasteful. Second, the format had no way for platform-specific adjustments, like defining that X depends on Y on Linux but not Windows. This was especially problematic for our Android builds, where it would try to build projects that don’t actually support Android or weren’t needed but increasing the size of the final APK. This problem was solved by moving our Android builds to use Craft, which maintains its own dependency metadata.

Because of these shortcomings when we replaced our Jenkins-based CI with Gitlab CI sysadmins came up with a new way of defining dependencies for each project. Instead of a single, global file with all information each project now has a .kde-ci.yml file in its repository that defines the dependencies. There is no equivalent of the kf5umbrella any more, which forces projects to explicitly list all of their frameworks dependencies. The new format also allows to define platform-specific dependency information. For example Neochat’s .kde-ci.yml looks like this:

Dependencies:
- 'on': ['@all']
  'require':
    'frameworks/extra-cmake-modules': '@stable'
    'frameworks/kcoreaddons': '@stable'
    'frameworks/kirigami': '@stable'
    'frameworks/ki18n': '@stable'
    'frameworks/kconfig': '@stable'
    'frameworks/syntax-highlighting': '@stable'
    'frameworks/kitemmodels': '@stable'
    'frameworks/knotifications': '@stable'
    'libraries/kquickimageeditor': '@stable'
    'frameworks/sonnet': '@stable'
    'libraries/kirigami-addons': '@latest'
    'third-party/libquotient': '@latest'
    'third-party/qtkeychain': '@latest'
    'third-party/cmark': '@latest'

- 'on': ['Windows', 'Linux', 'FreeBSD']
  'require':
    'frameworks/qqc2-desktop-style': '@stable'
    'frameworks/kio': '@stable'
    'frameworks/kwindowsystem': '@stable'
    'frameworks/kconfigwidgets': '@stable'

- 'on': ['Linux', 'FreeBSD']
  'require':
    'frameworks/kdbusaddons': '@stable'

However, kdesrc-build still uses the old dependency infomation. As it is natural for two instances of the same information, they eventually got out of sync and the metadata used by kdesrc-build got more and more incorrect. Something had to be done. Due to its architecture it isn’t really feasible for kdesrc-build to directly read the .kde-ci.yml files since that would require cloning the repos to read the data. Instead we opted to generate the old-style dependency data from the .kde-ci.yml files. In an attempt to learn Rust I wrote a tool that does this and committed the initial result. In the spirit of the recently announced Automation Goal this ought to be automated fully, but that’s for another day.

Any missing information in the generated data should be fixed by adding it to the relevant .kde-ci.yml file. If you find any other issues with the generated data please let me know.

To support more KDE-wide building-block initiatives like this KDE is hiring a Software Platform Engineer. Hiring people is enabled through your donations to KDE. Check out our End of Year Fundraiser that will enable more of this work to happen.

Happy kdesrc-building!

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

On May 5th night, we had a hangout call with our project mentors and other GSoC students of WikiToLearn team.
This is the first hangout call we had with respect to GSoC.

We discussed the following things :

* Having a blog account and keep updating the progress in it. Also to find a way to mirror our blog and WikiToLearn wiki page to keep track of everything.

* Gianluca explained about the need of KDE account, Phabricator.

* All our current source code are hosted on Github, we may move to KDE QuickGit someday soon.

* We discussed our project proposals. We felt it will be a good idea if we inform about our project ideas to upstream contributors, MediaWiki contributors so that they could help us if we have any problem with respect to MediaWiki extension development.

* Make use of WikiToLearn tech channel effectively for every technical problem because we have experienced people there who could help us to solve it.

Things which I have done till now :

* Created an account on KDE identity.

* Got KDE developer access.

* Aggregated my Blog with KDE planet.

* Have an account on Phabricator.

* Have an account on KDE Bugtracking System. (WikiToLearn team doesn’t use it much.)

* Updated my user page on WikiToLearn.

* Created a doc which shows a list of days and hours I’ll be working/taking off.

* Running MediaWiki instance locally in my system.

* Installed and enabled VisualEditor. (Playing with it)

* Spending some amount of time in configuring Parsoid server. (I need to link VisualEditor and Parsoid server so that they talk each other and enables me to create and save wiki pages.)

Things I’ll work on next :

* Configure Parsoid server.

* Design workflow scheme for collaborative editor extension.

* Try out some simple VE extensions.