4

I am developing a commercial product that ships with a custom embedded Linux distro (similar to Yocto), and am in the process of collecting the copyright and license notices to comply with the GPL requirements. I intend to extend an offer to provide the sources and mention the GPL on the user interface of the program. I should also mention that the user will not access the command line, rather interact via a web interface, and because of that /usr/share/licenses/ is empty.

Is it my understanding from GPL-2.0 §1 that I should mention the copyright, license and warranty terms of all GPL'd programs shipped, which for me means the Kernel, bootloader and all the extra SW packages that form the distro. This is proving to be an utter nightmare to collect, with a lot maintenance effort. I have encountered the following problems so far:

  • Lots of packages with no clear info of copyright holders, either with no AUTHORS file, or the AUTHORS file is empty and no clear mention in a README. One has then to dig lots of source files headers, where no distinction between authorship and contribution is made (this can lead to a few dozen names per package). This is also very tiresome and error prone.
  • Some packages (e.g. binutils or dropbear) have lots of slightly different licensed and authored components, which gives half a page long notice.
  • Some packages are free, but require a copyright notice, adding to a very lengthy list of information.

Also, with software updates it is possible that some packages have a newer GPL/LGPL version, more contributors, or some are added/removed, causing a considerable maintenance effort. At the moment I have about ~120 different SW Modules (OS, bootloader and packages managed by the lightweight package manager).

My questions are:

  1. Do I really have to mention all that information for all those packages? A google search shows a lot of 1 Paragraph GPL notices, but that seems to fall very short of the requirements.
  2. How is this usually done in custom/embedded distros? I am certainly not the first one to ship a commercial product with a custom distro.
  3. If I were to provide the licenses on /usr/share/licenses/, would that help me fulfill the requirements? I assume not, at least because in my case that would be inconspicuous.
  4. Any idea on how can I make this process less laborious?
4
  • can you put the license files there and have the user browse that dir? Commented Feb 2, 2021 at 23:27
  • @planetmaker but then there is still the copyright notice
    – calofr
    Commented Feb 3, 2021 at 10:03
  • Here is a list of copyright notices for LG TVs, running WebOS, as an example. I've pulled this because WebOS uses Yocto (yes, there's an OSS version too). As an another example, here's the license list Yocto generates. Notice that it uses a list of SPDX identifiers (which are specified in recipes) so it is easy to collate the data. From what I have seen, Yocto generally only identifies the license files and goes on, not bothering to identify individual contributors...
    – jaskij
    Commented Feb 8, 2021 at 21:35
  • For Linux kernel the only file in the licenses subdirectory of the build output is the 18-line COPYING file. Personally, I'm inclined to believe that a Linux Foundation project is doing it right and leave it at that.
    – jaskij
    Commented Feb 8, 2021 at 21:36

1 Answer 1

1

The easiest solution is to just ship the open-source code alongside the product, in a SD card or USB Stick.

Deeply embedded open-source code inaccessible by the user is the very definition of inconspicuous. Also there may be size/performance/configuration restrictions hindering compliance on such platforms, unlike say a Ubuntu OS, where the user can interact with the software directly on a powerful computer.

And then there are a lot of packages where the authors do indeed gpl the code, but do no bother with copyright and authorship clarifications. Most of the time that is fine because the user is the one actually manipulating, compiling or inspecting the code, but not here.

By shipping all the open-source code (assuming you have a clear separation between open-source and proprietary modules) you are not giving away anything really, in terms of your commercial interests - it is not where you add value to the product, but you can save yourself the nightmare of collecting the authorship and copyright (and licensing btw, there are (L)GPL-X.Y, BSD, MIT, unspecified and custom licensed software pieces all across such complex items as a Linux distro) information. Instead, give everything away, let the user know about it (those 1 paragraph disclaimers you mention) and sift through it if he wants.

Theoretically it is still not legally clear if you are fully compliant, because you are not disclosing the copyright information properly in the disclaimer to the user, but you show effort and you change the possible legal consequences from licensing royalties to a less severe compensation for damages.

IANAL, although I did consult with one on this matter.

2
  • This use case seems to habe been neglected by the open source licenses - the compliance effort to the letter is insane. There also seems to be a lot of legal unclarity regarding how strictly does one have to comply.
    – calofr
    Commented Mar 12, 2021 at 16:06
  • 1
    If you think that's limited to open source, think again and start reading EULAs and licenses of all proprietary software you buy. It's intrinsic to anything related to copyright (maybe better called copy"right"). Commented Mar 12, 2021 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.