[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ethical repository evaluation of SourceHut
Re: Ethical repository evaluation of SourceHut
Fri, 24 Jan 2020 10:51:46 -0500
On Thu Jan 23, 2020 at 4:38 PM, Aaron Wolf wrote:
> If simply blocking Stripe doesn't interfere with the use of SourceHut by
> GNU and other free software projects, then it could be seen as not "an
> important site function".
> I'm sure that GNU will accept that interpretation (SourceHut with no
> Stripe) rather than grant any exception to the non-free Stripe JS.
Let me clarify the specifics.
SourceHut will eventually require mandatory payment for service from
project owners, but NOT from contributors. You will be able to make an
account to contribute to projects without submitting payment and thus
without going through Stripe, but payment will be required for repo
ownership, mailing list ownership, etc. The reasoning is to set up a
system of incentives which keeps SourceHut accountable to users, not
However, there are a couple of alternatives. One is that I simply
sponsor free accounts for users who are unable to pay for some reason -
they're subsidized by the rest of the userbase. This is used for
students, people in low-income situations, people in countries where
Stripe is not supported, etc. I also occasionally sponsor important free
software projects, to give back to the community. I have also accepted
payment in cash, in person, where a face-to-face meeting is possible.
Additionally, for third-party instances of SourceHut, you can simply
turn off billing entirely and all accounts will receive all services
administration to decide.
> A) step in the right direction (but not fully ideal in GNU terms): make
> sure to sandbox the Stripe JS and provide a disclaimer. That's what
> Snowdrift.coop currently does. So, acknowledging the problem and
> apologizing is a step in the right direction. Making sure the JS only
> loads where absolutely necessary for the function helps too.
Aye, there should be a better disclaimer. I've added this warning just
> B) do the handling of payment info on the server side, passing to Stripe
> through their API without using the client-side JS. That's what
> CrowdSupply does, and that's the approach that can get full GNU
> endorsement. This takes more hassle and some liabilities, but it's
> doable. It doesn't require SourceHut to actually store any payment info,
> so it's not that level of liability. Incidentally, Snowdrift.coop hopes
> to go this way in the long run once there's enough resources to handle
> setting that up.
I've asked Stripe to support a workflow like this several times, and
they aren't interested. It's against their terms of service to reverse
the business risk of doing that. I'll keep pestering them for a better
> I agree with the gist, but GNU wants to be sure that all GNU source is
> available as widely as possible. I personally support more nuance than
> pass/fail here. If the service itself does no active discrimination, we
> might say that it passes this even though legal impositions on it have
> the potential to interfere. I'm not sure here.
I understand and agree with the ethical desires here, but it's not
reasonable to ask service providers to risk jail time over it. Dealing
with it here is not the right approach to fixing unreasonable sanctions.
> There's a mix of political/philosophical and factual claims here.
> Private and unlisted repositories do not make licensing moot
> necessarily, only in the case where the software stays totally private
> (not distributed to anyone other than the copyright holders). Free
> software licensing becomes relevant as soon as the software gets copied
> for anyone, even if the project does not provide a way for the general
> public to get access. So, in the cases where Person A with a private
> repo who grants access or makes a copy for Person B.
> But there could be a qualifier considered for A4 around private repos.
> Again, my personal (not the GNU project) view is that the grades should
> not be all-or-nothing, so I'd rather see a percentage score for how much
> of A is passing rather than just tagging something with B because it
> doesn't meet 100% of A. In my view, any repo that won't meet 100% then
> has no incentive to meet the requirements they can, and I think better
> is better even if not complete.
A related problem is that this criteria is ostensibly designed to
determine if a host is appropriate for hosting a GNU project, but this
criteria is more about excluding projects which don't necessarily agree
with GNU principles. The criteria should be about suitability for GNU,
not enforced unsuitability for other kinds of projects.
> > A6: Kind of passes, kind of fails? We use both terms throughout. I
> > disagree with this on principle, however, because it seems to be
> > evaluating the platform in terms of "does it advance GNU's private
> > agenda" rather than "does it match the GNU ideas of ethical hosting",
> > the latter being the ostensible purpose of these criteria.
> We had debates about such things when forming the criteria. I wanted
> this bit to be in the A+ section and to focus on *saying* "free" and
> "freedom" more than on *not* saying "open source". But in the end, these
> criteria are not decided by consensus or popular vote. They reflect GNU
> leadership with the assistance of volunteers like me.
Again, at this point the criteria are no longer about whether or not a
platform is suitable for hosting GNU projects, but really about whether
or not a platform agrees with GNU's agenda items. The pedantry of GNU
over the use of the term "free software" or "GNU/Linux" has always
really bothered me, because GNU doesn't just lead by example - they
attack people who don't linguistically fall in line. This isn't helping
to swing anyone to GNU's side. I wrote a long-form article about it:
This is as someone who agrees with GNU's principles wholeheartedly, but
disagrees with GNU's implementation of this principles.
Let's not get too deep in the dredges of philosophy. If you're not
convinced, then rather than argue the point let's concede that SourceHut
does not qualify for this criteria.
> > A+1: Fails, but this is also unreasonable. We need to collect logs for
> > security reasons. We detect things like when someone is failing to log
> > into your account, or registering accounts in bulk, etc - then blackhole
> > their IP. We monitor important account activity and allow you to review
> > it to detect unauthorized account access, and we can't let you delete it
> > because then the attacker could, too (these are automatically deleted
> > after 30 days). A more measured approach to addressing user data
> > collection would be better here.
> I think this criterion needs clarification. I think the intent is about
> not logging anything for *visitors**i.e. people that come to the site
> and don't register an account or anything. I'm not sure about this.
That's not going to work, either. For one, at various levels of the
stack, identifying account holders versus visitors requires *worsening*
security by bringing more information to previously siloed off parts of
the infrastructure. SourceHut is designed to share information on a
need-to-know basis, and most parts of the service are totally ignorant
about the rest. Additionally, it's also often necessary to monitor
visitors to prevent abuse - this is how our robots.txt was written:
And also necessary for identifying SQL injection attempts, dealing with
denial of service attacks, and so on. In order to meet criteria A+1 we
would have to jeopardize our ability to provide a reliable and secure
service for the rest of our users.
> Thanks for making such honorable efforts to do the right things here! I
> hope we can push things forward to make sure we can add SourceHut with
> at least a passing grade. Regardless of the specifics and debates around
> the GNU criteria, it's clear you care about the ethics as a real value.
And thank you for the feedback!