Arch Linux finally starts licensing PKGBUILDs

By Joe Brockmeier
November 26, 2024

Arch Linux is popular as a base for other Linux distributions; examples of Arch-derivatives include EndeavourOS, Manjaro, Parabola, and SteamOS. There's one small problem: the control files used to describe how to build packages for Arch Linux have no stated license. That creates a bit of uncertainty about the rights and responsibilities for the downstream derivatives. So far, that doesn't seem to have been a problem, nor has it stopped other projects from assuming that reuse is allowed. However, the Arch project is looking to add some clarity by explicitly assigning a liberal license to its package sources. Currently the project is in the process of reaching out to contributors to see if they have any objections.

An Arch Linux package is described using a PKGBUILD file, which is a Bash script used by the makepkg utility to compile the package source and make it ready to install using the pacman package manager. The Arch wiki has a good overview of the components and steps needed to create an Arch package.

RFC

What Arch Linux packages have not had in the 22 years since Arch was first released, is explicit licensing for the PKGBUILD files or other incidental scripts that are used to create packages. In August, Sven-Hendrik Haase took the first steps to correcting this by following the Arch RFC process and submitting an RFC that proposed licensing all Arch Linux package sources under the terms of the Zero-Clause BSD license. (The license is erroneously named, as it was modeled after the ISC License and not one of the BSD licenses.) This would include things like the PKGBUILD file, systemd files, and other files for installation on Arch and Arch-derived systems, but not change any licensing for the packaged software.

The RFC to clarify PKGBUILD licensing does not seem to have been prompted by a recent event, but the text of the RFC does note that people have raised concerns over the lack of license in the past.

In 2011, there was a lengthy discussion on Arch's aur-general mailing list about the legal status of files uploaded to the Arch User Repository (AUR), including PKGBUILDs, but that did not lead to any action. In 2020 Denis "GNUtoo" Carikli opened a bug report in the Parabola bug tracker looking to clear up the copyright status of Arch package sources. Activity in the bug report stalled until November 19, when it was updated about the RFC.

It is somewhat unusual for a major Linux distribution to have no policy regarding its package sources. Debian does not have an overarching policy on which license should be assigned to files used for building each package, but its packaging guidelines require a debian/copyright file included with each package (see example). That file describes the license assigned to every file in a package, including the packaging-related files under the debian directory.

Fedora considers the RPM spec files to be code, which are covered by the Fedora Project Contributor Agreement (FPCA). Unless declared otherwise, spec files for Fedora packages are given the MIT license by default, as noted in the FPCA for code contributions. Contributors can choose other licenses if they wish. For example the spec file for the php-smbclient package is explicitly licensed under the Creative Commons CC BY-SA 4.0. But in the absence of a declared license, there is a default license that is assigned.

The openSUSE project requires spec files to have a license header. It assigns the same license to its RPM spec files as the license of the package itself. So, if a package is GPLv3-licensed, the spec file is also considered GPLv3. The exception is if a package does not have an open-source license, then the spec file is assigned the MIT License. Gentoo's ebuild repository contains a header file with the GPLv2. Individual packages may also have copyright assignments to "Gentoo Authors" and list the GPLv2 as the license (example).

Is this really necessary?

Even though it is a common practice, some Arch contributors were skeptical of the need to license package-build files. The initial draft of the RFC would have had the project try to identify every developer who had contributed PKGBUILD files and any other build files, and ask their permission to license the contributions. The project would email each contributor and ask for a reply with this language: "I agree to provide all my contributions to the above packages under the terms of the Zero-Clause BSD license." If the developer did not agree, or they could not be reached within six months, then the project would decide if the contribution needed to be removed and rewritten. That, obviously, would entail a great deal of work on behalf of the project without dramatic benefits—and some contributors were not convinced the effort was necessary or desirable.

Christian Heusel asked why the Arch terms of service (ToS) did not apply when developers contributed PKGBUILD files. The ToS states that contributions to Arch projects are assumed to be under the GPLv3 if no other license is stated. Morten Linderud replied that the ToS is less than a decade old, and would not clear up the legal status of PKGBUILDs overall. Though he did not say so explicitly, many contributions may predate the ToS by several years.

User "Toolybird" said that they did not understand "all the fuss" and complained that the attempt to declare licenses for PKGBUILD files "smacks of corporate influence". They expressed disagreement that even complex build scripts should be subject to a license or copyright.

Allan McRae was more diplomatic, but still wondered whether it was a project worth doing. He noted that the only gain would be for distributions based on Arch Linux, all of which seemed to be working fine without the clarification. "Given the lack of contribution heading back upstream, is it worth 1,100 hours to address?" He suggested instead that the project contact all contributors to give them the opportunity to disagree, but not try to get an affirmative response from each one. Haase liked that idea, and incorporated it to the proposal.

Accepted

Once Arch RFC's are accepted, they are merged into the rfcs repository and made available on the Arch Linux RFCs page. After discussion, an RFC is finalized and an announcement is sent to the arch-dev-public list to start a 14-day final comment period. Haase announced the comment period on September 3, and the RFC's final draft merged on September 23. It calls for the project to scan all packages for #Maintainer and #Contributor tags to come up with a list of contributors to contact.

