Re: GPL-3+ licensed test fixture (SVG/metadata) in BSD-3 project

Soren Stoutner <[email protected]> Mon, 16 Mar 2026 15:22:25 -0700
Newsgroups	gmane.linux.debian.devel.legal
Organization	Debian
Message-ID	<3464728.yKVeVyVuyW@soren-desktop>
On Monday, March 16, 2026 12:47:16 PM Mountain Standard Time Mechtilde Stehmann 
wrote:
> Hello,
> 
> Am 16.03.26 um 20:15 schrieb Soren Stoutner:
> 
> > On Sunday, March 15, 2026 3:06:12 AM Mountain Standard Time Carl Keinath
> > wrote:
> 
> >> Hello,
> >>
> >>
> >>
> >> I have a licensing question regarding a Debian package. The upstream
> >> project is licensed under BSD-3-Clause. To run autopkgtests, I added a
> >> minimal cursor theme under debian/tests/. It consists of an SVG image
> >> and a metadata file (.hl) used as input data by the tests.
> >>
> >>
> >>
> >> These files are licensed under GPL-3+. During the tests they are
> >> converted into a compiled theme format (.hlc), which the test binaries
> >> then read. The files are not part of the upstream source code, are not
> >> linked into the program, and are not installed in any binary packages.
> >>
> >>
> >>
> >> Could including these GPL-3+ test data files under debian/tests/
> >> cause the resulting test binaries, or the source package as a whole,
> >> to be considered a derivative work of GPL-3+?
> >>
> >>
> >>
> >> PS: please CC me, as I am not subscribed.
> > 
> > 
> > No, I don’t think adding GPL-3+ test data to debian/tests makes the shipped
> > binary
 packages GPL-3+ (if someone is aware of a way that it would make
> > the shipped binary packages GPL-3+, please correct me).  It does force
> > everything that runs the Debian tests to comply with the GPL-3+, but that
> > is not a problem for Debian, as our testing infrastructure handles many
> > GPL-3+ files.
> > 
> > I think you are fine as long as the licensing of these files is correctly
> > identified in debian/
 copyright.
> 
> 
> The main question is:
> 
> What are the requirements to have a derived work in the sense of the GPL?
> 
> What can I put together without having a derived work?

A derivative work is one where the non-GPL code is compiled into a binary with the GPL 
code, or where the non-GPL code uses the GPL code through an API (like linking with a 
GPL library).

A derivative work would ship the GPL code in the binary package, and the binary package 
would break or lose functionality if the GPL code were removed.

Because the GPL code is only being consumed as a data file in the testing environment, it 
does not produce a derivative work.  However, it does make the test itself GPL, so anybody 
that runs the test or who forks it must comply with the GPL.  For example, I cannot fork 
the test, modify it, and distribute it without making the modifications to the test available 
under the GPL.

In GPL legalese, this is what is called a compilation.  This is similar to how Debian ships a 
compilation of packages on a single distribution media, but they aren’t compiled together 
and don’t depend on each other.  The data in your test can be considered a separate entity 
from the upstream project.  The testing infrastructure can use it in combination with the 
main program, but neither depend on each other to run and someone who installs the 
binary package will never encounter a code path that includes the GPL code.

-- 
Soren Stoutner
[email protected]
signature.asc (application/pgp-signature, 833 B)