Skip to content

Sunday, 7 November 2021

Polkit explained What is PolKit PolKit is a standard authorization method for Linux. It usually consists of PolKit daemon, PolKit session agent and the helper program shipped by applications that use PolKit. As a user, you don’t really interact with PolKit itself, usually you interact with PolKit session agent. Like KDE’s PolKit agent: You can consider it as sudo of the GUI. But it works completely different than sudo. I spent two days trying to figure out what PolKit is, how it works, and how to use it to write a GUI tool that requires root privileges but can’t be run as root itself.

Saturday, 6 November 2021

That’s right! Kalendar is now on version 0.1, and we have a first release. There’s still a lot we have left to work on before we get to 1.0, but we are getting there! More on this below. We also have a truly titanic changelog for the past two weeks. Some truly big changes and … Continue reading "Kalendar is out! — Kalendar devlog 21"

Friday, 5 November 2021

Let’s go for my web review for the week 2021-44.

Preindustrial workers worked fewer hours than today’s

Tags: history, work, economics

Definitely contradicts our preconceived ideas regarding labor before the industrial revolution.

Research: People prefer friendliness, trustworthiness in teammates over skill competency | Binghamton News

Tags: management, team

Interesting findings about team dynamics. It’s actually a good thing that we seem to usually prefer people exhibiting skills + friendly and trustworthy, but that if we can get only one of the two we favor friendly and trustworthy over skills. It’s healthy, just skills tend to drag teams down.

The metaverse is bullshit

Tags: tech, cyberpunk, metaverse, gafam, capitalism

Definitely this. We got a bunch of rich people with a very shallow understanding of cyberpunk literature. They’re focusing on the gimmicks, missing completely the big picture… all of this to not face they’d be the villains in those stories.

Complexity is killing software developers | InfoWorld

Tags: tech, complexity

The paper is very “cloud focused” but most of the arguments make sense overall. Managing complexity is really the core issue of what we do as engineers… or at least it should be.

‘Trojan Source’ Bug Threatens the Security of All Code – Krebs on Security

Tags: tech, security, compiler, supply-chain

Now this one is really nasty…

Curves and Surfaces – Bartosz Ciechanowski

Tags: geometry, mathematics, 3d, 2d

Very very nice post. Explains from the basics how to build Bezier curves and patches but also Splines, B-splines, NURBS and Catmull-Clark subdivision surfaces. Talks about curvature, normals, etc. You name it.

Bye for now!

Thursday, 4 November 2021

kate showing a completion for qml

kate showing another completion for qml

qml-lsp is a simple LSP server for QML. it currently only offers primitive non-context-aware completions, without anything else. it understands:

  • completing component names
  • completing properties defined in surrounding component (not properties from its superclasses)
  • completing enums

note that it doesn't understand project-local QML components, only stuff installed to the system QML dirs with qmlplugindump set up correctly.

regardless, it does a decent job at completing system types, and considering that Qt Creator struggles with some of the plugins that qml-lsp has no problem with, it's pretty usable and an improvement over the nothing found in editors other than Qt Creator.

you can check out the source at, or fetch a statically linked binary here. plonk the binary in your PATH under the name qml-lsp.