Rafael Epplée said that the project had gathered about 5,000 unique contributor emails. The project announced that emails would start going out, over the course of a week, on November 19. Contributors who are fine with the change need do nothing, the project will assume their consent to the license assignment and drop a LICENSE file into the package repositories after four months. In the event a contributor objects, the project will decide on a case-by-case basis what to do next.

Arch's approach may not be quite what a lawyer would recommend, but it seems like a reasonable and pragmatic approach to solve a longstanding problem. It seems unlikely that many, if any, Arch contributors will have strong objections to a permissive license being applied to package sources even if they don't believe it's wholly necessary. It will be interesting, four months from now, to see if any have objected at all, and (if so) what their reasons are for doing so.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 16:48 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] (35 responses)

GPL2 contains the text

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.

and GPL3 has similar language. This would imply (in fact, require) that the scripts for a GPL2 or 3 package be distributable under compatible terms. The package scripts control compilation and installation.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 17:05 UTC (Tue) by intelfx (subscriber, #130118) [Link] (34 responses)

> and GPL3 has similar language. This would imply (in fact, require) that the scripts for a GPL2 or 3 package be distributable under compatible terms. The package scripts control compilation and installation.

The package scripts are not a derived work of the program being built (nor they are part of that program). GPL has no jurisdiction over them.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 17:26 UTC (Tue) by ballombe (subscriber, #9523) [Link] (25 responses)

... because they would work fine without the upstream source, they do not depend on filenames installed by the upstream makefile, they do not run the upstream build scripts etc.

Sure.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 17:28 UTC (Tue) by intelfx (subscriber, #130118) [Link] (24 responses)

I'm pretty damn sure that running another program, or even depending on its output format (in some sense of the word), does not create a derived work relationship.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 18:44 UTC (Tue) by npws (subscriber, #168248) [Link] (18 responses)

Correct. However in order to distribute the binary, you have to accept the license, and even if your build scripts are not a derived work, you are obligated to provide them under the terms of the GPLv2/v3.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 19:54 UTC (Tue) by daroc (editor, #160859) [Link]

I've seen a few discussions along these lines about what is or isn't a derived work, and when a license does or doesn't apply. And while I think that it's an interesting topic, I also think that it can quickly devolve into people confidently stating opinions on the law, while not themselves being lawyers. So feel free to continue discussing, but I would appreciate it if everyone would make sure that their future comments say something new, and don't just re-state existing assertions.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 20:30 UTC (Tue) by Wol (subscriber, #4433) [Link] (16 responses)

> However in order to distribute the binary, you have to accept the license, and even if your build scripts are not a derived work, you are obligated to provide them under the terms of the GPLv2/v3.

So what happens when (as has happened with me) the make files have a different author to the main project source, and were written because the main project didn't have any?

As was stated elsewhere, this promptly kills any requirement to provide said build scripts (because the original project didn't have any), and the GPL has no jurisdiction due to the lack of derivation.

(In practice, the makefile is "GPL by default", but there's nothing stopping it being explicitly GPL-incompatible.)

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 0:07 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (15 responses)

It seems that if you give someone an executable of a GPL program, the text requires you to provide source, and the license says the source includes the build script you used to produce that executable.

If you don't provide an executable, then sure, it seems you can claim that any build scripts you have are independent works. I agree that they aren't derivative works. But it's producing the executable that combines them: the executable depends both on the original source and your build scripts. So you need to provide both to comply with the license if you distribute compiled code.

IANAL, but really, just read the text of the license. That's what it says.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 1:09 UTC (Wed) by sfeam (subscriber, #2841) [Link] (14 responses)

" the license says the source includes the build script you used to produce that executable".

I suspect this brings us right back to the oft-noted point that it is not within the power of a license to define what is or is not a derivative work. I would argue that it is similarly not within the power of a license to extend itself to cover additional objects, text, entities, etc that are not inherently part of the work being licensed. There is also the argument that this requirement is invalid because it is too vague. What exactly constitutes "the build script you used"? Is it the makefile? a shellscript that invokes the makefile? the shell itself? the configuration script for your build environment? all or none of the above?

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 10:37 UTC (Wed) by Wol (subscriber, #4433) [Link] (11 responses)

And indeed, this is covered by the definition of what is FLOSS.

It is very clear that FLOSS *forbids* licences attempting to cover "mere aggregation". So again we're getting into the realms of "what is a derivative work". Given that tarballs, git repositories etc rarely contain binaries, the argument about "derivative works" almost certainly doesn't apply to distributing those.

I wonder - the requirement for build scripts etc - is that a GPL3 anti-tivo-isation measure? It would be "interesting" if an attempt to ensure freedom actually broke freedom in a different way. Rather like GFDL documents are considered "unfree" if they contain invariant sections ...

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 11:02 UTC (Wed) by anselm (subscriber, #2796) [Link] (10 responses)

I wonder - the requirement for build scripts etc - is that a GPL3 anti-tivo-isation measure?

The build-script requirement is already in GPLv2, which predates the TiVo.

AFAIR, the “anti-TiVo-isation” effort in GPLv3 added the notion of “User Products” (such as DVRs) and stipulated that software conveyed for use with User Products must include any required “methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product” (GPLv3 section 6). This goes beyond the requirements in GPLv2 to prevent a situation where, e.g., the DVR you bought came with complete source code under the GPLv2 but its proprietary boot loader will only run an operating system signed with the device maker's private key, which is not part of your software package.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 15:04 UTC (Wed) by malmedal (subscriber, #56172) [Link] (9 responses)

> but its proprietary boot loader will only run an operating system signed with the device maker's private key

According to Bradley Kuhn, this is not correct, he says you could install and run your own Linux-version on TiVo as much as you wanted, but if you did, the proprietary software would stop working.

https://sfconservancy.org/blog/2021/jul/23/tivoization-an...

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 8:21 UTC (Thu) by anselm (subscriber, #2796) [Link] (8 responses)

According to Bradley Kuhn, this is not correct, he says you could install and run your own Linux-version on TiVo as much as you wanted

I wasn't making a claim about the TiVo in particular – this was just a hypothetical to describe the sort of provisions the GPLv3 adds to prevent clever antics on the part of device makers.

(You could note, too, that Linux specifically is GPLv2, so nothing in the GPLv3 that isn't in the GPLv2 would apply to a Linux-based DVR in any case. Just imagine, for the sake of the discussion, a future Linux-like operating system that DVR manufacturers might like to use and that is published under the GPLv3.)

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 11:34 UTC (Thu) by malmedal (subscriber, #56172) [Link] (7 responses)

> I wasn't making a claim about the TiVo in particular

Sure, Kuhn's claim is that TiVo agreed that GPLv2 forced them to allow the user to install and run modified Linux.

I believe this sentence from your post is wrong:

>>> but its proprietary boot loader will only run an operating system signed with the device maker's private key, which is not part of your software package.

If I am understanding Kuhn correctly he says that GPLv2 already forces the device manufacturer to provide such keys, and that TiVo agreed and complied in the case of their device.

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 13:35 UTC (Thu) by anselm (subscriber, #2796) [Link] (6 responses)

If I am understanding Kuhn correctly he says that GPLv2 already forces the device manufacturer to provide such keys, and that TiVo agreed and complied in the case of their device.

I'm certainly not going to disagree about GPL interpretation with Bradley Kuhn, who is after all a lawyer and noted GPL expert.

It does leave me wondering, though, why the GPLv3 went to the trouble of adding all sorts of provisions about “User Products” and so on, if the GPLv2 already does what is required. (In the case of the TiVo there's obviously no way the Linux kernel license could prevent the – “merely aggregated” – TiVo user-space software from checking whether it is running on an official TiVo-provided kernel and refusing to work if it isn't, and that would presumably also apply if the kernel was GPLv3 instead of GPLv2.)

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 16:27 UTC (Thu) by malmedal (subscriber, #56172) [Link] (3 responses)

I believe it is because of this paragraph in GPLv3(important bit in bold):

"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

Kuhn says he asked Stallman and Stallman confirmed that the point of this was to ensure that proprietary software should continue to function normally even if the GPL parts were modified, and my understanding is that this also holds for "mere aggregation".

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 1:55 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

That sentence only seems to cover the modified GPLed code though? IIRC from Kuhn's posts, in the TiVo scenario the modified GPLed code still works fine, its just that the proprietary userland code running on it will not.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 1:57 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

See also Kuhn's GPLv3 in automotive presentation:

https://events19.linuxfoundation.org/wp-content/uploads/2...

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 10:41 UTC (Fri) by malmedal (subscriber, #56172) [Link]

Interesting, thank you, in his blog-post Kuhn writes.

Specifically, I asked him on 2012-05-05:
[so], these words in GPLv3: “The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.” mean that the proprietary software that is not a combined work with the GPLv3'd work must also function?
Stallman replied on 2012-05-06 with:
Absolutely. And I wrote it specifically to do that!

In the slides he says:

Ironically, even if Linux were GPLv3, Tivo’s method of crypto-lock-down would likely comply with GPLv3.

bkuhn checked this with RMS: even he agrees this mechanism complies with GPLv3.

I can't find anywhere he has written his reasoning, would be interested to read a longer explanation of exactly what would and would not be a violation.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 13:24 UTC (Fri) by paulj (subscriber, #341) [Link]

Last I knew, bkuhn did not claim to have any formal legal qualifications. Even if he were, you certainly could still disagree with Bradley - because there is no consensus in the legal world on a number of questions around the GPL.

Sometimes I get the feeling that some of the leading copyleft lawyers almost prefer not to see these questions argued in court and decided authoritatively (and here I do not refer in any way to bkuhn or anyone related to SFC, just for clarity). But maybe that's just my limited experience.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 15:42 UTC (Fri) by Wol (subscriber, #4433) [Link]

> It does leave me wondering, though, why the GPLv3 went to the trouble of adding all sorts of provisions about “User Products” and so on, if the GPLv2 already does what is required.

Maybe, at the time, it didn't?

Especially in light of the Playstation II furore, maybe TiVo changed the mechanism to be GPL3-compatible. If I thought something at work was a grey area (legal, H&S, whatever) and I could see a quick fix, I'd push for it ...

Businesses don't like expensive problems. Offer them a quick and cheap fix for a potentially expensive problem, and you should be able to get it through.

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 0:35 UTC (Thu) by gdt (subscriber, #6284) [Link]

A license doesn't have to limit its demands to "derived works". In fact most licenses do not -- they demand a payment.

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 17:09 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

> I suspect this brings us right back to the oft-noted point that it is not within the power of a license to define what is or is not a derivative work. I would argue that it is similarly not within the power of a license to extend itself to cover additional objects, text, entities, etc that are not inherently part of the work being licensed.

That is not how this works. You need permission to distribute the binaries. The license says, effectively, I will give you permission if you comply with my instructions. Those instructions can cover anything under the sun. If you don't want to follow the instructions, that's fine, it just means you cannot distribute binaries of the licensed program. It does not mean you get to pick and choose which instructions you want to follow.

> What exactly constitutes "the build script you used"? Is it the makefile? a shellscript that invokes the makefile? the shell itself? the configuration script for your build environment? all or none of the above?

The authors of the GPL already thought of all of those questions. Here's GPL 2:

> The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

GPL 3 contains a longer and more elaborate set of definitions in section 1 (which are, as far as I can see, largely equivalent to GPL 2, but more detailed). See https://www.gnu.org/licenses/gpl-3.0.en.html#license-text and note that definitions provided in section 0 are used in section 1.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 11:06 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

What are your grounds to be "pretty damn sure" of that? Can you cite something to that effect?

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 11:52 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Well, it can, in the sense that a compiler may contain chunks of code that it copies verbatim into the resulting binaries - which is why I believe GCC explicitly disclaims any copyright that may transfer to object code.

But for a perfect example of what you want ... is your blockbuster novel a derived work of the word processor you used to create it?

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 16:22 UTC (Wed) by paulj (subscriber, #341) [Link]

The comment I was replying to stated this does not have any copyright implications:

> "running another program, ... depending on its output format"

E.g., a possible scenario: popen() some other programme, have it perform some task for you and take the resulting output and use it, such that your programme /depends/ on that other programme. At least, that's a scenario that lies within the realm of scenarios this statement admits. If the comment author didn't intend that with their statement maybe they can clarify. If they did intend that scenario to be covered, I'm curious for the reasoning to believe we can be "damn sure" there are no copyright implications.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 17:06 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

I advise you to be less combative, but yes, I can: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
>
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
>
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

Note that I never said that "running another program *prevents* a derived work relationship". I said that such a relationship is not necessarily created by running another program or even depending on some properties of its output. Even if you "popen() some other programme, have it perform some task for you and take the resulting output and use it, such that your programme /depends/ on that other programme". The FSF seems to agree with me.

While I'm clearly not a lawyer, it is my belief that "depending" on the names of the binaries created by the upstream build scripts is far too insignificant of a dependency to be considered a basis for a derived-work relationship.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 17:19 UTC (Wed) by paulj (subscriber, #341) [Link]

Hmm, I wasn't being combative. It was meant to be an open question that didn't pre-suppose an answer, so I could perhaps learn something. Maybe a little terse, and maybe that was easy to mistake for combativeness, but that wasn't the intention.

The piece you quote from the FAQ is what I had understood before. Your comment made me wonder if you were arguing that running another programme (e.g. popen) /always/ prevented a "derives from" relationship, in which case I was curious to read more of your reasoning for that, to learn exactly why. But that wasn't what you meant - as you've just clarified there. Thanks.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 0:03 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (7 responses)

If you (generic you) take a GPL'd work, modify it, and redistribute it, either you're doing so in compliance with the license or not. The license says that you must include the source code. The license describes the source code as including the build and installation scripts. So either those build scripts are distributable under terms at least as generous as the GPL (either version), or there's a license violation. That's especially relevant when someone who uses the upstream tarball would wind up with a different executable than the one you get if you install the package.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 0:44 UTC (Wed) by intelfx (subscriber, #130118) [Link] (6 responses)

> If you (generic you) take a GPL'd work, modify it, and redistribute it, either you're doing so in compliance with the license or not. The license says that you must include the source code. The license describes the source code as including the build and installation scripts. So either those build scripts are distributable under terms at least as generous as the GPL (either version), or there's a license violation. That's especially relevant when someone who uses the upstream tarball would wind up with a different executable than the one you get if you install the package.

The problem with this line of reasoning is very simple: Where do you draw the line?

If a script calls another script, which then calls the upstream build system, do I suddenly "grow" such obligations for both scripts? What about three?

What if the entire machinery plugs into some sort of a central management system for my build farm, do I have to share all of that (let's suppose, for the sake of example, that build flags are being passed from the topmost level, which affects the reproducibility of the executable, like you say)?

In the end, the GPL under your interpretation becomes not different from, say, SSPL. Which is clearly an absurd conclusion.

So, IANAL, but I emphatically do not buy your interpretation of the GPL.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 1:34 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (5 responses)

For an RPM or .deb or equivalent from another distro, it seems it is fairly easy: the package is self-contained. Treat it as a unit, including the scripts. If the installation calls out to services that are normally part of the OS, the GPL covers that case too:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

I don't think that this is hard. Especially as people are moving toward reproducible builds, we want everything necessary to reproduce that executable to be available. Doesn't mean the scripts must be GPL, they could be BSD0 or any other more permissive license. The point is, that if you provide the executable you're required to provide the source, and this includes any scripts used to turn the source code into the executable.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 1:44 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

> if you provide the executable you're required to provide the source, and this includes any scripts used to turn the source code into the executable.

So... what if there are no scripts, and I produce the binary though a series of manual command invocations?

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 0:47 UTC (Thu) by rra (subscriber, #99804) [Link] (2 responses)

It's almost like the GPL is an arcane and absurdly complicated legal document that almost no one fully understands, whose meaning is socially and in places legally disputed, and that many people in the free software community fail to follow correctly without ever realizing it.

I'm not going to argue with people about the merits of the GPL when applied to some large and complex piece of software that is meaningfully affected by the copyleft principles, but I wish people would think twice before slapping it on their 500 line Python library. Following the GPL correctly is nontrivial and controversial, and even people who have worked on free software for decades regularly fail to follow it correctly according to at least some people. I wish people would ask themselves whether it's really worth paying the mental tax for each specific piece of software before they blindly use it.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 16:15 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

If you think the GPL is bad, try reading the AGPL section 13 very carefully, and then think about which of the following scenarios might or might not violate it:

* The FooBar application, licensed under AGPL 3, has some networking functionality (which is elaborate enough that users can interact with it remotely), and is freely available (with source, full attribution, a copy of the AGPL, etc.) on GitHub. It does not have any feature that allows remote users to directly request a copy of its source code.
* You fix a typo or other minor bug in the FooBar source, commit the changes to a local Git repository, and send a pull request to the FooBar maintainers. You only fix the typo, and do not add a feature allowing remote users to request source from the application.
* The FooBar developers add a "request source" function to the FooBar application. It is implemented using mDNS, which relies on broadcast packets to work. You don't like broadcast packets on your home network, so you patch this functionality out in your own private copy of FooBar. This patch is never redistributed to anyone, and the binary is only ever used on your own private LAN that nobody else can access. For good measure, you hide the FooBar application behind some kind of client-authenticating reverse proxy, so that you can be absolutely sure that it has no remote users other than yourself.
* Alternatively, you stick your copy of FooBar behind a router or switch that is configured to drop broadcast packets.
* You make a FooBar instance accessible over the public internet, after making some minor modifications to it (all of which are contributed upstream via GitHub pull requests, so your copy of FooBar is identical to the public source code). But broadcast packets are not going to be routed over the public internet, so the source offer presents an unusable mDNS domain (your changes never touched the source offer part of the code).
* You change the link to point to the public GitHub, but upstream refuses your pull request (arguing that FooBar should serve its own source code without relying on GitHub or any other third party, and claiming that mDNS is "good enough" for their intended use case on a private LAN), so now you are presenting a source link that does not exactly correspond to the binary you are running.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 17:34 UTC (Fri) by rra (subscriber, #99804) [Link]

Oh, yeah, I absolutely refuse to use the AGPL for any software I write. If I'm going to have to invest that much time and mental energy into understanding a complex legal document, I'd better be getting a house out of it.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 1:48 UTC (Wed) by intelfx (subscriber, #130118) [Link]

> For an RPM or .deb or equivalent from another distro, it seems it is fairly easy: the package is self-contained. Treat it as a unit, including the scripts

Why? Who says that I am *obligated* to draw the line exactly at this point? I say the "self-contained unit" is the upstream tarball (which includes all scripts that _upstream_ deems a part of the "complete work"). Why am I wrong?

> If the installation calls out to services that are normally part of the OS, the GPL covers that case too

No, that's irrelevant to the point I was making. I have many scripts, they all call each other (and ultimately call the upstream build system), and none of those are part of the OS.

> I don't think that this is hard. Especially as people are moving toward reproducible builds, we want everything necessary to reproduce that executable to be available. Doesn't mean the scripts must be GPL, they could be BSD0 or any other more permissive license.

Okay, so what is it? Is it a copyright obligation or a moral obligation? If it's a copyright obligation (as you claim), they could not "be BSD0 or any other more permissive license". If it's a moral obligation, then that's not what we discussed. Let's stick to a single claim, please.

> The point is, that if you provide the executable you're required to provide the source, and this includes any scripts used to turn the source code into the executable.

I have contested your interpretation of this point in my previous reply.

We live in a crazy world

Posted Nov 26, 2024 19:01 UTC (Tue) by khim (subscriber, #9252) [Link] (11 responses)

We live in a world where Deep Purple needs to pay royalties if they perform their own songs.

I haven't contributed scripts to Arch Linux, but I have done that for some other distros… and I would really be annoyed if someone would ask me to indemnify them against such stupidity if they would use something I wrote 20 years ago.

I have lived in different countries, worked for different companies, I simply have no idea if I have the right to give permissions WRT these.

But if someone would ask me if I object to relicensing? Nope, I wouldn't. I simply don't care, but I couldn't prevent such cases and I don't want to pay out of my own pocket for someone's else stupidity.

That's why asking and getting no objecting is the best they can really hope for.

We live in a crazy world

Posted Nov 26, 2024 21:10 UTC (Tue) by jbschirtzinger (guest, #174780) [Link]

Yep. The trouble here is greed and litigation. If I were in a position where I had contributed to these products, I would have done so with the idea that the licensing was under some kind of GPL scenario. If suddenly I found out that was not so, I would probably want my contribution revoked.

We live in a crazy world

Posted Nov 27, 2024 10:16 UTC (Wed) by anselm (subscriber, #2796) [Link] (9 responses)

We live in a world where Deep Purple needs to pay royalties if they perform their own songs.

Nope. The band doesn't need to pay royalties to play their own songs – whoever is putting on the concert (presumably not the band itself) needs to pay royalties to the band, via a copyright collection agency. What the cited story leaves out is that – unless Deep Purple themselves are in the business of organising their own concerts in Russia, which sounds unlikely – the local concert promoter, who is the one on the hook for the royalties, apparently didn't dot all the i's and cross all the t's. Why Deep Purple get fined for this is anyone's guess (but hey, this is Russia, and probably somebody thought that Deep Purple = Deep Pockets).

The way copyright collection agencies work, a band contracts the management of their royalties out to the collection agency. The advantage for the band is that they don't need to deal with individual requests (which would otherwise be required by copyright law) to play their songs on the radio, have them performed by cover bands, etc., and of course also the royalties due to the band when the band performs its own material at a concert. The contract with the collection agency usually stipulates that royalties are due for any performance (including by the band itself) and that the band isn't supposed to make side deals that leave the collection agency out of the loop. And the collection agencies cooperate internationally to ensure that local concert organisers can talk to the collection agency in their country even though the band – if it is a big international touring outfit like Deep Purple – works with a collection agency in a completely different country. Finally, since professional musicians tend to subscribe to collection agencies, and since there is usually one collection agency per country, there is a presumption that that collection agency is in charge of all the interesting music that is around; the burden of proof is on concert organisers if they want to claim that, e.g., no royalties to the collection agency are due for a folk-music concert where the band (who is not affiliated with the collection agency) only plays its own arrangements of traditional tunes from the public domain. So, no surprise that the Russian copyright collection agency gets to levy royalties on the Deep Purple concert even if Deep Purple have never heard from them before – after all, clearing royalty payments for a concert in Russia isn't their problem, it's that of the Russian guys who have asked them to come and play.

Copyright collection agencies are, of course, not in any way mandatory but they are quite useful if you're a band (especially a big and famous band like Deep Purple whose music is played all over the world) – not least because concert venues, radio stations, bars, etc. like to have a single institution to talk to in order to manage their royalty obligations. Your friendly neighbourhood FM radio broadcaster is sure as hell not going to negotiate the right to play “Smoke on the Water” on the air with Deep Purple directly, which would be a time-consuming and expensive hassle for both the radio station and Deep Purple('s lawyers); they prefer to pay a monthly lump sum to the collection agency so they can air whatever songs – from the repertoire managed by the collection agency, which as we said covers approximately “everything” – they please.

We live in a crazy world

Posted Nov 27, 2024 11:17 UTC (Wed) by khim (subscriber, #9252) [Link] (8 responses)

> The band doesn't need to pay royalties to play their own songs – whoever is putting on the concert (presumably not the band itself) needs to pay royalties to the band, via a copyright collection agency.

That's distinction without a difference. Band have already received a compensation, band have done the work and band have never passed their rights to said copyright collection agency… why should it be involved in that crazyness at all?

Said NGO is supposed to collect royalties in cases where collection of said royalties is problematic… but how come that public execution of songs by their principal authors involve any royalties at all?

If the initiator of that crazyness would have been collection agency that band actually signed agreements with it could have been justified. But nope, that's not what have happened.

> there is a presumption that that collection agency is in charge of all the interesting music that is around; the burden of proof is on concert organisers if they want to claim that, e.g., no royalties to the collection agency are due for a folk-music concert where the band (who is not affiliated with the collection agency) only plays its own arrangements of traditional tunes from the public domain.

And, similarly, clearing the mess around copyright for scripts I wrote 20 years ago is not my problem either. I wrote and shared them in good faith, if there are suddenly, some crazy collection agencies somewhere who have the right to collect money in my name (even if I have never heard about their existence) – then it's not my mess.

> Copyright collection agencies are, of course, not in any way mandatory

That's the issue: in Russia they are mandatory. They don't even try to contact anyone before sending you to court. They are build on the presumption that everyone in the world is supposed to contact them and if someone doesn't – it's on them. It's not the collector's agency work to prove that I passed my rights to them, but mine.

> especially a big and famous band like Deep Purple whose music is played all over the world

Deep Purple are just most famous example of that crazyness. The collector agency in question even collect royalties in the name of dead USSR authors who died before said agency was created! These authors physically could sign any agreements with any collector agency, they died before that system was established!

> they prefer to pay a monthly lump sum to the collection agency so they can air whatever songs – from the repertoire managed by the collection agency, which as we said covers approximately “everything” – they please.

And that's why I couldn't idemnify you about my scripts written 20 years ago. These were simpler times and collector agencies haven't tried to collect money in my name back then. Today they do that and I have no idea if they would try to do that using my measly script or not.

They most I can promise is that I wouldn't try to sue anyone, but in a world where a dead author have be raised from the grave to visit the court and prove that he (or she) haven't passed the rights to some agency I couldn't claim, in good conscience, that someone else wouldn't sue you, in my name.

We live in a crazy world

Posted Nov 27, 2024 11:56 UTC (Wed) by Wol (subscriber, #4433) [Link]

> They most I can promise is that I wouldn't try to sue anyone, but in a world where a dead author have be raised from the grave to visit the court and prove that he (or she) haven't passed the rights to some agency I couldn't claim, in good conscience, that someone else wouldn't sue you, in my name.

The US tried to pass an internet streaming law that would DEMAND you pay copyright fees in order to stream your own copyrighted works ...

Germany has a law that allows lawyers to sue on your behalf without you knowing anything about it ...

This craziness isn't restricted to Russia ...

Cheers,
Wol

We live in a crazy world

Posted Nov 27, 2024 12:52 UTC (Wed) by anselm (subscriber, #2796) [Link] (6 responses)

That's the issue: in Russia they are mandatory.

I don't know a lot about Russian law, but what I meant is that certainly here in Germany, using a collection agency is very much not mandatory if you're a content creator. The downside, of course, is that without being affiliated with the collection agency, you will probably get less exposure (and money) because radio stations, CD manufacturers, etc. who must obey the relevant laws won't touch your stuff with a long pole – they don't need the hassle, and through their contract with the collection agency they already have everything they need to keep the air waves filled, so ignoring your stuff is no skin off their nose. If Bob's Bar & Grill puts on your CD for the entertainment of its customers and doesn't read the fine print, you won't get any of the monthly royalties check they send to the collection agency because you don't participate when that money is distributed. (Of course Bob's Bar & Grill shouldn't be playing your copyrighted CD without asking you first, but have fun suing Bob over it.) If you can live with that, then dealing with the collection agency is by no means required.

OTOH, if you're someone using presumably-copyrighted content, then getting out of having to deal with the relevant collection agency is way more difficult, due to the presumption that the collection agency is in charge of everything of commercial interest: It is on you to prove that you're not using anything managed by the collection agency, which can be tricky as the collection agency doesn't condescend to publish a definitive database of what they have – because, why would they? In the age of CC-licensed content this is becoming more complicated but so far the legislation around copyright collection agencies has not caught up. Even now, though, selling music outside the regime of the copyright collection agency is a legitimate business which finds eager customers among people who operate, e.g., elevators and call center queues.

It's not a problem at all for the collection agency to levy royalties on behalf of foreign content creators or content creators who haven't been dead long enough for their works to pass into the public domain – because they can. The collection agency will happily levy royalties even for the performance of public-domain material because as we said, it is a concert organiser's job to maneuvre themselves out of that and if they won't, then the collection agency will for sure not object to having its bills paid. (The collection agency doesn't care in the least what exactly is played at a concert – the royalties they collect are typically based on the size of the venue, the number of attendees, and the price of the tickets, not the material performed.)

People have been wondering, off and on, whether a system of copyright collection agencies for software along the lines of those established for music or written works would make sense. Every computer user would have to pay a set mandatory fee and, in exchange, would be allowed to use the software managed by the collection agency without having to deal with software makers directly. All the fees would go into a pot and would eventually be distributed to the software authors based on the size and popularity of their contribution (so that, e.g., Microsoft would get a very large share of the pot because their software is on 90% of people's computers and people use it all the time). The problem of “software piracy” would go away, and big companies would no longer have to be afraid of expensive software license audits. This of course has a whole boatload of problems, including but not limited to how you figure out who is using what software without infringing on everyone's privacy, or how one ensures adequate compensation for people who write highly complicated and specialised (thus, expensive to make) software that only a few people actually use. Also, there is a lot of useful software around right now that people don't need to pay for at all, and a presumption, à la music copyright, that everyone must pay the mandatory fee because the software collection agency is already in charge of everything that is interesting therefore won't fly. Finally, software companies generally reserve the right to set the fees they extort from users as they please and would probably not welcome a scheme where the money they get is just a share of a big pot over which they have no direct influence.

We live in a crazy world

Posted Nov 27, 2024 13:02 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

> The collection agency doesn't care in the least what exactly is played at a concert – the royalties they collect are typically based on the size of the venue, the number of attendees, and the price of the tickets, not the material performed.

In the UK at least, I presume they HAVE to care - having dealt with them you MUST send them a list of all the works (presumably under copyright) you have played, and they then distribute based on that list.

> so that, e.g., Microsoft would get a very large share of the pot because their software is on 90% of people's computers and people use it all the time

There is plenty of evidence - even based on the playlists that the agents collect - that the big people get more than their fair share, and the little people end up paying the majority of the agency's costs ...

> Also, there is a lot of useful software around right now that people don't need to pay for at all, and a presumption, à la music copyright, that everyone must pay the mandatory fee because the software collection agency is already in charge of everything that is interesting therefore won't fly.

Witness the Italian copyright enforcement people being taken to court for lying, when they paid for adverts saying "Copying CDs is illegal". Most if not all of Europe has a legal obligation to make sure adverts don't overstep the bounds - eg the UK's "Legal, Decent, Honest and Truthful". It was one of Europe's Free Software groups that sued, I believe, and the copyright agency pretty much crumbled on the spot without a leg to stand on.

Cheers,
Wol

We live in a crazy world

Posted Nov 27, 2024 13:53 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

Witness the Italian copyright enforcement people being taken to court for lying, when they paid for adverts saying "Copying CDs is illegal".

Many of the adverts the copyright-holder lobby puts out are based more on wishful thinking than actual law. For example, they will claim with great confidence and authority that downloading movies from the Internet is illegal, but the fact is that people don't generally get sued for downloading movies. If they're getting sued at all they get sued for uploading movies whose copyright they don't own, which is something that takes much more intent (unless you're using BitTorrent without knowing how that works) and is usually way easier to make stick.

What is technically not allowed according to the law, certainly here in Germany, is downloading movies “from obviously illegal sources”, but it is difficult for a layperson to figure out whether a site is “obviously illegal” if it looks very convincing and has a slick and professional UI that is, if anything, nicer than the official offerings. It's not as if such sites have a big banner at the top saying OBVIOUSLY ILLEGAL MOVIE SOURCE.

We live in a crazy world

Posted Nov 27, 2024 14:00 UTC (Wed) by Wol (subscriber, #4433) [Link]

> Many of the adverts the copyright-holder lobby puts out are based more on wishful thinking than actual law. For example, they will claim with great confidence and authority that downloading movies from the Internet is illegal,

So basically they're saying the whole streaming industry is a fraud?

In the UK, if they didn't plaster their claims with disclaimers left right and centre, they'd be in big trouble with the advert regulator. Who has the power (and they've used it) to ban them from ANY advertising without running it past the regulator first. They've only used it once or twice ...

> If they're getting sued at all they get sued for uploading movies whose copyright they don't own

Unless they're MGM, or Columbia, or Fox 2000, or Sony ... remember when they were regularly getting DMCA takedowns from themselves? <rofl> ...

Cheers,
Wol

We live in a crazy world

Posted Nov 27, 2024 14:11 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

Translation from English to English: said agencies are not caring about copyright protection of artistic works one jot (because how can you protect someone's interest if you don't even know if he is involved in what you are doing or not?) but are purely an extortion, racket business that exist solely to fill some people pockets.

They sign an agreements with people who don't need their services (because anyone who if famous enough to squeeze significant royalties from they guys don't need these money) and then pressure people who may benefit to giva up their rights.

That's very well-known phenomenon that existed as an ugly side-show to the recording industry and which was tolerated before broadband made distribution of music essentially free.

Why it should even exist today is entirely non-clear, but nonetheless, it persists.

> People have been wondering, off and on, whether a system of copyright collection agencies for software along the lines of those established for music or written works would make sense.

Of course it would! Sure, it would hurt the society and would make lives of everyone except these collectors worse, but it could bring enough money to pay to the legislators and then it would become a reality.

> how one ensures adequate compensation for people who write highly complicated and specialised (thus, expensive to make) software that only a few people actually use

Which is approximately 99% or 99.9% of all the software that exists. Sure, puny excel spreadsheet with a few knobs is not as glamorous as Excel itself, but if you count number of such spreadsheets, then, together they dwarf all the software that we have ever heard about by huge margin.

But that's still not a reason to create something like that – and I'm not gonna try to do anything about that, especially if that would happen in a country that I don't plat to ever visit.

Worse: since “protectors of my rights” don't deign it important to even notify me that they are “protecting my rights” I couldn't promise to someone that s/he wouldn't sued by said “protectors” without my knowledge.

We live in a crazy world

Posted Nov 27, 2024 14:54 UTC (Wed) by anselm (subscriber, #2796) [Link]

Why it should even exist today is entirely non-clear, but nonetheless, it persists.

Copyright collection agencies do solve an important problem: Without them, users of copyrighted content would have to talk licensing with creators of that content on a one-to-one basis, and that obviously doesn't scale well. Imagine running a radio station, or for that matter playing background music in a bar, if you had to obtain an individual license from every single composer, lyricist, arranger, and musician involved with every single song you play. Compared to that, having to deal with just one collection agency looks fairly reasonable and enticing, certainly from a practical POV.

There are very many things to criticise concerning the way copyright collection agencies are established in law, and how they go about their business. In fairness, a lot of their practices are probably not even deliberate attempts at extortion but simply holdovers from a previous time where they did sorta-kinda make sense (again from a practical POV). Some reform would certainly be nice. However, unless we abolish the basic premise of copyright (the “right” of a creator to control when, how, and by whom their works are “copied”) altogether, collection agencies as a practical solution to an obvious problem won't be going away anytime soon.

We live in a crazy world

Posted Nov 27, 2024 14:56 UTC (Wed) by jzb (editor, #7867) [Link]

As interesting as global policies on the collection of music royalties might be, it seems we have once again strayed far from the original topic. Let's end this thread, and any similar ones, here please.

Debian

Posted Nov 27, 2024 6:34 UTC (Wed) by pabs (subscriber, #43278) [Link] (2 responses)

Correction: Debian does have a policy on which license is used for the debian/ directory, albeit an informal one; it should use the same license as the upstream project, for compatibility with upstream, which is useful for sending patches, documentation and so on.

Debian

Posted Nov 27, 2024 14:46 UTC (Wed) by jzb (editor, #7867) [Link] (1 responses)

Debian does have a policy on which license is used for the debian/ directory, albeit an informal one

Is it a policy or a convention? If there's an informal convention that people should mirror the same license as the upstream software then that's not actually a policy, but perhaps something considered a best practice. I couldn't find anything that codified it when looking through the Debian Policy Manual—but admittedly it's a bit lengthy and I haven't memorized it or anything...

Debian

Posted Nov 28, 2024 0:40 UTC (Thu) by rra (subscriber, #99804) [Link]

It's a convention, not a policy. I believe the convention is followed pretty widely, but I have seen exceptions (usually in the form of licensing the debian directory under an MIT-style license even though the upstream source is GPL).

Good!

Posted Nov 28, 2024 23:10 UTC (Thu) by intgr (subscriber, #39733) [Link]

Thanks, Arch developers, for taking this step to clarify the licensing mess.

It's not frivolous. Nobody benefits from operating in a legal gray area.

Declaring a license for their repos is the right amount of legalese that most open source projects should be subjected to.