3 ms·

The GNU project did an evaluation of code hosting providers recently[1]. GitHub got an F (and note that 'server code is free software' is only a requirement for

by cyphar 9y ago

The GNU project did an evaluation of code hosting providers recently[1]. GitHub got an F (and note that 'server code is free software' is only a requirement for an A grade). GitLab only got a C. There are more severe problems than just "is the server free software". Also please note that neither GNU nor the FSF really care about new fads. Their main concern is software freedom, and much like the whole convenience-security tradeoff there is a freedom-convenience tradeoff too. The FSF and GNU project do not compromise on freedom. [1]: https://www.gnu.org/software/repo-criteria-evaluation.en.html https://www.gnu.org/software/repo-criteria-evaluation.en.htm...

sametmax 9y ago
You don't have to compromise, you just have to evaluate. What could go wrong ? In this case, the worst thing that can happen is that you have to get your data and move, which are both easy to do. So what you can do is: - create a git lab instance as a synchronized unused backup that doesn't require a lot of maintenance to work. - use github as the main dev plateform. - then if (and it's a biiiiiig if) something ever go wrong, you switch The benefits are huge : - much less work work for the GNU and FSF; - much more reliable plateform. If you get hit by a massive traffic, your gitlab instance is less likely to hold than github; - much more visibility; - much less friction. It's a win-win. It's not about fad. It's about being practical. You can fight for your freedom without rejecting everything closed source. We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery labor in China. Which they all are. Spend your energy wisely instead of living a dogma.
- cyphar 9y ago
  > What could go wrong? The GNU project would be promoting proprietary software by requiring free software developers to use proprietary software. As there exist free alternatives, such promotion would negatively impact the free software movement (people would say "why not use GitHub? GNU decided that it was okay!"). That is enough of a reason to discount proprietary services. It's that simple. > much more visibility; ... for GitHub as well. Which is one of the main issues. > We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery[sic] labor in China. Which they all are. Non-sequitur. "X is bad, so why are you caring about Y (which is less bad)".
  - sametmax 9y ago
    That's actually a much better reason that what's been used before. As for non sequitur, it's not. There is no moral comparison, i'm just saying that practicality beats purity and that we all do it so advocating purity is defintly not credible.
    - cyphar 9y ago
      > i'm just saying that practicality beats purity and that we all do it so advocating purity is definitely not credible This is like arguing that a member of the Vegeterian Foundation should buy chicken rather than chick-peas because chicken is easier to cook. Or because the chick-peas are being produced using animal fertilizers. There are many criteria by which you can evaluate software. Usability is one of them. Software freedom is another. The GNU project proritises the latter over the former. More importantly it's got nothing to do with "purity". I really don't understand how people are surprised that the Free Software Foundation prioritises Free Software as a criteria over anything else.
      - sametmax 9y ago
        No that's fair enough.
jrimbault 9y ago
This is only a moral/ethical evaluation done by the GNU project. It doesn't inform on the actual quality of the products. And of course Savannah would come first, since they're the one judging themselves according to ethical standards they decided themselves. Judge and jury with an after taste of self-interests.
- cyphar 9y ago
  > This is only a moral/ethical evaluation done by the GNU project. And GNOME is part of the GNU project... > And of course Savannah would come first There's no reason why GitLab could not also get an A rating, aside from friction from GitLab themselves.
  - mikegerwitz 9y ago
    GitLab has been very receptive to many recommendations. There's discussion (stalled) here: https://gitlab.com/gitlab-org/gitlab-ce/issues/15678 https://gitlab.com/gitlab-org/gitlab-ce/issues/15678 More discussion can be found in the archives: https://lists.gnu.org/archive/html/repo-criteria-discuss/ https://lists.gnu.org/archive/html/repo-criteria-discuss/
    - cyphar 9y ago
      > GitLab has been very receptive to many recommendations. I never said it wasn't, I was just saying that the only meaningful blocker is on GitLab's side (though as you've mentioned in that thread there is some discussion on refining the requirements). > There's discussion (stalled) here: Emphasis on "stalled". ;)
      - mikegerwitz 9y ago
        > I never said it wasn't I was just praising them, not disagreeing with you. :)
  - jrimbault 9y ago
    No reason apart from the fact that the ones judging are the ones setting up the rules for judgment and have a horse in the race. And still, it doesn't get to the heart of the issue, we're not comparing ethical viewpoints here, we're asserting product quality from a user standpoint.
deadbunny 9y ago
> There are more severe problems than just "is the server free software". Nonsense. They have 2 reasons for it getting an F rating. > 1. Important site functionality does not work without running nonfree JavaScript. (C0) Contradicts what you say. > 2. Specific information may not be available in all countries Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments. > see roskomnadzor[1] This was blocked by the Russian .gov, nothing to do with GitHub > and export controls[2] for more details. They are a US company hosted with a US provider complying with US laws on exporting controlled data. So to counter your point one issue is because they're using non free software, one reason is out of their control, and the other is following the law of the land they are doing business in. If this is a fail in the FSF then that's fine, claiming they have "more severe problems than not running free software" is disingenuous. 1. https://github.com/github/roskomnadzor/blob/master/2014-10-21-roskomnadzor.md https://github.com/github/roskomnadzor/blob/master/2014-10-2... 2. https://help.github.com/articles/github-and-export-controls/ https://help.github.com/articles/github-and-export-controls/
- cyphar 9y ago
  > > 1. Important site functionality does not work without running nonfree JavaScript. (C0) > Contradicts what you say. ... no it doesn't. GitHub has server code and has JavaScript code that is sent to the client for the client to execute on the user's machine. This requirement is referring to the client code not the server code. The former is more of a matter of user freedom than the latter. More importantly this requirement doesn't even require GitHub to make their JavaScript free, they just have to make their site work with JavaScript disabled. I'm not sure how you could possibly read the requirement as saying "all server code that GitHub has must be free software"... > Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments. GitLab doesn't get a ding for this requirement, so clearly this statement may be true but it doesn't seem like you are required to act the way GitHub does by law. > So to counter your point one issue is because they're using non free software, one reason is out of their control They have written proprietary software and sell it. I admit that it's hard to fix this problem if you already have proprietary code (contractors retain copyright in some cases), but pretending like they were completely at the mercy of someone else is ridiculous.
arunc 9y ago
Wondering how they missed Kallithea (a software conservancy project) and RhodeCode in their evaluation. Everyone's mind is just clouded by GitHub/GitLab these days.

by cyphar 9y ago

sametmax 9y ago

You don't have to compromise, you just have to evaluate. What could go wrong ? In this case, the worst thing that can happen is that you have to get your data and move, which are both easy to do. So what you can do is: - create a git lab instance as a synchronized unused backup that doesn't require a lot of maintenance to work. - use github as the main dev plateform. - then if (and it's a biiiiiig if) something ever go wrong, you switch The benefits are huge : - much less work work for the GNU and FSF; - much more reliable plateform. If you get hit by a massive traffic, your gitlab instance is less likely to hold than github; - much more visibility; - much less friction. It's a win-win. It's not about fad. It's about being practical. You can fight for your freedom without rejecting everything closed source. We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery labor in China. Which they all are. Spend your energy wisely instead of living a dogma.

cyphar 9y ago
> What could go wrong? The GNU project would be promoting proprietary software by requiring free software developers to use proprietary software. As there exist free alternatives, such promotion would negatively impact the free software movement (people would say "why not use GitHub? GNU decided that it was okay!"). That is enough of a reason to discount proprietary services. It's that simple. > much more visibility; ... for GitHub as well. Which is one of the main issues. > We are all against slavery, but I don't see anybody on HN refusing to post a comment here because their laptop is being build by slavery[sic] labor in China. Which they all are. Non-sequitur. "X is bad, so why are you caring about Y (which is less bad)".
- sametmax 9y ago
  That's actually a much better reason that what's been used before. As for non sequitur, it's not. There is no moral comparison, i'm just saying that practicality beats purity and that we all do it so advocating purity is defintly not credible.
  - cyphar 9y ago
    > i'm just saying that practicality beats purity and that we all do it so advocating purity is definitely not credible This is like arguing that a member of the Vegeterian Foundation should buy chicken rather than chick-peas because chicken is easier to cook. Or because the chick-peas are being produced using animal fertilizers. There are many criteria by which you can evaluate software. Usability is one of them. Software freedom is another. The GNU project proritises the latter over the former. More importantly it's got nothing to do with "purity". I really don't understand how people are surprised that the Free Software Foundation prioritises Free Software as a criteria over anything else.
    - sametmax 9y ago
      No that's fair enough.

jrimbault 9y ago

This is only a moral/ethical evaluation done by the GNU project. It doesn't inform on the actual quality of the products. And of course Savannah would come first, since they're the one judging themselves according to ethical standards they decided themselves. Judge and jury with an after taste of self-interests.

cyphar 9y ago
> This is only a moral/ethical evaluation done by the GNU project. And GNOME is part of the GNU project... > And of course Savannah would come first There's no reason why GitLab could not also get an A rating, aside from friction from GitLab themselves.
- mikegerwitz 9y ago
  GitLab has been very receptive to many recommendations. There's discussion (stalled) here: https://gitlab.com/gitlab-org/gitlab-ce/issues/15678 https://gitlab.com/gitlab-org/gitlab-ce/issues/15678 More discussion can be found in the archives: https://lists.gnu.org/archive/html/repo-criteria-discuss/ https://lists.gnu.org/archive/html/repo-criteria-discuss/
  - cyphar 9y ago
    > GitLab has been very receptive to many recommendations. I never said it wasn't, I was just saying that the only meaningful blocker is on GitLab's side (though as you've mentioned in that thread there is some discussion on refining the requirements). > There's discussion (stalled) here: Emphasis on "stalled". ;)
    - mikegerwitz 9y ago
      > I never said it wasn't I was just praising them, not disagreeing with you. :)
- jrimbault 9y ago
  No reason apart from the fact that the ones judging are the ones setting up the rules for judgment and have a horse in the race. And still, it doesn't get to the heart of the issue, we're not comparing ethical viewpoints here, we're asserting product quality from a user standpoint.

deadbunny 9y ago

> There are more severe problems than just "is the server free software". Nonsense. They have 2 reasons for it getting an F rating. > 1. Important site functionality does not work without running nonfree JavaScript. (C0) Contradicts what you say. > 2. Specific information may not be available in all countries Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments. > see roskomnadzor[1] This was blocked by the Russian .gov, nothing to do with GitHub > and export controls[2] for more details. They are a US company hosted with a US provider complying with US laws on exporting controlled data. So to counter your point one issue is because they're using non free software, one reason is out of their control, and the other is following the law of the land they are doing business in. If this is a fail in the FSF then that's fine, claiming they have "more severe problems than not running free software" is disingenuous. 1. https://github.com/github/roskomnadzor/blob/master/2014-10-21-roskomnadzor.md https://github.com/github/roskomnadzor/blob/master/2014-10-2... 2. https://help.github.com/articles/github-and-export-controls/ https://help.github.com/articles/github-and-export-controls/

cyphar 9y ago
> > 1. Important site functionality does not work without running nonfree JavaScript. (C0) > Contradicts what you say. ... no it doesn't. GitHub has server code and has JavaScript code that is sent to the client for the client to execute on the user's machine. This requirement is referring to the client code not the server code. The former is more of a matter of user freedom than the latter. More importantly this requirement doesn't even require GitHub to make their JavaScript free, they just have to make their site work with JavaScript disabled. I'm not sure how you could possibly read the requirement as saying "all server code that GitHub has must be free software"... > Both are abiding by laws restricting access to that content. If you have an issue with that perhaps talk to the relevant governments. GitLab doesn't get a ding for this requirement, so clearly this statement may be true but it doesn't seem like you are required to act the way GitHub does by law. > So to counter your point one issue is because they're using non free software, one reason is out of their control They have written proprietary software and sell it. I admit that it's hard to fix this problem if you already have proprietary code (contractors retain copyright in some cases), but pretending like they were completely at the mercy of someone else is ridiculous.

arunc 9y ago

Wondering how they missed Kallithea (a software conservancy project) and RhodeCode in their evaluation. Everyone's mind is just clouded by GitHub/GitLab these days.