kate LSP config:

	"qml": {
		"command": ["qml-lsp"],
		"highlightingModeRegex": "^QML$"

tags: #libre

Sunday, 31 October 2021

What I’m doing recently Formats & Language KCM So one thing I’ve been doing past four months is the porting of Formats KCM, but now the scope is no longer restricted in only porting. Alone the process, first the old KCM design isn’t that mobile friendly so I did a re-design. And then Nate pointed out that the Formats KCM is in conflicted with Language KCM, which leads to the merging of Language and Formats KCM.

Friday, 29 October 2021

Featured image of post KDE PIM in September and October

In the months since the KDE PIM July-August report there have been two patch releases for Kontact, and over 1400 changes made by more than 40 contributors have been integrated. Here are some of the highlights.


A lot has happened over the last two months in KOrganizer development. First of all, Friedrich has been working on reviving the calendar decoration feature. This feature was introduced in 2007, but has since suffered from a lack of maintenance and multiple regressions.

Decorations allow you to display additional information inside the week view. Here is what it looked like back in 2007 when it was introduced.

KOrganizer back in 2007

As part of this effort, the plugin that allowed KOrganizer to display the current “Picture of the day” from the English Wikipedia, was ported to Wikipedia’s new API, and now works again. (KDE Gear 21.12)

Picture of the day
Picture of the day

Friedrich is also working on a new plugin that shows the moon phase inside the week view. Pretty neat if you like astronomy. This feature should hopefully also land in KDE Gear 21.12.

Moon Phase
Moon Phase

The work on the Moon Phase plugin prompted Friedrich to add this feature to KOrganizer’s month view too. This feature is still under review but should hopefully land in KDE Gear 21.12 as well.

Month View Decoration
Month View Decoration

There are also ongoing discussions about making this plugin more generic, and, in the future, adding support for these calendar decorations to Kalendar and the Plasma Calendar applet.

Glen Ditchfield has also been busy fixing many issues inside KOrganizer.

The event editor no longer creates duplicate tags (Bug 441846), and the list used in the Event View and the Find dialog do not automatically re-sort themselves by starting date when the event editor alters an event (441530). The user’s sorting preferences for these lists are preserved, just like other preferences.

The Find dialog also got better labels and tooltips. When an event displayed in it gets modified, this gets immediately updated in the UI.

Glen also made several improvements to the Month View. In general, the layout is now more compact (Bug 435667). Multiple-day holidays are now correctly displayed as one multiple-day event instead of several single-day events. A more visible change is that the current day is now highlighted with your system theme’s highlight color instead of grey (420515).

Month view

Lastly, the sidebar item viewer displays the completion date and time of completed to-dos, rather than just the date (Bug 374774).

Volker Krause removed the procedure and email alarms that allowed events to execute commands and send emails due to the security risk they pose in combination with shared calendars.

In term of documentation, David Bryant started cleaning up KOrganizer’s docs, like he previously did with KMail.


Glen also updated the Canadian holidays inside KHolidays, and Ghalib Ahmed added holiday information for Pakistan.


Laurent Montel improved the emoji support in KMail. It is now easier to find emojis thanks to a new emoji search feature, as well as a new recently-used emojis tab.

Emoji search
Emoji search

Search is generally easier since multiple search fields now perform a case-insensitive search.

In the email editor, warnings about too many recipients are now indicated by an inline message (instead of a popup dialog), conforming to KDE’s HIG.


Additionally, a few bugs related to the formatting in the email editor were fixed by Laurent Montel (Bug 419978, 442416 and 443108).

Volker Krause made sure that KMail connects to an SMTP servers with TLS enabled even when no login is required (bug 423423). He also fixed an infinite SSL warning dialog loop that appeared when a connection to an IMAP server was rejected with an invalid certificate (bug 423424).

Sandro Knauß also helped solve the above security vulnerabilities and started working on supporting the Autocrypt-Draft-State header. This header is needed when you want to store a draft and need to indicate whether it should be sent as an encrypted mail or not.

Ingo added filtering by paths to folder selection. This is useful when you need to copy or move a message to a folder, or when you need to jump to a folderas you just type, say, “foo/bar” and you will narrow down the list of folders to those containing the string “bar” that are subfolders of folders. This change was funded by Intevation GmbH. (Bug 443791).

Filtering by paths

Finally, David Bryant is working on updating the credits sections in both the KMail documentation and the About dialog, since most of the people who started contributing to KMail after 2010 aren’t yet mentioned in the credits.


Kleopatra is KDE’s certificate manager and makes it possible to manage X.509 and OpenPGP certificats and smartcards. In the last two months, Ingo Klöcker worked on improving the accessibility of the decryption and encryption of files. He also created an AppImage for Kleopatra.


David Jarvie fixed a few issues KAlarm was having when handling application themes. The time edit spinbox now works correctly when using the Breeze theme (bug 443062) and, similarly, the sub-daily recurrence editor should now be usable with the Fusion theme.

He also worked on using the translated forms of AM/PM when displaying times This will make it more appropriate for certain locales.


Kalendar is also making tons of progress. Clau aded a new week view and enabled filtering by tags, Carl (me) worked on a QtQuick version of KCommandBar, Devin Lin ported the mobile version to Kirigami.NavigationTabBar and Felipe Kinoshita made the sidebar collapsible. This is just the tip of the iceberg, you can find a more comprehensive list of all the changes in Clau Cambra’s blog.

Kalendar also passed the KDE Review process and you can expect a first release soon!

KDE Itinerary

KDE Itinerary, the ultimate companion app for all your trips, also received many new features. Itinerary now provides navigation guides for walking and for transfer sections of public transport elements, a new barcode scan mode, and rental vehicle information.

KDE itinerary transfer navigation instructions

You can find more information about all of Itinerary’s changes in Volker Krause’s latest blog post.

Deprecation work

A large focus remains on preparing for the upcoming migration to Qt6 and KF6. This mainly consists of porting away from deprecated functionality in Qt and KDE Frameworks, as well as moving to more modern build systems or C++ constructs. While this does not have any visible impact yet, this will allow for a smoother transition down the line. This work was largely done by Laurent Montel, Alexander Lohnau, Friedrich W. H. Kossebau, Nicolas Fella and a few others.

Help us make Kontact even better!

Check out some of our open junior jobs! They are simple, mostly programming-focused tasks, but they don’t require any deep knowledge or understanding of Kontact, so anyone can work on them. Feel free to pick any task from the list, then get in touch with us! We’ll be happy to guide you and answer all your questions. Read more here…

Thanks to Claudio Cambra and Paul Brown for the proofreading.

Let’s go for my web review for the week 2021-43.

Reflections as the Internet Archive turns 25 - Internet Archive Blogs

Tags: tech, internet, commons

Another very important common turns 25 this year. Happy birthday Internet Archive!

Privacy is a Human Right | Tor Blog

Tags: tech, tor, fundraising

Fundraising from the Tor project, especially nice message this year.

Google sought fellow tech giants’ help in stalling kids’ privacy protections, states allege

Tags: google, facebook, gafam, surveillance

Basically an attempt at building a cartel of the surveillance capitalism companies to slow down privacy regulations… how surprising, not.

Can we trust Microsoft with Open Source? - Dusted Codes

Tags: microsoft, free-software

Unlike what the usual PR claims, Microsoft keeps being Microsoft… lots of infighting and tensions.

Despite having just 5.8% sales, over 38% of bug reports come from the Linux community

Tags: tech, linux, quality

This is in the context of a game, but from my experience in other domains… this is definitely why you want Linux users when you make a product. Might not generate a lots of sales but the signal/noise ratio in the bug reports is just great.

RSS is Wonderful ·

Tags: tech, rss, web, social-media

Since I’m still hoping for a strong RSS revival (not that it disappeared but I wish it was more the default option again), this post especially resonated with me. The discovery tool sounds very interesting.

RFC 3339 vs ISO 8601

Tags: tech, date, rfc3339, iso8601

Dates are important, they can also be complicated. When unsure about how a format works this page can help.

CookLang: recipe markup language

Tags: tech, cooking

Funny interesting tiny markup language targeting cooking. Funnily enough I could see myself using this.

When you’re a manager, your behavior is under a microscope - Jacob Kaplan-Moss

Tags: management, leadership

Like it or not but the “manager” label indeed changes interpersonal dynamics.

Jobs that Marry Together the Most | FlowingData

Tags: statistics, data-science

Interesting exploration of statistics around marriage (in the US). Some jobs are definitely more staying in their own circles than others.

Bye for now!

Wednesday, 27 October 2021

Today we want to introduce the last of the new features we are implementing into the 2.9 release which we have recently finalized.

To demo this new feature, let’s use an example contributed by one of our users. This example is based upon the measurement data from a solar cell. The so-called “incident photon-to-current conversion efficiency” (IPCE) tells us how many incoming photons are converted into free electrons in the cell. This conversion efficiency, together with the generated current and their dependency on the wavelength of the incoming light, are the usual subjects of studies and optimizations for solar cells.

Consider the example where we want to plot the IPCE and the current density in the same plot and to see their behavior as a function of the wavelength. Your first idea may be to just lay out the curves for the plot like this:

Two curves, single range

But this reveals two problems:

  • The two quantities have different ranges (IPCE goes from 0% to ca. 80%, while the current density goes from 0 mA/cm^2 to ca. 12 mA/cm^2). This problem can become even more severe if the data ranges differ by many orders of magnitude.
  • The two quantities don’t share the same units. That makes it impossible to put a meaningful description on the y-axis.

We can remedy the situation a bit by using a plot legend which helps discriminate the different curves. Unfortunately the result is still far from being optimal, and this way of plotting different quantities having different units is commonly considered wrong.

A better solution for this kind of visualization is to work with two different data regions and axes. This is something that was not possible in LabPlot before now and it is a feature for which we had multiple requests in the past. This has led us to  recently implement this missing functionality, and the plot below shows what it looks like:

Two curves, two ranges

Note how, by working with two different axis scales and colors, you can produce a much clearer and more coherent visualization. Such a result is easily achieved in LabPlot now, and it all starts with the definition of the two data ranges for the x and y directions:

Range definition

The red-highlighted area in the image above is the new feature. The ranges for x and for y are combined into “Plot Ranges” and the objects on the plot like axes and curves are “assigned” to the different plot ranges. Once the definition of the plot ranges is done, the desired visualization for the two curves in the plot above is achieved with one single step by selecting the proper data range for every curve:

Curve range assignments

We arrive at the final result by assigning the second y-axis to the second data range and by adjusting the color properties of the second axis.

The user has a lot of flexibility in LabPlot to position the axes. Another possible visualization utilizing the two-axes technique is shown below:

Two curves, two ranges

A detailed walk-through for this example is maybe an idea for a future tutorial.

Suffice to say that, as mentioned, the development of new features for 2.9 is finalized, and we are now concentrating on the stabilization and quality control work to prepare everything for the release. People interested in contributing to these activities are invited to test our nightly builds and to provide us with feedback.

Stay tuned for more news regarding version 2.9!

Today (Wednesday 27th Oct) at 18:00 CEST I will be streaming some Kalendar development live on YouTube and on KDE’s Peertube instance. KDE Peertube (Kockatoo): My YouTube channel: If you are curious about contributing to Kalendar, have questions for me, or just want to hang out, come say hi! 😁

Monday, 23 March 2020

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.

Where else to find this article & updates

A copy of this blog is available also on Liferay Blog.
Haksung Jang (장학성) was awesome enough to publish a Korean translation.

2021-03-09 update: better wording; more info on how to handle anonymous authors and when copyright is held by employer, © and ASCII, multiple authors; DCO; easier REUSE instructions

2022-10-23 update: more FAQ entries

2023-03-28 update: a few more FAQ entries following feedback at FOSDEM and from Mastodon


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) 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 <>

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 holder1 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 license2 –, or make use of a statutory limitation or exception3. 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 3rd party works, such as copied code or libraries.

