9 ms·

If you have the source, it shouldn't be difficult to build binaries, should it? If you are building a new Linux distribution based on Ubuntu, I don't even unde

by pekk 11y ago

If you have the source, it shouldn't be difficult to build binaries, should it? If you are building a new Linux distribution based on Ubuntu, I don't even understand why you would want to reuse binaries they built. This post would be more meaningful if it literally quoted from unfavorable license terms used by Ubuntu to actually prevent people from making derivatives. Saying that Canonical "appears to require" something is using weasel words.

caf 11y ago
The post needs to be read in the context of the series of which it forms a part, eg. http://mjg59.dreamwidth.org/38467.html http://mjg59.dreamwidth.org/38467.html
mjg59 11y ago
> If you have the source, it shouldn't be difficult to build binaries, should it? You'd think, but no - there's no guarantee that the shipped binary packages can be built with the shipped toolchain or shipped dependencies. > If you are building a new Linux distribution based on Ubuntu, I don't even understand why you would want to reuse binaries they built. Because it's entirely unnecessary? Building the entire archive is a huge amount of effort. > This post would be more meaningful if it literally quoted from unfavorable license terms used by Ubuntu to actually prevent people from making derivatives. Saying that Canonical "appears to require" something is using weasel words. The terms are at http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy http://www.ubuntu.com/legal/terms-and-policies/intellectual-... - I probably should have linked them, I've just been writing about this enough lately that it's easy to forget that people might read a single post without context.
- lmm 11y ago
  > You'd think, but no - there's no guarantee that the shipped binary packages can be built with the shipped toolchain or shipped dependencies. If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation (and a far more serious one than any possible ZFS issue, and one that you're in a position to do something about as a copyright holder). If the shipped source doesn't include whatever their developers actually use to build (and I refuse to believe an organization like Ubuntu wouldn't have a unified "build it all" script, or at least a README that described the steps you needed to take) then how can it possibly be the preferred form for making modifications?
  - ghaff 11y ago
    >If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation Why would it be? Build and testing systems for something like a Linux distribution are far more complex systems than a simple script. In any case, there's no requirement in the GPL (or any other OSI-approved license AFAIK) to include components outside of the software itself to simplify building and installing. Of course, there are a variety of things like package managers that do simplify the process but there's no requirement in the GPL that it be straightforward to install from sources.
    - lmm 11y ago
      The requirement is to ship the source in the preferred form for making modifications. That doesn't include standardized external tools, but it surely includes the build instructions (with things like which versions of the tools to use) and test suite (and indeed git history - mjg59 has disagreed with me regarding that before, but I don't think he gave a rationale) - those are things you'd definitely want to have for making modifications.
  - majewsky 11y ago
    There are scripts for building each package individually, and these scripts list other packages that are required for the build process. There is nothing to enforce the requirement that the build requirements are a subset of the packages built, or even correlated to them.
  - mjg59 11y ago
    > If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation Package A's source code contains some undefined behaviour that gcc 4.4 tolerates. The distribution upgrades to gcc 5.1 and the build now breaks, but nobody notices because no new version of Package A has been uploaded and so no new build has been performed. Is your position that it was in compliance with the GPL before the gcc transition, and in violation afterwards?
    - 11y ago
- ryao 11y ago
  > there's no guarantee that the shipped binary packages can be built with the shipped toolchain or shipped dependencies. That problem will be with us as long as we use binaries as the primary means of distribution. If you consider that to be a problem, you could put effort into distributions where the packaging is the source code. I know I do. > Because it's entirely unnecessary? Building the entire archive is a huge amount of effort. How do you know that the source code provided actually corresponds to the binaries unless you compile them yourself[ with a toolchain you compiled yourself [...]]? > The terms are at http://www.ubuntu.com/legal/terms-and-policies/intellectual-.. http://www.ubuntu.com/legal/terms-and-policies/intellectual-.... - I probably should have linked them, I've just been writing about this enough lately that it's easy to forget that people might read a single post without context. No company's policies are perfect. You might be more effective trying to deal with the overall distribution of how software is done rather than imperfections in community leaders. There is a point of diminishing returns in focusing on a small subset of the companies out there while completely ignoring the rest.
  - wantreprenr007 11y ago
    Reproducibility from source and build env are fundamental to science or making changes to improve something. Without these, it can appear to signal hoarded proprietariness waving the banner of FLOSS or just a poorly-maintained project without high standards, even if it were unintentional.
    - ryao 11y ago
      > Reproducibility from source and build env are fundamental to science or making changes to improve something. Without these, it can appear to signal hoarded proprietariness waving the banner of FLOSS or just a poorly-maintained project without high standards, even if it were unintentional. I am typing this on a system running Gentoo that has only 3 proprietary packages installed, with one being Intel's microcode. In time, I hope to lower that number to zero. If you are concerned about this and do not run a source-based distribution, I suggest that you switch.
      - 11y ago
- vacri 11y ago
  mjg59: when you link to a Shuttleworth comment as a 'flat refusal', and that comment is actually a statement of position and procedure to achieve your general aims (if not your specific ones), but finally ends with a paragraph stating that you misrepresent what Shuttleworth says, it's hard not to believe him.
- deleted 11y ago
  [deleted]

by pekk 11y ago

caf 11y ago

The post needs to be read in the context of the series of which it forms a part, eg. http://mjg59.dreamwidth.org/38467.html http://mjg59.dreamwidth.org/38467.html

mjg59 11y ago

> If you have the source, it shouldn't be difficult to build binaries, should it? You'd think, but no - there's no guarantee that the shipped binary packages can be built with the shipped toolchain or shipped dependencies. > If you are building a new Linux distribution based on Ubuntu, I don't even understand why you would want to reuse binaries they built. Because it's entirely unnecessary? Building the entire archive is a huge amount of effort. > This post would be more meaningful if it literally quoted from unfavorable license terms used by Ubuntu to actually prevent people from making derivatives. Saying that Canonical "appears to require" something is using weasel words. The terms are at http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy http://www.ubuntu.com/legal/terms-and-policies/intellectual-... - I probably should have linked them, I've just been writing about this enough lately that it's easy to forget that people might read a single post without context.

lmm 11y ago
> You'd think, but no - there's no guarantee that the shipped binary packages can be built with the shipped toolchain or shipped dependencies. If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation (and a far more serious one than any possible ZFS issue, and one that you're in a position to do something about as a copyright holder). If the shipped source doesn't include whatever their developers actually use to build (and I refuse to believe an organization like Ubuntu wouldn't have a unified "build it all" script, or at least a README that described the steps you needed to take) then how can it possibly be the preferred form for making modifications?
- ghaff 11y ago
  >If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation Why would it be? Build and testing systems for something like a Linux distribution are far more complex systems than a simple script. In any case, there's no requirement in the GPL (or any other OSI-approved license AFAIK) to include components outside of the software itself to simplify building and installing. Of course, there are a variety of things like package managers that do simplify the process but there's no requirement in the GPL that it be straightforward to install from sources.
  - lmm 11y ago
    The requirement is to ship the source in the preferred form for making modifications. That doesn't include standardized external tools, but it surely includes the build instructions (with things like which versions of the tools to use) and test suite (and indeed git history - mjg59 has disagreed with me regarding that before, but I don't think he gave a rationale) - those are things you'd definitely want to have for making modifications.
- majewsky 11y ago
  There are scripts for building each package individually, and these scripts list other packages that are required for the build process. There is nothing to enforce the requirement that the build requirements are a subset of the packages built, or even correlated to them.
- mjg59 11y ago
  > If the shipped source doesn't contain enough information to actually perform a build surely that's a straight-up GPL violation Package A's source code contains some undefined behaviour that gcc 4.4 tolerates. The distribution upgrades to gcc 5.1 and the build now breaks, but nobody notices because no new version of Package A has been uploaded and so no new build has been performed. Is your position that it was in compliance with the GPL before the gcc transition, and in violation afterwards?
  - 11y ago
ryao 11y ago
> there's no guarantee that the shipped binary packages can be built with the shipped toolchain or shipped dependencies. That problem will be with us as long as we use binaries as the primary means of distribution. If you consider that to be a problem, you could put effort into distributions where the packaging is the source code. I know I do. > Because it's entirely unnecessary? Building the entire archive is a huge amount of effort. How do you know that the source code provided actually corresponds to the binaries unless you compile them yourself[ with a toolchain you compiled yourself [...]]? > The terms are at http://www.ubuntu.com/legal/terms-and-policies/intellectual-.. http://www.ubuntu.com/legal/terms-and-policies/intellectual-.... - I probably should have linked them, I've just been writing about this enough lately that it's easy to forget that people might read a single post without context. No company's policies are perfect. You might be more effective trying to deal with the overall distribution of how software is done rather than imperfections in community leaders. There is a point of diminishing returns in focusing on a small subset of the companies out there while completely ignoring the rest.
- wantreprenr007 11y ago
  Reproducibility from source and build env are fundamental to science or making changes to improve something. Without these, it can appear to signal hoarded proprietariness waving the banner of FLOSS or just a poorly-maintained project without high standards, even if it were unintentional.
  - ryao 11y ago
    > Reproducibility from source and build env are fundamental to science or making changes to improve something. Without these, it can appear to signal hoarded proprietariness waving the banner of FLOSS or just a poorly-maintained project without high standards, even if it were unintentional. I am typing this on a system running Gentoo that has only 3 proprietary packages installed, with one being Intel's microcode. In time, I hope to lower that number to zero. If you are concerned about this and do not run a source-based distribution, I suggest that you switch.
    - 11y ago
vacri 11y ago
mjg59: when you link to a Shuttleworth comment as a 'flat refusal', and that comment is actually a statement of position and procedure to achieve your general aims (if not your specific ones), but finally ends with a paragraph stating that you misrepresent what Shuttleworth says, it's hard not to believe him.
deleted 11y ago
[deleted]