3 ms·

On a tangent , can anyone point me to resources on solving the problem of distributing docker images with oss licensed software inside them?

koolba 3y ago
What’s the problem that’s specific to container images? It’s no different than distributing software binaries that include FOSS.
- totetsu 3y ago
  Sometimes the lower layers of the image fs can have binaries in there that are not used or even accessible to the running container.
  - eichin 3y ago
    They're still accessible by inspect and hash (maybe start with "docker history".) You may find it easier to use that to get enough info to build your own images from scratch, so you have control of what's going in (since you already have responsibility.) "mmdebstrap | docker import" gets you surprisingly far.
withinboredom 3y ago
It’s not a problem per-se. You just have to document them and their license. Whether you actually have to do that is another question since most believe that that would fall on the base image publisher, not the final image. Further, a proper base image will already include licenses in the base image because most OSS licenses require distributing the software with the license available. The only thing you would have to document are the things you specifically added. At least, that’s been my experience.
- totetsu 3y ago
  If the license says I must make the source code available, don’t I also have to have some mechanism to provide that code if asked?
  - withinboredom 3y ago
    Debian based distros (and all the others) have a command to run and get the sources for ALL open source packages installed on the system. So, there is nothing to do there. apt get source package. If someone asks for source code for a library, simple point them to the GitHub repository. This isn’t rocket science and it isn’t worth automating because practically nobody asks for it.
    - zvr 3y ago
      For packages being installed from distributions like Debian, you are correct that doing "apt-get source $pkg=$version" will download the source, so you can do it for every package in the image that you are distributing. On the other hand, if you are using Alpine as a base, things are not so easy.. For GPL-licensed code, you should provide the sources yourself. "Point them to a GitHub repository" is not acceptable, since the repo might disappear or change contents without you noticing. And it is definitely worth automating, if you are releasing at scale (either many products or many versions). Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"
      - withinboredom 3y ago
        > Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?" Generally, this can be solved by simply vendoring your dependencies (aka, commit them to the repository instead of fetching them for every build). > For GPL-licensed code, you should provide the sources yourself. Version 3 of the GPL simply states that "clear directions" on how to find the source code may be given. There's no requirement for you to distribute those sources yourself unless you make modifications and make the software available for sale or download. Internal use/private modifications do not need to be given away. > it is definitely worth automating I worked at a company that dealt in nothing but commercially licensed open source code. That meant we were much more likely to get requests for our source code because it was obvious we were running heavily modified open source software. That being said, despite having millions of users, we only got a few requests a month and we still didn't bother automating it. So, I'm not convinced it is worth automating unless you are in the hundreds of millions of users range.

koolba 3y ago

What’s the problem that’s specific to container images? It’s no different than distributing software binaries that include FOSS.

totetsu 3y ago
Sometimes the lower layers of the image fs can have binaries in there that are not used or even accessible to the running container.
- eichin 3y ago
  They're still accessible by inspect and hash (maybe start with "docker history".) You may find it easier to use that to get enough info to build your own images from scratch, so you have control of what's going in (since you already have responsibility.) "mmdebstrap | docker import" gets you surprisingly far.

withinboredom 3y ago

It’s not a problem per-se. You just have to document them and their license. Whether you actually have to do that is another question since most believe that that would fall on the base image publisher, not the final image. Further, a proper base image will already include licenses in the base image because most OSS licenses require distributing the software with the license available. The only thing you would have to document are the things you specifically added. At least, that’s been my experience.

totetsu 3y ago
If the license says I must make the source code available, don’t I also have to have some mechanism to provide that code if asked?
- withinboredom 3y ago
  Debian based distros (and all the others) have a command to run and get the sources for ALL open source packages installed on the system. So, there is nothing to do there. apt get source package. If someone asks for source code for a library, simple point them to the GitHub repository. This isn’t rocket science and it isn’t worth automating because practically nobody asks for it.
  - zvr 3y ago
    For packages being installed from distributions like Debian, you are correct that doing "apt-get source $pkg=$version" will download the source, so you can do it for every package in the image that you are distributing. On the other hand, if you are using Alpine as a base, things are not so easy.. For GPL-licensed code, you should provide the sources yourself. "Point them to a GitHub repository" is not acceptable, since the repo might disappear or change contents without you noticing. And it is definitely worth automating, if you are releasing at scale (either many products or many versions). Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"
    - withinboredom 3y ago
      > Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?" Generally, this can be solved by simply vendoring your dependencies (aka, commit them to the repository instead of fetching them for every build). > For GPL-licensed code, you should provide the sources yourself. Version 3 of the GPL simply states that "clear directions" on how to find the source code may be given. There's no requirement for you to distribute those sources yourself unless you make modifications and make the software available for sale or download. Internal use/private modifications do not need to be given away. > it is definitely worth automating I worked at a company that dealt in nothing but commercially licensed open source code. That meant we were much more likely to get requests for our source code because it was obvious we were running heavily modified open source software. That being said, despite having millions of users, we only got a few requests a month and we still didn't bother automating it. So, I'm not convinced it is worth automating unless you are in the hundreds of millions of users range.