Inbound vs. outbound licenses

The license you give to your downstream is called an outbound license, because it handles the rights in the code that flow out of you. In turn that same license in the same work would then be perceived by your downstream as their inbound license, as it handles the rights in the code that flows into them.

In short, licenses describing rights flowing in are called inbound licenses, and the licenses describing rights flowing out are called outbound licenses.

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 statement4.

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.

Copyright statements are useful

The copyright statement is not required by law, but in practice very useful as proof, at best, and indicator, more likely, of what the copyright situation of that work is. This can be very useful for compliance reasons, traceability of the code etc.

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 <>

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 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 specifications:

SPDX-FileCopyrightText: © 2020 Matija Šuklje <>

SPDX-License-Identifier: BSD-3-Clause

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


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.

Innocent infringement excursion for legal geeks

17 U.S. Code § 401.(d) states that if a work carries a copyright notice in the form that the law prescribes, in a copyright infringement case the defendant cannot rely on the innocent infringement defense, except if they had reason to believe their use was covered fair use. And even then, the innocent infringer would have to be e.g. a non-profit broadcaster or archive to be still eligible to such defence.

So, if you are concerned with copyright violations (at least in USA), you may actually want to make sure your copyright statements include both the copyright sign and year of publication.

See also note in Why the © sign for how a copyright notice following the US copyright act looks like.

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 1st 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 thumb5 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) years6 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.

