Zfs: ZFS on Linux code hosting currently fails GNU Ethical Repository Criteria Evaluations

[sampablokuper]

ZFS on Linux currently hosts its public code repository, wiki, and bug tracker with GitHub, which fails the GNU Ethical Repository Criteria Evaluations and has serious licensing concerns.

Please could ZFS on Linux move its repo, wiki, and bug tracker to a host that does not suffer from those problems? The github-backup tool may help :)

As for which host to choose that is free from those problems, options include:

• GitLab
• NotABug
• GNU Savannah

Thanks!

[ryao]

@sampablokuper Thanks for the report. However, I do not see any support for the allegations about licensing that you cite. If they were true, I'd imagine the FSF would list them on their site, but they do not. What they do list seems minor. I am not the project lead, so my opinion is just that of a contributor, but I do not see an actionable problem here.

[jwittlincohen]

@sampablokuper The only significant issue you raise is the licensing concern. However, a brief review of the Github ToS fails to support the claims made in your link. The ToS explicitly respects the license chosen by the contributor, except to the extent needed to display information and operate the site. Can you please cite the specific section of the ToS that you believe undermines Copyleft licenses? This is a rather bold claim, and from what I can see, is not supported in any way. (FYI, I am a lawyer.)

[gmelikov]

I agree with @ryao, @kpande and @jwittlincohen , my personal opinion - we don't have any gain to change anything.

[sampablokuper]

@ryao , @kpande , @jwittlincohen , @gmelikov,

Thanks for your replies.

Re: Ethical Repository Criteria. To be clear, I am not suggesting that ZFS on Linux is a GNU project or that ZFS on Linux has to follow Free Software Foundation guidelines. However, ZFS on Linux is a free software project, and it would be nice if it used free software infrastructure. It is particularly galling how much GitHub interaction requires proprietary JavaScript. This situation seems unlikely to improve.

Re: GitHub ToS, IANAL. In any case, whether it undermines copyleft would be up to a court to decide. It is a risk, not a certainty. Because it is an avoidable risk, avoiding it seems worthwhile. (Also, avoiding it by using an ethical repository host would be a double win.) Whether to agree with me about this is a matter of opinion. For an in-depth discussion of the ToS, see here and here.

Thanks again :)

[ryao]

I suggest that you get in touch with actual attorneys such as those at the SFLC regarding your copyleft concerns. They do this sort of analysis pro-bono. If there were a problem with github.com's ToS, I would have expected them to talk about it. I could ask them for their opinion, but given that I see no reason for concern, I see no reason for me to ask. You could ask them if you are concerned.

As for the javascript being proprietary, I imagine the HTML is proprietary too. I do not see a problem with this. Unlike typical proprietary software, Javascript is visible source and can be audited for security. Whether portions of their website can be reused by others is not relevant to an open source project developing something entirely different. I am happy to treat it as a black box much like I treat the microprocessor in my computer.

[jwittlincohen]

@sampablokuper

Thanks for the links. Your second link is illuminating. It appears that the FSF has had its lawyers review the ToS and their conclusion was that, "GitHub's updated terms caused a great deal of concern, but while they are confusing, they do not appear to be incompatible with copyleft.". While the FSF encourages using another provider, they don't do so for licensing concerns. From what I can tell, the other link was not drafted by a lawyer and appears speculative. My own opinion aligns with FSF's conclusion, although I don't find the ToS particularly confusing either.

[sampablokuper]

@ryao wrote:

As for the javascript being proprietary [...] I do not see a problem with this.

You might not, but others do: https://fsf.org/campaigns/freejs .

Javascript is visible source and can be audited for security.

GitHub's JavaScript, like much proprietary JavaScript, is minified (obfuscated). Examples: 1, 2. Auditing it for security would require similar techniques to auditing other proprietary software for security, i.e. reverse-engineering. It would very likely be more labour-intensive than auditing comparable free software.

Whether portions of their website can be reused by others is not relevant to an open source project developing something entirely different.

There are at least two ways in which it could be relevant:

1. All but the most casual users of the ZFS on Linux infrastructure are likely to have an interest and an investment in free software (why else would they be interested in ZFS on Linux?). It is perverse to require ZFS on Linux users and contributors to use proprietary infrastructure, and could discourage contributions from people who would otherwise be keen.

2. GitHub's proprietary nature means that if, for any reason, ZFS on Linux wishes to migrate to a different host in the future, this will require more effort than it would if the host used free software such as Gogs or GitLab CE. You can't just spin up a new, freely-licensed GitHub instance somewhere else ;)

[ryao]

@sampablokuper I imagine the minified version is used to speed up load times. I would suggest asking github to provide both copies for review.

With regard to your other points:

1. Thus far, no contributors have complained and users tend to get things from their distributions. There does not seem to be any outcry against github from users in general. If that changes, we can revisit this.

2. Our interface is git. We can just git push elsewhere. Taking github's infrastructure with us isn't important. Also, encapsulating everything into a VM kind of negates the ability to do HA.

That being said, it is not my call to make. It is @behlendorf's call. My only contribution here is my opinion.

[behlendorf]

@sampablokuper thanks for bringing up your concerns. For the moment GitHub is meeting the needs of this project and transitioning to a new host would be unnecessarily disruptive. If that changes I'd consider migrating the project, but until then this project will continue to be hosted at GitHub.

[sampablokuper]

@behlendorf, fair enough :) Meeting the project's needs is indeed the main concern. The concerns I raised are (IMO) reasonable, but I can see why you view them as them subsidiary.

Good to know that you have reflected on the matter, and that you would consider migrating if needs be. Thanks :)