Repository navigation
license of src/libcec/platform/adl/adl_* #748
Description
As Debian's automated tooling becomes more sophisticated, it picks up more little issues. One thing it noticed recently was that the files
src/libcec/platform/adl/adl_defines.hsrc/libcec/platform/adl/adl_sdk.hsrc/libcec/platform/adl/adl_structures.h
have a weird license:
// Copyright (c) 2008 - 2012 Advanced Micro Devices, Inc.
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND,
// EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
// WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
Note that this does not grant permission to use, copy, modify or redistribute. This is a problem!
My guess is that AMD basically meant to put these in the public domain, since they are just describing some interfaces with zero creativity. Might it be possible to get a note from them to that affect, or find the same info (or files) somewhere else under an appropriate free license?
Activity
barak commentedon Aug 17, 2026
Just checked, and AMD has since republished these same headers under the MIT license as the GPUOpen display-library SDK.
https://github.com/GPUOpen-LibrariesAndSDKs/display-library/tree/master/include
I've just pushed a commit to my fork of this repo, d7db050, which uses the newer MIT-licensed adl_*.h files. It also has a tiny patch to adl-edid.h to get them to work. Will make a pull request presently.
opdenkamp commentedon Sep 2, 2026
Thanks, picking this up now and addressing the other paperwork around this licensing issue
opdenkamp commentedon Sep 2, 2026
Fixed, and the audit it prompted went a bit wider than the three headers.
The ADL headers themselves — #749 (thanks @barak) replaced them with AMD's ADL SDK 18 versions, which carry a real MIT grant. Your guess was right: AMD did relicense them, so no note from them was needed.
Everything else the licence texts were getting wrong.
debian/copyrighthad onlyFiles: *andFiles: debian/*, so it positively misstated the AMD files as GPL-2+/Pulse-Eight, andLICENSE.mdcarried no copy of the MIT notice at all. That turned out to be one instance of a general problem — each distribution ships a different set of third-party code and nothing described it:libusb0.dll, pluslibusb0.dll/libusb0.sysinside the bootloader driver installer, LGPL-2.1+) and Microsoft DPInst inside both driver installers, and compiles node-addon-api into the prebuilt Node addon — none of it attributed anywhere;src/libcec/adapter/IMX/*is GPL-2+ only — the port's author struck the commercial-licence paragraph deliberately, keeping it intact on the file he copied verbatim in the same commit — so the blanket "GPL-2+ or other" claimed an option that cannot be offered on those files alone;src/libcec/adapter/Tegra/TegraCECDev.hhad no licence header at all.So rather than patch each file,
licenses/components.jsonnow records what each component is, whose copyright it is, which licence it falls under and which distributions carry it, andsupport/generate-licenses.pyassemblesLICENSE.md,debian/copyright, the two binding licence files and — per build, since it carries more — the Windows installer's own text. No licence text is maintained in two places, andrelease.pyrefuses to cut a release when the tracked outputs have drifted from the manifest.licenses/README.mdhas the details.Debian's tooling should be happy now; if it still finds something, please reopen.
One thing out of reach:
support/windows/p8-usbcec-driver-installer.exeis a prebuilt binary from 2012 with our ownCOPYINGbaked into it, so its copy is stale until that installer is rebuilt. It's noted in the repo so it doesn't get rediscovered as a bug.barak commentedon Sep 2, 2026
I think I (well, my software minions) already made those updates to my version of
debian/copyrightbut will double check. Perhaps we should look into unifying my debian packaging with yours, to the extent possible? It's in my fork branchdebianopdenkamp commentedon Sep 2, 2026
Went through the
debianbranch on your fork and synced what applies. It's all on master now (08668c0..2680fc0).All four of your quilt patches are already upstream, so
debian/patchescan go: the spelling fix, both cecc-client implementations (--helpand--list-devices) and the__stdcalltweak inadl-edid.hall landed with #749.Taken as-is. Your
cecc-client.1andpyCecClient.1— both were shipping with no documentation at all, and I checked every option in the cecc-client page against the source before taking it.cec-client.1moved intodebian/man/alongside them so our layouts match. Alsodebian/upstream/metadata,debian/clean(plus the two files we generate that yours doesn't), and the build-localHOMEfor node-gyp.Changed. The Python module path was a real bug and I'm glad you caught it —
import cecsimply failed on an installed package, because cmake hangs the module offCMAKE_INSTALL_LIBDIRand debhelper sets that to the multiarch triplet. Rather than themv/rmdirinrules, dh_install's two-column form does it in the.installfile:libcec8-devis nowMulti-Arch: samewith thePre-Depends, andlibudev-devis[linux-any].Licensing — one new thing for you. Contributions committed to this repository come in under the contributor agreement at https://www.pulse-eight.com/contributors, which leaves copyright with the contributor and grants us the licence that makes the dual-licensing possible. The Exynos, AOCEC and Linux backends arrived that way, so they're under libCEC's own terms — but the holders were never named, and
licenses/components.jsonnow records them.The EventGhost plugin is the exception, and it wasn't on your list either. Three files under
src/EventGhost/egplugin_sources/PulseEight/embed code from EventGhost itself and carry that project's GPL grant alongside ours, so they're GPL-2+ with no commercial option — the same position as the i.MX6 backend. They're packaged by the Windows installer, so they were missing from that licence text entirely.Your
debian/copyrightcan drop theFiles-Excludedfor the ADL headers and the copies underdebian/src/whenever you next rebase.One I couldn't reproduce: the unstripped
libcec.a. I built it withdpkg-buildflagsand the backend flags fromrules, then ran dh_strip's own test against it (perl -B, dh_strip line 243) and it comes back binary, so dh_strip does strip it. Our symbol table is runs of00 01 c9 3e— a NUL and a high byte per offset, andc9 3eisn't valid UTF-8, so nothing pushes it to the text side. If your build really does ship the 22MB version, could you paste the lintian output? Happy to take the workaround, I just don't want to carry it for something I can't see failing.Deliberately left for now. Standards-Version 4.7.4, debhelper-compat 14 and
pkgconfall assume a newer Debian than some of the distributions ourchangelog.intargets, so those want their own pass rather than a copy. Same for renamingpython-libcectopython3-libcec, which needs the Breaks/Replaces dance.On unifying the packaging: it's worth doing, and this closes most of the gap from our side. The remaining divergence is mostly deliberate — we ship a
libcec-dotnetpackage you don't, our source format is native, and we renamedlibcec-devtolibcec8-devto track the SONAME. Everything else looks reconcilable.barak commentedon Sep 2, 2026
Fantastic. I will, to the extent possible, use your debian/* scripts with only whatever minimal changes I need for Debian policy and consistency with previous versions. I will however defer this until your next official upstream release.