Worst case thought experiment

Let us imagine the worst possible scenario now:

1) you never bump the year in a copyright statement in a file and 2) 50+ years after its initial release, someone copies your code as if it were in public domain. Now, if you would have issue with that and go to court, and 3) the court would (very unlikely) take only the copyright statements in that file into account as the only proof and based on that 4) rule that the code in that file would have fallen under public domain and therefore the FOSS license would not apply to it any more.

The end result would simply be that (in one jurisdiction) that file would fall into public domain and be up for grabs by anyone for anything, no copyright, no copyleft, 50+ years from the file’s creation (instead of e.g. 5, maybe 20 years later).

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.

Keep the Git/VCS history clean

Also, bumping the year in all the files every year messes with the usefulness of the Git/VCS history, and makes the log unnecessarily long(er) and the repository consumes more space.

It makes all the files seem equally old (in years), which makes it hard to identify stale code if you are looking for it.

Another issue might be that your year-bumping script can be too trigger-happy and bump the years also in the files that do not even belong to you. Furthering misinformation both in your VCS and the files’ copyright notices.

Do not bump the year during build time

Bumping the year manually is bad, but automating year bumping during build time is taking it to another level!

One could argue – and I suspect this is where it originates from – that since compiling is translation and as such an exclusive right of the copyright holder. But while translation from one programming language to another clearly can take a lot of mental effort and might require different ways how to express something, a machine-compilation from human-readable source code to machine-readable object/binary code per se is extremely unlikely to have added a new copyrightable component into the mix. That would be like saying an old song would gain new copyright just because it was released in a new audio format without any other changes.

