3

Looking at https://pkgs.alpinelinux.org/packages, almost every single package in Alpine Linux is versioned as a.b.c-rd where a b c d are numbers, d is the "patch release" of the version a.b.c.

As the name implies, I suppose the patch release is a bug or security fix.

What about the licensing of the package? Is it possible that the license of a package is changing within a patch release, or can we ensure that the license is always the same within for a fixed a.b.c version, whatever d is?

Background is legal compliance: when we deliver a software based on Alpine Linux (delivered as Docker container), we need to ensure that the license of every single component is properly defined and delivered with our software.
But "clearing" a component requires getting the source code, and is always time consuming. I see here how to get the exact source code of a package, but this is much more complex that getting just the tag of the related GitHub repository.

So for compliance purposes, if the license remains the same, I would like to take any package of version a.b.c and ignore the release patch. What do you think?

Improve this question

1 Answer 1

Reset to default
6

Version numbers are, at best, a social contract between developers, packagers, and end users. You should not assume that version numbers will satisfy SemVer with respect to legal aspects like licensing. Alpine Linux does document policies on package names, version numbers, and licensing, but these are too flexible to be useful for you.

You should not assume that version numbers have any general meaning at all, other than maybe that they are a monotonically increasing sequence. I notice that there are Alpine packages including software I wrote, and the Alpine packagers did not reach out to me to check what I mean by the version numbers I chose.

However, if you are concerned about unexpected license changes, you may be able to write scripts that detect such changes. For example, you could extract the license field from the APKBUILD file, though this is just package metadata and not the actual license. Packagers too are only human, and might fail to notice when this metadata has to be updated.

If you want an easier time with Open Source license compliance, I would humbly suggest choosing a Linux distro with more thorough processes. Don't get me wrong, the Alpine project is great, but the Debian community cares a lot about proper licensing, and has built-in mechanisms for distributing licenses and source code for packages. Ultimately, this is a business decision for you how much you care about container image size, license compliance, and the effort necessary to achieve those.

Improve this answer
11
  • 1
    Not exactly a version number but I do have packages on my systems with versions like 2020Jun07, 1.9beta6, or 0.071220.c. These will not monotonically increase. They are not packages included in any distribution but are scientific packages. From a real distribution (OEL8) I see versions 4.999.9-23.beta.20220509git, 1.0.1-0.8.git5baa1e5, and 1.8.B59BrZX-8. Yes, version strings cannot be assumed to have real meaning.
    – doneal24
    Feb 22 at 21:48
  • thanks for your answer. I was expecting something like that... I remember another thread about SemVer vs License: the license is 'orthogonal' (and Independent) to the version so that the version does not tell anything about the license. Still, I wish the open source community is increasing a version fix for any license change: having so in the SemVer 'best practices' will help many businesses.
    – EricBDev
    Feb 23 at 9:46
  • Anyway, after discussing internally, we will go with my suggested approach, taking the 'risk' of such a version change, but hoping the Alpine-Linux community did not change any license in a patch release.
    – EricBDev
    Feb 23 at 9:46
  • as for Alpine vs Debian, we chose Debian-slim in another team whose docker images are delivered on a computer, but went with Alpine here because our docker images are delivered on a IoT device where size still matters: Alpine base image are simply smaller. If the size difference fade when we start adding many packages, we try to keep them as small as possible.
    – EricBDev
    Feb 23 at 9:48
  • 3
    In between, I also received an answer from the alpine community where I asked the same question in their user mailing list. Konstantin K. 's answer confirms yours, amon: "revbumps can alter package build options. New options can pull new dependencies. New deps can bring new licenses. As for fetching sources - if you find working with APKBUILDS too hard, pkgs.a.o has links to build logs for every package, maybe parsing such logs will be easier?" So yes, working with APKBUILDS or their logs will be the proper way, but we'll start with the shortcut proposal.
    – EricBDev
    Feb 23 at 10:52

Your Answer

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

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