3 ms·

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.
  - totetsu 3y ago
    Thank you that’s very helpful. I’m also wondering about pip and npm
    - withinboredom 3y ago
      That is specific to the language, but neither Python nor JavaScript is a compiled language, so for the most part, those sources are already distributed. Some of those packages also contain binaries, so it can get dicey. Some may even have an incompatible license, so you have to be careful. At a big company, we (as in the team) had to review any and every library and its dependencies before we could use it, then the security team had to review it. The amount of shit code out there is outstanding; many times we would just reimplement it ourselves, unless the library did something substantial that we didn’t want to maintain. (This is also why zero-dependency libraries are a thing)

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.
- totetsu 3y ago
  Thank you that’s very helpful. I’m also wondering about pip and npm
  - withinboredom 3y ago
    That is specific to the language, but neither Python nor JavaScript is a compiled language, so for the most part, those sources are already distributed. Some of those packages also contain binaries, so it can get dicey. Some may even have an incompatible license, so you have to be careful. At a big company, we (as in the team) had to review any and every library and its dependencies before we could use it, then the security team had to review it. The amount of shit code out there is outstanding; many times we would just reimplement it ourselves, unless the library did something substantial that we didn’t want to maintain. (This is also why zero-dependency libraries are a thing)