Bumping the year during build time also messes up reproducible builds.

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 issues7, 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 assumption8 – 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.

Token-based blame information

For a more fine-grained tool to see who to blame for which piece of code, check out cregit.

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. 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 world9.

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

Comparison between US and Slovenian copyright statements

As an EU example, the Slovenian ZASP §175.(1) simply states that holders of exclusive author’s rights may mark their works with a (c)/© sign in front of their name or firm and year of first publication, which can be simply put as:

© {$year_of_first_publication} {$name_of_author_or_other_copyright_holder}

On the other side of the pond, in the USA, 17 U.S. Code § 401.(b) uses more words to give a more varied approach, and relevant for this question in §401(b)(1) prescribes the use of

the symbol © (the letter C in a circle), or the word “Copyright”, or the abbreviation “Copr.”;

The rest you can go read yourself, but can be summarised as:

(©|Copyright|Copr.) {$year_of_first_publication} {$name_or_abreviation_of_copyright_holder}

See also the note in Why keep the year for why this can matter in front of USA courts.

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.

© sign and ASCII

While Unicode (UTF-8, UTF-16, …) is pretty much ubiquitous nowadays, there are places and reasons for when the encoding of source code will have to be limited to a much simpler one, such as ASCII. This could be e.g. in case when the code is written to be put into small embedded devices where every bit counts.

The © character was introduced in 8-bit extended ASCII, but the original 7-bit ASCII does not have it.

So if this is the situation you are in, it is fine to either ommit the copyright sign or replace it with e.g. (C) or Copyright.

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-mail10, 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.

Avoiding orphan works

For the legal geeks out there, a contact to the copyright holder mitigates the issue of orphan works.

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.

How to handle multitudes of authors?

Here are two examples of what you can write in case the project (e.g. Project X) has many authors and does not have a CAA or exclusive CLA in place to aggregate the copyright in a single entity:

© 2010 The Project X Authors <https://projectx.example/about/authors>

© 1998 Contributors to the Project X <https://git.projectx.example/ProjectX/blob/master/CONTRIBUTORS.markdown>

An an example of when the project is handled by a non-profit NGO legal entity.

© 2020 BestProjectNGO <https://bestprojectngo.example>

Bot to automate contributions

A really interesting project is All Contributors, which specifies how to manage contributions to all – even non-code – contributions to a project. It also includes a CLI tool and offers a GitHub bot to automate this process.

The major downside is that the prescribed format is an HTML table embedded in MarkDown. So not very easy to read or parse in source form.

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 <>
SPDX-FileCopyrightText: © 2021 Master Hacker <>

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 expired11.

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.

