4 ms·

(N.B.: I'm on the Debian ftpmaster team, which reviews all new software in Debian to ensure it matches our policies and commitments) > Does GPL say anything ab

by lwf 9y ago

(N.B.: I'm on the Debian ftpmaster team, which reviews all new software in Debian to ensure it matches our policies and commitments) > Does GPL say anything about distributing source via git repositories? Nope. > I mean, it talks about "preferred form of the work for making modifications". This is generally interpreted as a fancy way of saying "source code" — e.g. a minified JavaScript program or something that could be decompiled isn't the "preferred form… for making modifications". Source for all Debian packages can be retrieved via `apt-get source PACKAGE`, and via sources.debian.org[3]. Historically, the only hard requirement was that all patches be made available as a `.diff.gz` applied against the upstream, although for many years packages have since standardised on using `quilt`[2]. Some maintainers may also use git (and wrappers around it) to make things easier to manage, but quilt is sufficiently straightforward to work with that it's acceptable for most purposes. The VCS page on the BTS points to the repository for the package. It contains an unreleased version (1.3.3-5), the security update only is a patch on the previous version released in Debian. The last upstream release was 1.3 (2010), available on GitHub[1]. This is a Debian-specific patch against beep. We'd like all patches to make it upstream, and ensure maximum clarity, but we have limited time, and our first priority is the users of Debian. Sometimes, upstreams lose time, or there are coordination issues that prevent it. (not saying that's the case here) [1]: http://github.com/johnath/beep/ http://github.com/johnath/beep/ [2]: https://wiki.debian.org/UsingQuilt https://wiki.debian.org/UsingQuilt [3]: https://sources.debian.org/src/beep/unstable/ https://sources.debian.org/src/beep/unstable/

jwilk 9y ago
> Source for all Debian packages can be retrieved via `apt-get source PACKAGE`, and via sources.debian.org But sources.d.o seem to lack security updates (or at least the security update for this package is missing). :-\
0x0 9y ago
Thanks for your detailed reply. I'm still curious about the general case of GPL and Git. If I were to hack on some GPL-licensed software, my "preferred form of the work for making modifications" would hands-down be a .git repository, because all the individual git commits and commitmsgs are important (meta-)information, almost as important as the source code files themselves. It also makes collaborating on improvements much easier when you can work on git commit objects, with their parent(s) commit hash references. Without those, determining where and if a .patch should be applied to a source code dump becomes much harder. In other words, if there exists a .git repository for a given piece of software, and all one gets is a .tar.gz flat source dump snapshot, I feel like... something has been left out?
- lwf 9y ago
  This came up when RedHat stopped breaking out their patches against the Linux kernel: https://lwn.net/Articles/432012/ https://lwn.net/Articles/432012/ Relevant parts quoted: > While there can certainly be arguments about what "preferred form" means for source code distributions, Red Hat's actions here don't seem very close to the line. The basic idea is that the code be released in digital form, along with any build scripts, so that downstream developers can reproduce the GPL-covered binary that is being shipped. It is partly meant to prevent recalcitrant vendors from releasing the source on paper—or stamped into clay tablets in cuneiform. One could argue that those methods do provide the source code, but it certainly isn't in a form preferred by anyone—nor does it adhere to the "medium customarily used for software interchange" requirement. > Obfuscated source code, where all the variables and function names get turned into unintelligible gibberish, or the source is deliberately split up in ways that are harder to work with, are a bit more of a gray area—but not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing. > The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement. Tarball releases of GPL code are a longstanding tradition in the free software world. Many projects still do it that way and the FSF itself has made releases that way in the past. While it is nice to get some visibility into the version control system of a project, it certainly isn't required for GPL compliance. No one complained that Red Hat didn't provide access to its Git repositories back when it was still providing the broken-out patches, for example. A Git repository is definitely the preferred form for Red Hat developers to use, but there are lots of reasons that the company might want to keep its repositories to itself—something that is obviously within its rights.

by lwf 9y ago

jwilk 9y ago

> Source for all Debian packages can be retrieved via `apt-get source PACKAGE`, and via sources.debian.org But sources.d.o seem to lack security updates (or at least the security update for this package is missing). :-\

0x0 9y ago

Thanks for your detailed reply. I'm still curious about the general case of GPL and Git. If I were to hack on some GPL-licensed software, my "preferred form of the work for making modifications" would hands-down be a .git repository, because all the individual git commits and commitmsgs are important (meta-)information, almost as important as the source code files themselves. It also makes collaborating on improvements much easier when you can work on git commit objects, with their parent(s) commit hash references. Without those, determining where and if a .patch should be applied to a source code dump becomes much harder. In other words, if there exists a .git repository for a given piece of software, and all one gets is a .tar.gz flat source dump snapshot, I feel like... something has been left out?

lwf 9y ago
This came up when RedHat stopped breaking out their patches against the Linux kernel: https://lwn.net/Articles/432012/ https://lwn.net/Articles/432012/ Relevant parts quoted: > While there can certainly be arguments about what "preferred form" means for source code distributions, Red Hat's actions here don't seem very close to the line. The basic idea is that the code be released in digital form, along with any build scripts, so that downstream developers can reproduce the GPL-covered binary that is being shipped. It is partly meant to prevent recalcitrant vendors from releasing the source on paper—or stamped into clay tablets in cuneiform. One could argue that those methods do provide the source code, but it certainly isn't in a form preferred by anyone—nor does it adhere to the "medium customarily used for software interchange" requirement. > Obfuscated source code, where all the variables and function names get turned into unintelligible gibberish, or the source is deliberately split up in ways that are harder to work with, are a bit more of a gray area—but not much. Those kinds of actions should be seen as clear attempts to circumvent the GPL requirements. But that's not at all what Red Hat is doing. > The tarball that Red Hat is releasing may not be the preferred form for the Red Hat kernel developers to use, but that is not part of the requirement. Tarball releases of GPL code are a longstanding tradition in the free software world. Many projects still do it that way and the FSF itself has made releases that way in the past. While it is nice to get some visibility into the version control system of a project, it certainly isn't required for GPL compliance. No one complained that Red Hat didn't provide access to its Git repositories back when it was still providing the broken-out patches, for example. A Git repository is definitely the preferred form for Red Hat developers to use, but there are lots of reasons that the company might want to keep its repositories to itself—something that is obviously within its rights.