LibreELEC.tv
LibreELEC.tv copied to clipboard
LibreELEC
remove useless term 'present' from copyright headers
We started using the term "present" to represent a copyright timespan. This was the wrong decision and we should correct that now.
The term "present" really has no meaning in terms of copyright as it is open to interpretation.
The copyright year is good enough (and no we don't have to bump it every year).
ref:
- https://liferay.dev/blogs/-/blogs/how-and-why-to-properly-write-copyright-statements-in-your-code
- https://github.com/xbmc/xbmc/pull/13927#issuecomment-391542268
- https://github.com/xbmc/xbmc/pull/14206
- https://opensource.stackexchange.com/a/4890
As https://liferay.dev/blogs/-/blogs/how-and-why-to-properly-write-copyright-statements-in-your-code stated the real fix would be a timespan (present = current year) and a year is also just a hacky approach because he had no proper solution either. I don't see it as improvement to switch from one hacky approach to another.
And now the fun begins
- the "perfect fine solution", a timespan, has major downsides because we would need to touch every file every year, that's stupid because it messes the cvs
- touch the year if a copyright worthy change was made, that would be even more stupid and unmanageable (who decides ... )
- we could add a description how the year-present thing should work, that's also just a mediocre workaround
I saw that ppl/companies switch to year-less headers and dismiss the hacky workarounds we all use. In that case you need to look at the cvs to know when things changed. From my perspective that is a good solution. But I have no idea (didn't read anything about it) if this is also a good solution from lawyer POV. To workaround the issue that you loose the cvs information if you just download the source we could add a paragraph at our licence file to make clear that all LE related stuff is copyrighted till this year (2022). That would need just to change a single file every year to be up to date and we have a clear year stated.
Btw if we need to touch every file in the repo we could also switch to the new SPDX format of GPL2.0 GPL-2.0 -> GPL-2.0-only.
@lrusak just to clarify, you are proposing that we remove the string -present from all SPDX headers but leave the year and all other content as-is?
Edit: I was being blind, I reviewed this as a ticket and not a PR. Ignore this question.
As https://liferay.dev/blogs/-/blogs/how-and-why-to-properly-write-copyright-statements-in-your-code stated the real fix would be a timespan (present = current year) and a year is also just a hacky approach because he had no proper solution either. I don't see it as improvement to switch from one hacky approach to another.
What?
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 it anymore;
- the name of the copyright holder – typically the author, but can also be your employer or the if there is a CLA in place another legal entity or person;
- a valid contact to the copyright owner
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.
Stats for nerds:
$ git grep -l -E 'SPDX-License-Identifier' | sort | uniq | xargs grep -E -l '[0-9]{4}-present' | sort | uniq | wc -l
1111
$ git grep -l -E 'SPDX-License-Identifier' | sort | uniq | xargs grep -E -L '[0-9]{4}-present' | sort | uniq | wc -l
160
$ git grep -E '[0-9]{4}-present' | grep -v 'Team LibreELEC'
packages/addons/addon-depends/jre-depends/apache-ant/package.mk:# Copyright (C) 2019-present Peter Vicman ([email protected])
packages/addons/addon-depends/jre-depends/jdk-aarch64-zulu/package.mk:# Copyright (C) 2019-present Peter Vicman ([email protected])
packages/addons/addon-depends/jre-depends/jdk-arm-zulu/package.mk:# Copyright (C) 2019-present Peter Vicman ([email protected])
packages/addons/addon-depends/jre-depends/jdk-x86_64-zulu/package.mk:# Copyright (C) 2019-present Peter Vicman ([email protected])
packages/addons/tools/jre.zulu/package.mk:# Copyright (C) 2019-present Peter Vicman ([email protected])
packages/graphics/vulkan/glslang/package.mk:# Copyright (C) 2021-present Frank Hartung (supervisedthinking (@) gmail.com)
packages/graphics/vulkan/spirv-headers/package.mk:# Copyright (C) 2021-present Frank Hartung (supervisedthinking (@) gmail.com)
packages/graphics/vulkan/spirv-tools/package.mk:# Copyright (C) 2021-present Frank Hartung (supervisedthinking (@) gmail.com)
packages/graphics/vulkan/vulkan-headers/package.mk:# Copyright (C) 2018-present Frank Hartung (supervisedthinking (@) gmail.com)
packages/graphics/vulkan/vulkan-loader/package.mk:# Copyright (C) 2018-present Frank Hartung (supervisedthinking (@) gmail.com)
packages/graphics/vulkan/vulkan-tools/package.mk:# Copyright (C) 2018-present Frank Hartung (supervisedthinking (@) gmail.com)
packages/sysutils/busybox/scripts/libreelec-target-generator:# Copyright (C) 2020-present Matthias Reichl <[email protected]>
$ git grep -l -E '[0-9]{4}-present' | xargs basename -a | sort | uniq -c | sort -bg
1 00-addons.conf
1 04-sway.conf
1 04-weston.conf
1 30-disable-wakeup.rules
1 90-alsa-restore.rules
1 90-systemd.conf
1 99-mysql-histfile.profile
1 addon.py
1 adjust_kernel_config
1 amlogic-0001-WIP-add-confs-for-gx-sound-card-and-axg-sound-card.patch
1 apt-get
1 autoreconf
1 autoremove
1 backup-restore
1 brcmfmac-firmware-setup
1 build
1 build_mt
1 calibrate.py
1 ccache_stats
1 checkdeps
1 check_kernel_config
1 checkunpack
1 chrome-downloader
1 chrome-start
1 clean
1 compare_nvidia.py
1 config.txt
1 create_addon
1 create-edid-cpio
1 dashboard
1 dbusservice.py
1 distro-tool
1 docker
1 dthelper
1 dump-active-edids-drm
1 emby4.start
1 emmctool
1 environment-setup
1 ethmactool-config
1 extract
1 factory-reset
1 fixlecode.py
1 foot.sh
1 genbuildplan.py
1 get
1 get_archive
1 getedid
1 getedid-drm
1 get_file
1 get_git
1 image
1 inadyn-service
1 init
1 install_addon
1 installer
1 iptables_helper
1 jellyfin-downloader
1 jellyfin-start
1 kernel-overlays-setup
1 kodi-config
1 kodi-remote
1 kodi-safe-mode
1 kodi-userdirs.conf
1 lcdd.start
1 ledfix
1 libmali-setup
1 libreelec-target-generator
1 lock-screen.py
1 Makefile
1 makefile_helper
1 mariadb.start
1 mariadb.stop
1 minidlna.power
1 minidlna.start
1 minisatip.power
1 minisatip.start
1 mkpkg_bcm2835-driver
1 mkpkg_libcec
1 mkpkg_media_build
1 mkpkg_pvr
1 mkpkg_rtmpdump
1 mkpkg_vboxguest
1 mpd.power
1 mpd.start
1 mtstats.py
1 multithread
1 openssl-config
1 oscam.power
1 oscam.start
1 packages.mk.addon_template
1 packages.mk.template
1 pastebinit
1 pastekodi
1 path
1 pcscd.start
1 pkgbuilder.py
1 pkgcheck
1 pkginfo
1 pkgjson
1 prometheus-node-exporter.start
1 readme.md
1 refresh-patches
1 rpi-flash-firmware
1 rsyslog.init
1 service-addon-wrapper
1 service.py
1 smb.conf
1 smbd-config
1 snapclient.start
1 snapserver.start
1 snmpd.start
1 snmpd.stop
1 soundconfig
1 sway-config
1 sway-daemon.conf
1 sway.sh
1 syncthing-service
1 systemd-machine-id-setup
1 tigervnc.start
1 tinc.start
1 ts_calibrate.sh
1 ts_env.sh
1 ts_env.sh-sample
1 ts_env.sh-waveshare
1 ts_uinput_touch.sh
1 ttyd.start
1 tvheadend42.start
1 tvheadend43.start
1 uboot_helper
1 unpack
1 update_adafruit-libraries
1 update_binary-addons
1 update-bootloader-edid-rpi
1 update_common_functions
1 update_retroplayer-addons
1 update-scan
1 usercache-setup
1 userconfig-setup
1 vdr.start
1 viewconfig
1 viewplan
1 wait-time-sync.c
1 weston-config
1 wg-keygen
1 xorg-configure
1 z_03_wireguard.conf
2 actions.py
2 download.py
2 firmware
2 functions
2 install2emmc
2 tv_grab_file
2 tvheadend.power
3 distroconfig.txt
3 gputemp
4 canupdate.sh
4 cpufreq
7 mkimage
8 cputemp
8 install
8 release
8 update.sh
42 default.py
856 package.mk
my 2c. I don't think a global find and replace XXXX-present to XXXX is right. (I'm no lawyer - but as a contributor - what is being suggested is that my contribution in for example 2021 has no copyright - or that my copyright that was assigned to the team is being revoked.) If this change was to be considered - then it should cover off review the contributions and address if the change was a copyright worthy change. The article referenced was an interesting read but did not give a clear - do this and all will be ok. I like the idea of the simplification of the potentially dateless option and GPL-2.0-only - but still I'm not a lawyer. In looking at a number of other OSS projects (ones I assume that are well funded) the still have XXXX-YYYY e.g. 2016-2022. So is this something the LE can/should take the lead on? (not something I really want to invest my personal time in. I'm happy with the current lay-of-the-land, or a bulk yearly, or add the date as a comma when it is a worthy change, or potentially a dateless version - didn't do any research on this...)
I'd rather we did something constructive that advances the project (HDR on Generic perhaps) instead of fraying everyone's nerves with another "nobody is a lawyer, nobody is right" depressing debate on license headers. I'm going to abstain from this one .. life is too short.
Google's policy on the topic: https://opensource.google/documentation/reference/copyright
I'd rather we did something constructive that advances the project (HDR on Generic perhaps) instead of fraying everyone's nerves with another "nobody is a lawyer, nobody is right" depressing debate on license headers. I'm going to abstain from this one .. life is too short.
The problem comes when actual development is being actively blocked because of an opinion about the copyright header. My time is valuable and I would rather work on other features that continue advancing the project, however, others don't seem to see that.
my 2c. I don't think a global find and replace XXXX-present to XXXX is right. (I'm no lawyer - but as a contributor - what is being suggested is that my contribution in for example 2021 has no copyright - or that my copyright that was assigned to the team is being revoked.) If this change was to be considered - then it should cover off review the contributions and address if the change was a copyright worthy change. The article referenced was an interesting read but did not give a clear - do this and all will be ok. I like the idea of the simplification of the potentially dateless option and GPL-2.0-only - but still I'm not a lawyer. In looking at a number of other OSS projects (ones I assume that are well funded) the still have XXXX-YYYY e.g. 2016-2022. So is this something the LE can/should take the lead on? (not something I really want to invest my personal time in. I'm happy with the current lay-of-the-land, or a bulk yearly, or add the date as a comma when it is a worthy change, or potentially a dateless version - didn't do any research on this...)
This is a bit of a bad take.
What do you think a contribution is? Do you think somehow your contributions will be erased from git? The contributions are attributed to Team LibreELEC (a non legal, non organized, collection of people).
You likely gain copyright from this change being that the term present is ambiguous and could represent the "present" time that the changes were committed thus limiting copyright.
Really this PR is a fine option for now as the year of the original contribution is perfectly valid and well recognized.
I would also like to see new contributions be allowed to not use the term "present" and to not block them based on this.
The problem comes when actual development is being actively blocked because of an opinion about the copyright header. My time is valuable and I would rather work on other features that continue advancing the project, however, others don't seem to see that.
As I said before in https://github.com/LibreELEC/LibreELEC.tv/pull/6665#issuecomment-1184367545 you could just have used the package template which is/was the "in-house" style for new packages, your PR would have been merged most likely long ago and then the topic copyright header could have been discussed later.
So the only reason actual development is being actively blocked was your point of view wether it's useless or not to use the phrase present in the header.
IMHO I have no clue what's legally correct but at the same time I don't see any priority for such things 🤷🏻♂️
@chewitt since you've mentioned it, arent there any lawyers which might have a look at FOSS projects for free?
@lrusak
being actively blocked
I thought its obvious enough with my last comment on that topic, but for sure I can make it more precise. If you pr something that is not following the guidelines for the project you pr get rejected or changes are required. I know for sure you know those requirements, because even Kodi is actively doing it, obviously.
Me trying not to sound like captain obviously, but that's all common sense and I did not expect the need to write this down.
You may need to understand that we do not hoop through rings just because you proposed some profound change and justified the changes with comments from some internet randoms at some random prs and a blog entry from someone who tells us that your change is a workaround for doing it properly.
Currently, "everyone" does either timeframes (and more or less stupid workarounds for it)
- LE
- Kodi
- ffmpeg
- Linux Kernel
- A LOT more
or using or proposing timeless headers
- Microsoft (Github ...)
- facebook (migrating from xxx-present to yearless)
Even your linked blog entry says that this way is perfectly fine and the only con is
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
The value of the earliest date of a piece of code is very limited. If you want to use that then you need to add a year (lol) if a major rewrite happens - this is happening all the time over the years at LE. So we are back to using kinds of timeframes OR using the cvs to document the changes.
So, if "everyone" from the big players is not using "just a year" and even the mentioned blog shows better solutions, why should we still use it ?
We don't have the knowledge to make it waterproof, we are all no lawyers - so let's do it like the big players are doing it instead of using some unicorn approach. If the big companies are sure their ways are correct, why should we know better?
As I said before in #6665 (comment) you could just have used the package template which is/was the "in-house" style for new packages, your PR would have been merged most likely long ago and then the topic
copyright headercould have been discussed later.
meh, hardly a reason to not merge.
IMHO I have no clue what's legally correct but at the same time I don't see any priority for such things 🤷🏻♂️
I don't understand this comment. If you don't see any priority for this why comment?
@chewitt since you've mentioned it, arent there any lawyers which might have a look at FOSS projects for free?
We've already talked to lawyers (and even signed some papers). They hardly have time for large projects like Kodi and have even less time for small projects like ours 😊
@lrusak
being actively blocked
I thought its obvious enough with my last comment on that topic, but for sure I can make it more precise. If you pr something that is not following the guidelines for the project you pr get rejected or changes are required. I know for sure you know those requirements, because even Kodi is actively doing it, obviously.
Kodi allows self merging PR's so the requirements are pretty loose. That doesn't mean you can do whatever you want, but within reason is good enough.
Me trying not to sound like captain obviously, but that's all common sense and I did not expect the need to write this down.
You may need to understand that we do not hoop through rings just because you proposed some profound change and justified the changes with comments from some internet randoms at some random prs and a blog entry from someone who tells us that your change is a workaround for doing it properly.
Currently, "everyone" does either timeframes (and more or less stupid workarounds for it)
- LE
- Kodi
- ffmpeg
- Linux Kernel
- A LOT more
or using or proposing timeless headers
- Microsoft (Github ...)
- facebook (migrating from xxx-present to yearless)
Even your linked blog entry says that this way is perfectly fine and the only con is
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
I would be fine going dateless, however, that would seem like a rather large, intrusive change that would require signoff by anyone attributed to the team (I would think).
The value of the earliest date of a piece of code is very limited. If you want to use that then you need to add a year (lol) if a major rewrite happens - this is happening all the time over the years at LE. So we are back to using kinds of timeframes OR using the cvs to document the changes.
Ok? What's the point here? The changes are in version control anyways. I don't see a reason to continually update a year.
So, if "everyone" from the big players is not using "just a year" and even the mentioned blog shows better solutions, why should we still use it ?
We don't have the knowledge to make it waterproof, we are all no lawyers - so let's do it like the big players are doing it instead of using some unicorn approach. If the big companies are sure their ways are correct, why should we know better?
Ok, so that's progress. If you want to go yearless, then make the changes (like I've done in this proposal) and I'll approve them. At least that will be some progress.
or using or proposing timeless headers
Microsoft (Github ...) facebook (migrating from xxx-present to yearless)
Examples? My understanding is that would be an invalid copyright notice in the US. Per the US Copyright Office: https://www.copyright.gov/comp3/chap2200/ch2200-notice.pdf Sec. 2205.1(E)
In those cases where a year is required and no year of publication can be reasonably identified as part of the notice, the Office will consider the work to be published without notice.
If you want the legalese behind it, see Title 17 Sec. 401(b): https://www.copyright.gov/title17/92chap4.html
As for the original bloger's contention that only the first year of publication should be used, I would disagree. I would include all years a file has been touched, and let an attorney argue before a judge whether or not a change is "trivial" if it ever comes to it. In this context, the "triviality" of a change is a legal question. It's not a judgment you should be concerned with as the author; just make sure the stated year covers changes being made.
I am also not a fan of the "-present" usage because of its ambiguity. git log --pretty="%ci" or git show -s --format="%ci" appear to do most of the lifting to script replacing "present" with the year the file was last touched. I'll see if it can be added easily to the automated checking (probably just do a new script).
I am a nonlawyer, and I am not offering legal advice.
It is clear people are passionate about this topic.
It is also clear that in my opinion there is no purely technical "correct" solution and also that we do not have Team members who can speak to the legality of any proposal to a level that could conclude the decision non technically.
When deadlocked like this we traditionally just stick with the status quo but in this case I propose we take the discussion to slack and conclude with an eventual Team vote should the deadlock remain.
meh, hardly a reason to not merge.
If team members won't follow guidelines who else should do?
I don't understand this comment. If you don't see any priority for this why comment?
I don't see any priority in this discussion particular but you've raised this topic in an interesting and most likely useful PR so although I couldn't care less if present is present I do care about faster linking speeds.
We've already talked to lawyers (and even signed some papers). They hardly have time for large projects like Kodi and have even less time for small projects like ours blush
I see - and even if they've had some time to spent nobody could give a foolproof hint how to deal with this copyrights? Anyway as I'm no lawyer I lack the fantasy to understand the problem about the usage of present anyway. Maybe it's lost in translation but why not change it to "-present time" / "-now" or anything else suitable for native speakers. For me it sounds pretty much like splitting hairs if some lawayer would argue present could mean anything else...