Transformations of code

Translations between different languages, compilations and other transformations are all exclusive rights of the copyright owner. So you need a valid license even for compiling and minifying.

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.

Practical example

Imagine12 a FOSS project that has a copy of the MIT license stored in its LICENSE file and (only) the following comment at the top of all its source code files:

# This file is Copyright (C) 1997 Master Hacker, all rights reserved.

Now imagine that someone simply copies one file from that repository/archive into their own work, which is under the AGPL-3.0-only license, and this is also what it says in the LICENSE file in the root of its own repository. And you, in turn, are using this second person’s codebase.

According to the information you have at hand:

  • the copyright in the copied file is held by Master Hacker;
  • apparently, Mr Hacker reserves all the rights they have under copyright law;
  • if you felt like taking a risk, you could assume that the copied file is under the AGPL-3.0-or-later license – which is false, and could lead to copyright violation13;
  • if you wanted to play it safe, you could assume that you have no valid license to this file, so you decide to remove it and work around it – again false and much more work, but safe;
  • you could wait until 2067 and hope this actually falls under public domain by then – but who has time for that.

This example highlights both how problematic the wording of “all rights reserved” can be even if there is a license text somewhere in the codebase.

This can be avoided by using a sane copyright statement (as described in this blog post) and including an unambiguous license ID. ties both of these together in an easy to follow specification.

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 pseudonym14 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.

Anonymity and Git

If you are concerned about anonymity, do take into consideration also that Git stores both author and committer data for each commit. Look into how to keep those records in a way that they cannot be linked to you.

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.

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 <>
# SPDX-License-Identifier: BSD-3-Clause

import sense

# 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

  1. This is presumed to be the author at least initially. But depending on circumstances can be also some other person, a legal entity, a group of people etc. See also this FAQ entry for more info. 

  2. A license is by definition “[t]he permission granted by competent authority to exercise a certain privilege that, without such authorization, would constitute an illegal act, a trespass or a tort.” 

  3. Limitations and exceptions (or fair use/dealings in USA/Canada/UK) in copyright are extremely limited when it comes to software compared to more traditional media. Do not rely on them. 

  4. In USA, the copyright statement is often called a copyright notice. The two terms are used intercheangably. 

  5. E.g. the 5 SLOC rule of thumb means that any contribution that is 5 lines or shorter, is (likely) too short to be deemed copyrightable, and therefore can be treated as un-copyrightable or as in public domain; and on the flip-side anything longer than 5 lines of code needs to be treated as copyrightable. This rule can pop up when a project has a relatively strict contribution agreement (a CLA or even CAA), but wants some leeway to accept short fix patches from drive-by contributors. The obvious problem with this is that on one hand someone can be very original even in 5 lines (think haiku), while one can also have pages and pages of absolute fluff or just plain raw factual numbers. 

  6. This depends from jurisdiction to jurisdiction. The Berne convention stipulates at least 50 years after death of the author as the baseline. There are very few non-signatory states that have shorter terms, but the majority of countries have life + 70 years. The current longest copyright term is life + 100 years, in Mexico. 

  7. The only improvement is that it avoids messing up the Git/VCS history. 

  8. In practice what the Author field in a Git repository actually includes varies quite a bit and depends on how the committer set up and used Git. 

  9. Of course, I did not go through all of the copyright laws out there, but I checked a handful of them in different languages I understand, and this is the pattern I identified. If anyone has a more thorough analysis at hand, please reach out and I will happily include it. 

  10. Just think about it, pretty much every time you create a new account somewhere online, you are asked for your e-mail address, and in general people rarely change their e-mail address. 

  11. As stated before, in most jurisdictions that is 70 years after the death of the author. 

  12. I suspect many of the readers not only can imagine one, but have seen many such projects before ;)

  13. Granted, MIT code embedded into AGPL-3.0-or-later code is less risky than vice versa. But simply imagine what it would be the other way around … or with an even odder combination of licenses. 

  14. A(n identifiable) pseudonym, under copyright law, has basically the same power as a legal name. Think of all the musicians, actors and writers that we know under their pseudonym or stage name.