~sircmpwn/sr.ht-discuss

14 3

Ethical repository evaluation of SourceHut

Details
Message ID
<C03B4X6WE7XN.9NAXAORGDJ0B@homura>
DKIM signature
missing
Download raw message
Hello! I would like to request an evaluation of SourceHut under the GNU
ethical repository criteria. SourceHut was already almost there, and I
spent some time in the past couple of days shoring up our weak points.

Note: I've Cc'd the sr.ht-discuss mailing list.

I've done a self-evaluation, here are my conclusions:

# Criteria C

SourceHut passes criteria C1, C2, C3, C5, and C6.

C0: SourceHut mostly passes, but there is one case of nonfree JavaScript
that I can't do anything about: payment processing is handled by Stripe
and I am required to use their nonfree JavaScript for this purpose. I
would like to request an exception. Nonfree JavaScript is not required
for daily use of the services (in fact, JavaScript isn't required at
all). Additionally, I have occasionally accepted payment for the service
in cash for users who are concerned about this issue, at events like
FOSDEM.

C1: Passes

C2: Unfortunately, SourceHut is a business which is based in the United
States, and I am required to follow US laws including trade sanctions. I
don't think that criteria C2 is a reasonable criteria to include in this
list, because it's not legally possible for most hosting providers to
overcome - in fact I think that any of the current evaluees which are
currently receiving marks for this criterion are not in fact able to make
this guarantee. SourceHut would pass if the criteria were a bit more
reasonable: "Does not discriminate against classes of users or against
any country, except where required by law, such as obeying sanctions."

C3: Passes

C4: This is subjective and not a good criteria for that reason. However,
subjectively, I think our terms are pretty reasonable:
https://man.sr.ht/terms.md

C5: Passes: https://man.sr.ht/license.md

C6: Passes

# Criteria B

B0: I just added these to our scripts yesterday (which are very few in
number), I think I got them all. Please let me know if you notice
anything missing and I'll quickly correct them.

B1: Passes

B2: Passes: https://man.sr.ht/license.md; projects without a license see
the following message: https://sr.ht/s5pU.png

B3: Passes: https://man.sr.ht/license.md

# Criteria A

A0: Passes, with flying colors.

A1: Passes: https://git.sr.ht/~sircmpwn/?search=sr.ht 100% free
software!

A2: Passes, A3: Passes: https://man.sr.ht/license.md

A4: Fails. I disagree with this in principle, however. SourceHut
stresses the importance of licenses and offers recommends free software
licenses. However, it also offers private (personal) repositories and
unlisted repositories, for which the choice of license is basically
moot. I also reckon that source-available software is better than
proprietary software, so de-platforming source-available software would
just increase the amount of proprietary software out there.

A5: Passes

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.

A7: This is too vague, but I think we pass.

A8: Fails, but this is another one which is clearly favoring GNU's
private agenda rather than its ethical principles. It's also false - for
the most part, SourceHut runs on Linux without GNU, mainly Alpine Linux.

A9: Fails, but I also disagree with this on principle. This is a best
practice, not an ethical obligation. The purpose of including a license
summary in every file is to prevent the file from being mistakenly
reused in contradiction of the license terms, but even without this the
files are still licensed under their license terms.

On the whole, section A is where the criteria seems to get off the rails
for me. This should focus on evaluating ethical principles, don't get
distracted with "GNU/Linux" or what kind of comments source files have.

## Criteria A+

A+0: Passes

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.

A+2: We're mostly there, but not entirely. We're working on it.

A+3: Passes

A+4: Passes

A+5: In progress. This is a high-priority item.

Curious to hear your thoughts. Thank you for all of your hard work in
evaluating hosting options and helping people choose ethical providers
for their services!
Aaron Wolf
Details
Message ID
<5d003cae-60f2-7c70-24fc-24053b8cf9c8@riseup.net>
In-Reply-To
<C03B4X6WE7XN.9NAXAORGDJ0B@homura> (view parent)
DKIM signature
missing
Download raw message
On 2020-01-23 8:22 a.m., Drew DeVault wrote:
> Hello! I would like to request an evaluation of SourceHut under the GNU
> ethical repository criteria. SourceHut was already almost there, and I
> spent some time in the past couple of days shoring up our weak points.
> 
> Note: I've Cc'd the sr.ht-discuss mailing list.
> 
> I've done a self-evaluation, here are my conclusions:
> 
> # Criteria C
> 
> SourceHut passes criteria C1, C2, C3, C5, and C6.
> 
> C0: SourceHut mostly passes, but there is one case of nonfree JavaScript
> that I can't do anything about: payment processing is handled by Stripe
> and I am required to use their nonfree JavaScript for this purpose. I
> would like to request an exception. Nonfree JavaScript is not required
> for daily use of the services (in fact, JavaScript isn't required at
> all). Additionally, I have occasionally accepted payment for the service
> in cash for users who are concerned about this issue, at events like
> FOSDEM.
> 

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.

As for handling the Stripe issue, there are two things we can suggest to
SourceHut:

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.

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.

> C1: Passes
> 
> C2: Unfortunately, SourceHut is a business which is based in the United
> States, and I am required to follow US laws including trade sanctions. I
> don't think that criteria C2 is a reasonable criteria to include in this
> list, because it's not legally possible for most hosting providers to
> overcome - in fact I think that any of the current evaluees which are
> currently receiving marks for this criterion are not in fact able to make
> this guarantee. SourceHut would pass if the criteria were a bit more
> reasonable: "Does not discriminate against classes of users or against
> any country, except where required by law, such as obeying sanctions."
> 

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.

> C3: Passes
> 
> C4: This is subjective and not a good criteria for that reason. However,
> subjectively, I think our terms are pretty reasonable:
> https://man.sr.ht/terms.md
> 
> C5: Passes: https://man.sr.ht/license.md
> 
> C6: Passes
> 
> # Criteria B
> 
> B0: I just added these to our scripts yesterday (which are very few in
> number), I think I got them all. Please let me know if you notice
> anything missing and I'll quickly correct them.
> 
> B1: Passes
> 
> B2: Passes: https://man.sr.ht/license.md; projects without a license see
> the following message: https://sr.ht/s5pU.png
> 
> B3: Passes: https://man.sr.ht/license.md
> 
> # Criteria A
> 
> A0: Passes, with flying colors.
> 
> A1: Passes: https://git.sr.ht/~sircmpwn/?search=sr.ht 100% free
> software!
> 
> A2: Passes, A3: Passes: https://man.sr.ht/license.md
> 
> A4: Fails. I disagree with this in principle, however. SourceHut
> stresses the importance of licenses and offers recommends free software
> licenses. However, it also offers private (personal) repositories and
> unlisted repositories, for which the choice of license is basically
> moot. I also reckon that source-available software is better than
> proprietary software, so de-platforming source-available software would
> just increase the amount of proprietary software out there.
> 

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.

Source-available software *is* still proprietary, but I know what you
meant. Source-available proprietary software is arguably better than
no-source proprietary software. I don't think the GNU position
acknowledges that in any meaningful way though.

> A5: Passes
> 
> 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.


> A7: This is too vague, but I think we pass.

This passes as long as the political / ethical idea that software
freedom matters is unambiguously included.

> 
> A8: Fails, but this is another one which is clearly favoring GNU's
> private agenda rather than its ethical principles. It's also false - for
> the most part, SourceHut runs on Linux without GNU, mainly Alpine Linux.
> 

When you are referring to Linux without GNU, there's no expectation of
acknowledging GNU. The criterion says "when referring to GNU/Linux".

> A9: Fails, but I also disagree with this on principle. This is a best
> practice, not an ethical obligation. The purpose of including a license
> summary in every file is to prevent the file from being mistakenly
> reused in contradiction of the license terms, but even without this the
> files are still licensed under their license terms.
> 
> On the whole, section A is where the criteria seems to get off the rails
> for me. This should focus on evaluating ethical principles, don't get
> distracted with "GNU/Linux" or what kind of comments source files have.
> 
> ## Criteria A+
> 
> A+0: Passes
> 
> 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.

> 
> A+2: We're mostly there, but not entirely. We're working on it.
> 
> A+3: Passes
> 
> A+4: Passes
> 
> A+5: In progress. This is a high-priority item.
> 
> Curious to hear your thoughts. Thank you for all of your hard work in
> evaluating hosting options and helping people choose ethical providers
> for their services!
> 

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.

Cheers,
Aaron Wolf
Details
Message ID
<C04540KXO8P0.1LKG8HFCJG99G@homura>
In-Reply-To
<5d003cae-60f2-7c70-24fc-24053b8cf9c8@riseup.net> (view parent)
DKIM signature
missing
Download raw message
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
investors.

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.
In such cases, nonfree JavaScript is never required.

Additionally, for third-party instances of SourceHut, you can simply
turn off billing entirely and all accounts will receive all services
without any nonfree JavaScript. That's up to the third-party instance
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
now: https://sr.ht/fXzy.png

> 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
engineer their JavaScript to make a custom solution, and I can't accept
the business risk of doing that. I'll keep pestering them for a better
solution, though.

> 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:

https://drewdevault.com/2019/09/17/The-wrong-words-but-the-right-ideas.html

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:

https://git.sr.ht/robots.txt

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!
Aaron Wolf
Details
Message ID
<e60a1e2e-27e3-7b53-2b6e-763e5376518d@riseup.net>
In-Reply-To
<C04540KXO8P0.1LKG8HFCJG99G@homura> (view parent)
DKIM signature
missing
Download raw message
Dropping the repo-criteria list, replying only to you and sr.ht list:

As co-founder of Snowdrift.coop, I just have to say we're 100% on the
same page here. We tried and failed to meet RMS and GNU criteria
completely, partly through just disagreement and practical reality. We
are not and will likely never be a GNU project. We may not get RMS's
endorsement, though he recognizes that we are allies and share overall
ethical concerns.

We are ourselves working to address exactly the sort of economic
challenges you bring up. We'd love to eventually be able to be a
fundraising option for SourceHut and even to move from GitLab to
SourceHut for our own stuff (our journey from Gitorious to GitLab CE to
GitLab.com was itself painful and costly, all around frustrations with
these things, and GitLab's VC-funding undermines their trust otherwise,
etc., I have been meaning to write a blog about all this. I'll highlight
SourceHut when I do.)

To just be clear about that: our mission is funding public goods,
meaning non-rivalrous. Bandwidth at SourceHut is technically rivalrous
but it might as well be non-rivalrous for smaller projects. So, my
long-term dream would be that Snowdrift.coop's crowdmatching funds
SourceHut development and the basic maintenance of the hosting service.
Then, anyone who needs beyond a modest size repo or wants more dedicated
support service will pay you for that (or get sponsored if need be).

We wrote our own critique of RMS's pedantic rejection of "open"
https://wiki.snowdrift.coop/about/free-libre-open (and incidentally, we
do encourage you to consider the term "FLO").

I had some long arguments with RMS about these things. Him asking us to
stop having references to "open" anything was unconvincing. I tried to
argue for more of the repo criteria being A+ extra-credit and to having
more nuance and more of a percentage grade rather than simply getting a
C if you miss a single B item even when meeting most of A.

While RMS truly considered my arguments, the repo criteria represent his
decisions in the end. Hence, I replied to express my understanding of
the RMS / GNU position.

I find the criteria a good starting point still since they are in the
right direction.

On Stripe, I wonder if CrowdSupply is still managing today to work with
Stripe without proprietary JS, they first implemented that back in 2015
or so.

Anyway, since we seem completely aligned, I'd like to encourage any
further partnership, even if for now that just means using whatever best
ideas and principles we each come up with. For example, I'm pretty darn
happy with our excellent Terms and Privacy policies (but they haven't
yet had lawyer review fully): https://snowdrift.coop/privacy and
https://snowdrift.coop/terms — and I'm now curious to see what you've
come up with and consider any good ideas there, and I invite you to do
the same.

We don't want to reinvent wheels, we want to be part of everyone who
cares working together cooperatively for the best for the public interest.

Cheers,
Aaron Wolf


On 2020-01-24 7:51 a.m., Drew DeVault wrote:
> 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
> investors.
> 
> 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.
> In such cases, nonfree JavaScript is never required.
> 
> Additionally, for third-party instances of SourceHut, you can simply
> turn off billing entirely and all accounts will receive all services
> without any nonfree JavaScript. That's up to the third-party instance
> 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
> now: https://sr.ht/fXzy.png
> 
>> 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
> engineer their JavaScript to make a custom solution, and I can't accept
> the business risk of doing that. I'll keep pestering them for a better
> solution, though.
> 
>> 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:
> 
> https://drewdevault.com/2019/09/17/The-wrong-words-but-the-right-ideas.html
> 
> 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:
> 
> https://git.sr.ht/robots.txt
> 
> 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!
> 
Details
Message ID
<0473f92c-fdf2-5df9-20f0-d29e654d1d4a@brack.se>
In-Reply-To
<5d003cae-60f2-7c70-24fc-24053b8cf9c8@riseup.net> (view parent)
DKIM signature
missing
Download raw message
A+1: You could log IP addresses in a masked format. This is also 
required by the GDPR, I think. I have never given my active, informed 
consent to having my IP stored. (Not doing this could potentially put 
you on the hook for a €20M fine, or require you to break requirements C2 
and C3)

The following protocol should be good enough, while not putting odious 
requirements:
1) Each week, generate a random salt with ID = year + week number
2) Hash the IP with the salt (possibly with a difficult hash that takes 
~1ms/evaluation or whatever)
3) Store salt ID and and first 12 bits of hash.

Then, whenever you want to ban an IP, you can still do this. Add the 
hash to a list of banned IPs, and check all inbound IPs against the 
banned list. If it matches, then you can store the full IP and delete 
the hash. Keep salts for the last 2 weeks.

The same goes for the country code, if you want to keep that 
information. You can estimate how many bits of information it has, round 
down, and save country + 12-N bits of salted IP hash.

Another solution is to add a feature in the settings where you say, "I 
know what I am doing, my password can't easily be brute-forced, don't 
log my login attempts _going forward_".

Furthermore, IP blocking is not going to mesh well with Tor. Are you 
going to ban Tor (violating C3), or give attackers a free pass as long 
as they use Tor (making the IP blocking moot)?

I think a better approach is gray-listing: If your IP is clean, you 
don't need a captcha to log in. If your IP is not clean, you need to 
give one.
(That can also be done without saving IPs; you could use one of those 
numeric bloom filters or whatever to get an approximate value of "failed 
login attempts in past 24 hours for IP X" - it doesn't have to be exact)

Protecting against SQLi with IP logging is doomed to fail. Professional 
hackers will just use a botnet. Besides, you are using prepared 
statements, right?

C0: You could take Monero or Bitcoin for payment. This has better 
privacy and, at least in the case of Monero, lower transaction fees. It 
can be done without JavaScript.

C2: This is hard, but perhaps a change in corporate structure might 
accomplish it? Or does it prohibit all US citizens from doing such 
business? Alternatively, providing an onion service and taking payment 
in cryptocurrency will allow such citizens to use the service as long as 
you are not actively aware of it.
Details
Message ID
<C050LDRN5696.1N2AL9YD7WDOH@homura>
In-Reply-To
<0473f92c-fdf2-5df9-20f0-d29e654d1d4a@brack.se> (view parent)
DKIM signature
missing
Download raw message
On Sat Jan 25, 2020 at 5:30 PM, Elliot Bräck wrote:
> A+1: You could log IP addresses in a masked format. This is also
> required by the GDPR, I think. I have never given my active, informed
> consent to having my IP stored. (Not doing this could potentially put
> you on the hook for a €20M fine, or require you to break requirements
> C2 and C3)

This is a flawed understanding of the GDPR. I don't need your consent to
log your IP address with a reasonable retention policy, as long as I
comply with the rest of the GDPR.

> Furthermore, IP blocking is not going to mesh well with Tor. Are you
> going to ban Tor (violating C3), or give attackers a free pass as long
> as they use Tor (making the IP blocking moot)?

No, but I might temporary ban certain exit nodes, or identify other
patterns from the attackers. I can't go into more detail here, security
by obscurity is a necessary tactic for dealing with this kind of abuse.

> Protecting against SQLi with IP logging is doomed to fail. Professional
> hackers will just use a botnet. Besides, you are using prepared
> statements, right?

I don't rely on monitoring to defend from SQLi, I am quite confident
that SourceHut is safe from it regardless. However, SQLi attempts are an
easy way to identify bad actors on the network. Again, not going to go
into much more detail here.

> C0: You could take Monero or Bitcoin for payment. This has better
> privacy and, at least in the case of Monero, lower transaction fees. It
> can be done without JavaScript.

I am not interested in accepting cryptocurrencies.

> C2: This is hard, but perhaps a change in corporate structure might
> accomplish it? Or does it prohibit all US citizens from doing such
> business? Alternatively, providing an onion service and taking payment
> in cryptocurrency will allow such citizens to use the service as long as
> you are not actively aware of it.

Unfortunately, no, there is no business model which will allow me to
circumvent sanctions. I have thought about it, but again, users are
better off if I'm vague about this than if I elaborate in any great
detail. In this case you just have to trust that I am going to do the
right thing, and that's the end of it.

I profoundly apologise for the vagueness, but these points are the most
difficult ones to address transparently without undermining themselves.
At some point, going into more detail will force service operators to
make compromises that will end up with users being worse off than
before. I hope that the rest of my principles are enough to earn my
user's trust in these matters, because doing right by them requires
being less transparent about some things.
Details
Message ID
<91ea2751-2509-7a0a-0efb-5b003a3456fc@brack.se>
In-Reply-To
<5d003cae-60f2-7c70-24fc-24053b8cf9c8@riseup.net> (view parent)
DKIM signature
missing
Download raw message
(It seems like I'm not getting the e-mail from the mailing list, just 
from the issue tracker - do I need to set it up somewhere?)

 > No, but I might temporary ban certain exit nodes, or identify other
 > patterns from the attackers. I can't go into more detail here, security
 > by obscurity is a necessary tactic for dealing with this kind of abuse.
 >
 > I don't rely on monitoring to defend from SQLi, I am quite confident
 > that SourceHut is safe from it regardless. However, SQLi attempts are an
 > easy way to identify bad actors on the network. Again, not going to go
 > into much more detail here.
Well, if that's the case then that's the case. I must say that it's not 
a robust approach however, and it arguably isn't strictly required for 
the functioning of the service. Goodhart's law: whatever characteristic 
you can measure, they can game. For example, you can get a new exit node 
by feeding a new set of credentials to the Tor SOCKS proxy. A malicious 
actor could trivially (we are talking < 5 minutes of work) make a script 
to send SQLi attempts from all the Tor exit nodes.

In fact, here is such a script:
`while true; do (torsocks -i curl 'sr.ht/do_some_sqli' & sleep 1); done`

(FWIW, I think SQLi attempts are only being done by mass crawlers, not 
targeted attackers; they might be a nuisance but they shouldn't pose any 
serious threat to your website. If there is a genuine vulnerability, 
there is the issue that they can run a local instance to perfect it, and 
then they only need to make it through your filtering once to exploit it)

 > I am not interested in accepting cryptocurrencies.
Well, it seems like a simple solution to your problem...

Another approach is to offer direct bank transfer. Ask people to wire 
money to your business' account with the message field being their 
username. Money orders or cheques sent through postal mail would also 
work for American customers.
Details
Message ID
<C051MUMPMU5Q.T75SDU7X2OAI@homura>
In-Reply-To
<91ea2751-2509-7a0a-0efb-5b003a3456fc@brack.se> (view parent)
DKIM signature
missing
Download raw message
On Sat Jan 25, 2020 at 6:20 PM, Elliot Bräck wrote:
> Well, if that's the case then that's the case. I must say that it's not
> a robust approach however, and it arguably isn't strictly required for
> the functioning of the service. Goodhart's law: whatever characteristic
> you can measure, they can game.

This is why I won't go into detail on what characteristics I'm
measuring. The monitoring is robust, I can assure you.

> Another approach is to offer direct bank transfer. Ask people to wire
> money to your business' account with the message field being their
> username. Money orders or cheques sent through postal mail would also
> work for American customers.

I have considered options like this, but the reality is that supporting
a large subset of the world's population is extremely difficult and time
consuming. It can take months of wading through regulatory problems for
*each* new country you want to accept payments from. I simply don't have
the time for it.
Details
Message ID
<C051TLJOZY2T.25SLHBMDJOGLD@homura>
In-Reply-To
<e60a1e2e-27e3-7b53-2b6e-763e5376518d@riseup.net> (view parent)
DKIM signature
missing
Download raw message
On Fri Jan 24, 2020 at 8:33 AM, Aaron Wolf wrote:
> To just be clear about that: our mission is funding public goods,
> meaning non-rivalrous. Bandwidth at SourceHut is technically rivalrous
> but it might as well be non-rivalrous for smaller projects.

What does non-rivalrous mean in this context?

> So, my long-term dream would be that Snowdrift.coop's crowdmatching
> funds SourceHut development and the basic maintenance of the hosting
> service. Then, anyone who needs beyond a modest size repo or wants
> more dedicated support service will pay you for that (or get sponsored
> if need be).

Hm, not really interested in this. Let's talk in private if you want my
feedback on the snowdrift model. SourceHut is doing just fine with its
current financial model today and I don't see a reason to change that.

> We wrote our own critique of RMS's pedantic rejection of "open"
> https://wiki.snowdrift.coop/about/free-libre-open (and incidentally, we
> do encourage you to consider the term "FLO").

Nice article! From the article I linked in my earlier email, you might
get an idea of my own approach to the language issue. I deliberately
reject planting a flag in the sand by exclusively using terms like "free
software", "open source", or even "FOSS", and the same arguments apply
to "FLO".

Side note: I have some visual impairments and I found this article very
difficult to read. You should increase contrast and consider using
the user's default fonts. Out of curiosity, I ran it through Chromium's
accessibility profiler, and found it scored only 53%. I recently did
some work to secure the last 7% in SourceHut's score - now 100% - let me
know if you want some tips.

> On Stripe, I wonder if CrowdSupply is still managing today to work with
> Stripe without proprietary JS, they first implemented that back in 2015
> or so.

Not sure, but I did notice they use Google Analytics now, so I imagine
that they have kind of lost those principles.

> Anyway, since we seem completely aligned, I'd like to encourage any
> further partnership, even if for now that just means using whatever best
> ideas and principles we each come up with. For example, I'm pretty darn
> happy with our excellent Terms and Privacy policies (but they haven't
> yet had lawyer review fully): https://snowdrift.coop/privacy and
> https://snowdrift.coop/terms — and I'm now curious to see what you've
> come up with and consider any good ideas there, and I invite you to do
> the same.

Looks like we have some similar ideas. Here's SourceHut's:

https://man.sr.ht/privacy.md
https://man.sr.ht/terms.md

Thanks for the links!

> We don't want to reinvent wheels, we want to be part of everyone who
> cares working together cooperatively for the best for the public
> interest.

Agreed!
Details
Message ID
<03d538ab-65f2-f4b1-663f-c2bb0dc1181a@brack.se>
In-Reply-To
<C051MUMPMU5Q.T75SDU7X2OAI@homura> (view parent)
DKIM signature
missing
Download raw message
On 1/25/20 6:20 PM, Drew DeVault wrote:
 > I have considered options like this, but the reality is that supporting
 > a large subset of the world's population is extremely difficult and time
 > consuming. It can take months of wading through regulatory problems for
 > *each* new country you want to accept payments from. I simply don't have
 > the time for it.
If you want to, you could take a third option and allow you to fund 
other people's accounts with your credit card. Then I could receive 
cash/local bank transfers/cryptocurrency/whatever and pay for them with 
my card.
Aaron Wolf
Details
Message ID
<35e74b50-7307-81e3-a365-0dc48ebc3346@riseup.net>
In-Reply-To
<C051TLJOZY2T.25SLHBMDJOGLD@homura> (view parent)
DKIM signature
missing
Download raw message
On 2020-01-25 9:29 a.m., Drew DeVault wrote:
> On Fri Jan 24, 2020 at 8:33 AM, Aaron Wolf wrote:
>> To just be clear about that: our mission is funding public goods,
>> meaning non-rivalrous. Bandwidth at SourceHut is technically rivalrous
>> but it might as well be non-rivalrous for smaller projects.
> 
> What does non-rivalrous mean in this context?
> 

Non-rivalrous means that when someone new access something it in no way
detracts from anyone else. So, people running copies of software. When
their use of a web service involves *negligible* bandwidth or hassle
from the limited-time of the service providers, it's effectively
non-rivalrous. Rivalrous includes stuff like video-hosting
(high-bandwidth) and support energy from people and food and cars etc.
private goods.

See https://wiki.snowdrift.coop/about/economics for more

>> So, my long-term dream would be that Snowdrift.coop's crowdmatching
>> funds SourceHut development and the basic maintenance of the hosting
>> service. Then, anyone who needs beyond a modest size repo or wants
>> more dedicated support service will pay you for that (or get sponsored
>> if need be).
> 
> Hm, not really interested in this. Let's talk in private if you want my
> feedback on the snowdrift model. SourceHut is doing just fine with its
> current financial model today and I don't see a reason to change that.
> 

I'm really glad you have a working model. Happy also to talk about the
benefits of our model, but no rush. We're not ready to use anyway.

>> We wrote our own critique of RMS's pedantic rejection of "open"
>> https://wiki.snowdrift.coop/about/free-libre-open (and incidentally, we
>> do encourage you to consider the term "FLO").
> 
> Nice article! From the article I linked in my earlier email, you might
> get an idea of my own approach to the language issue. I deliberately
> reject planting a flag in the sand by exclusively using terms like "free
> software", "open source", or even "FOSS", and the same arguments apply
> to "FLO".

I agree, we don't need to be exclusive. FLO is just the best overall for
most cases. Add it to your repertoire maybe. We don't really want to
play the exclusivity game.

> 
> Side note: I have some visual impairments and I found this article very
> difficult to read. You should increase contrast and consider using
> the user's default fonts. Out of curiosity, I ran it through Chromium's
> accessibility profiler, and found it scored only 53%. I recently did
> some work to secure the last 7% in SourceHut's score - now 100% - let me
> know if you want some tips.
> 

Oh nice!! Thanks for bringing that up. First I've heard of that
profiler. I agree about the contrast. I actually use the Dark Background
Light Text plugin to maximize contrast everywhere, and I just have it
off for Snowdrift.coop to see what our site looks like. I'm not one of
the design folks, but I'll bring this up. We all care about these concerns!

>> On Stripe, I wonder if CrowdSupply is still managing today to work with
>> Stripe without proprietary JS, they first implemented that back in 2015
>> or so.
> 
> Not sure, but I did notice they use Google Analytics now, so I imagine
> that they have kind of lost those principles.
> 

Oh damnit. Thanks for checking.

>> Anyway, since we seem completely aligned, I'd like to encourage any
>> further partnership, even if for now that just means using whatever best
>> ideas and principles we each come up with. For example, I'm pretty darn
>> happy with our excellent Terms and Privacy policies (but they haven't
>> yet had lawyer review fully): https://snowdrift.coop/privacy and
>> https://snowdrift.coop/terms — and I'm now curious to see what you've
>> come up with and consider any good ideas there, and I invite you to do
>> the same.
> 
> Looks like we have some similar ideas. Here's SourceHut's:
> 
> https://man.sr.ht/privacy.md
> https://man.sr.ht/terms.md
> 
> Thanks for the links!
> 
>> We don't want to reinvent wheels, we want to be part of everyone who
>> cares working together cooperatively for the best for the public
>> interest.
> 
> Agreed!
> 
Details
Message ID
<C052NWV5OXMW.28CFQ6JYH2RBU@homura>
In-Reply-To
<35e74b50-7307-81e3-a365-0dc48ebc3346@riseup.net> (view parent)
DKIM signature
missing
Download raw message
On Sat Jan 25, 2020 at 10:00 AM, Aaron Wolf wrote:
> Non-rivalrous means that when someone new access something it in no way
> detracts from anyone else. So, people running copies of software. When
> their use of a web service involves *negligible* bandwidth or hassle
> from the limited-time of the service providers, it's effectively
> non-rivalrous. Rivalrous includes stuff like video-hosting
> (high-bandwidth) and support energy from people and food and cars etc.
> private goods.
>
> See https://wiki.snowdrift.coop/about/economics for more

In what way does SourceHut then qualify as rivalrous? Do you just mean
that the hosting infrastructure is privately owned? I mean, someone's
got to foot the bill...
Aaron Wolf
Details
Message ID
<d30878b6-c563-b4f5-ef64-b90ca1736846@riseup.net>
In-Reply-To
<C052NWV5OXMW.28CFQ6JYH2RBU@homura> (view parent)
DKIM signature
missing
Download raw message
On 2020-01-25 10:09 a.m., Drew DeVault wrote:
> On Sat Jan 25, 2020 at 10:00 AM, Aaron Wolf wrote:
>> Non-rivalrous means that when someone new access something it in no way
>> detracts from anyone else. So, people running copies of software. When
>> their use of a web service involves *negligible* bandwidth or hassle
>> from the limited-time of the service providers, it's effectively
>> non-rivalrous. Rivalrous includes stuff like video-hosting
>> (high-bandwidth) and support energy from people and food and cars etc.
>> private goods.
>>
>> See https://wiki.snowdrift.coop/about/economics for more
> 
> In what way does SourceHut then qualify as rivalrous? Do you just mean
> that the hosting infrastructure is privately owned? I mean, someone's
> got to foot the bill...
> 

Non-rivalrous: totally unlimited use by anyone, nobody takes away from
anyone else

Rivalrous: my use limits your use

Rivalrous aspects of basically any FLO project: the hosting
infrastructure, development/maintenance/support time from people

Yes exactly, someone has to foot the bill. The only question is whether
the bill goes *up* more than negligibly as the service gets more use.
Surely there's a base-level cost that remains regardless of usage. If
each new repository or user account has no noticeable effect on the
costs, then it's all basically non-rivalrous.

From the Snowdrift.coop perspective, the goal is to cover the necessary
R&D and maintenance costs (servers, salaries etc) of FLO projects
without artificially limits (paywall) or harm (ads, non-free limitations
etc) to the non-rivalrous products and services.

In other words, it makes complete sense to directly charge anyone whose
use is directly increasing your costs.

If a user does not measurably increase costs, that sort of use is
non-rivalrous.

Does that make it clearer?

Even a service open to everyone without paywall is one where we want the
users to be directly paying in to cover the basic costs for the service
to exist. That's the tension. How to remove paywalls and still get the
costs covered.
Details
Message ID
<C052ZL8LOMSH.M1UNJ7GTOCB3@homura>
In-Reply-To
<d30878b6-c563-b4f5-ef64-b90ca1736846@riseup.net> (view parent)
DKIM signature
missing
Download raw message
On Sat Jan 25, 2020 at 10:23 AM, Aaron Wolf wrote:
> Non-rivalrous: totally unlimited use by anyone, nobody takes away from
> anyone else
>
> Rivalrous: my use limits your use
>
> Rivalrous aspects of basically any FLO project: the hosting
> infrastructure, development/maintenance/support time from people
>
> Yes exactly, someone has to foot the bill. The only question is whether
> the bill goes *up* more than negligibly as the service gets more use.
> Surely there's a base-level cost that remains regardless of usage. If
> each new repository or user account has no noticeable effect on the
> costs, then it's all basically non-rivalrous.
>
> From the Snowdrift.coop perspective, the goal is to cover the necessary
> R&D and maintenance costs (servers, salaries etc) of FLO projects
> without artificially limits (paywall) or harm (ads, non-free limitations
> etc) to the non-rivalrous products and services.
>
> In other words, it makes complete sense to directly charge anyone whose
> use is directly increasing your costs.
>
> If a user does not measurably increase costs, that sort of use is
> non-rivalrous.
>
> Does that make it clearer?

Thanks for the explanation, that does help.

Unfortunately, our costs don't really roll up into a nicely modelable
tin like that. We have infrequent expenses for things like new servers
which are driven as a function of demand, which scales non-linearly and
is not predictable far in advance. We have business expenses, like
insurance, bookeeping, regulatory compliance, etc. We have to keep some
sum of money on hand to deal with emergency expenses, which also gives
us some buffer to withstand broader economic issues for example. The
financial planning for SourceHut is rather complicated.

Also, and this gets at the heart of how SourceHut differs
philisophically from Snowdrift.coop, we invest our profits above our
expenses into open source/free software by hiring developers to work on
any FLO projects they please, at their discretion. This helps to promote
development on smaller projects which don't necessarily have the
critical mass to get funding outright, as well as naturally working to
the benefit of larger projects as well. It also allows one engineer to
provide value to mulitple large projects without having to try and work
out the budget issues between them. In other words, I prefer to finance
developers, not projects.
Aaron Wolf
Details
Message ID
<2c04607a-2e79-f9f2-c9f9-769737b64647@riseup.net>
In-Reply-To
<C052ZL8LOMSH.M1UNJ7GTOCB3@homura> (view parent)
DKIM signature
missing
Download raw message
On 2020-01-25 10:24 a.m., Drew DeVault wrote:
> On Sat Jan 25, 2020 at 10:23 AM, Aaron Wolf wrote:
>> Non-rivalrous: totally unlimited use by anyone, nobody takes away from
>> anyone else
>>
>> Rivalrous: my use limits your use
>>
>> Rivalrous aspects of basically any FLO project: the hosting
>> infrastructure, development/maintenance/support time from people
>>
>> Yes exactly, someone has to foot the bill. The only question is whether
>> the bill goes *up* more than negligibly as the service gets more use.
>> Surely there's a base-level cost that remains regardless of usage. If
>> each new repository or user account has no noticeable effect on the
>> costs, then it's all basically non-rivalrous.
>>
>> From the Snowdrift.coop perspective, the goal is to cover the necessary
>> R&D and maintenance costs (servers, salaries etc) of FLO projects
>> without artificially limits (paywall) or harm (ads, non-free limitations
>> etc) to the non-rivalrous products and services.
>>
>> In other words, it makes complete sense to directly charge anyone whose
>> use is directly increasing your costs.
>>
>> If a user does not measurably increase costs, that sort of use is
>> non-rivalrous.
>>
>> Does that make it clearer?
> 
> Thanks for the explanation, that does help.
> 
> Unfortunately, our costs don't really roll up into a nicely modelable
> tin like that. We have infrequent expenses for things like new servers
> which are driven as a function of demand, which scales non-linearly and
> is not predictable far in advance. We have business expenses, like
> insurance, bookeeping, regulatory compliance, etc. We have to keep some
> sum of money on hand to deal with emergency expenses, which also gives
> us some buffer to withstand broader economic issues for example. The
> financial planning for SourceHut is rather complicated.
> 
> Also, and this gets at the heart of how SourceHut differs
> philisophically from Snowdrift.coop, we invest our profits above our
> expenses into open source/free software by hiring developers to work on
> any FLO projects they please, at their discretion. This helps to promote
> development on smaller projects which don't necessarily have the
> critical mass to get funding outright, as well as naturally working to
> the benefit of larger projects as well. It also allows one engineer to
> provide value to mulitple large projects without having to try and work
> out the budget issues between them. In other words, I prefer to finance
> developers, not projects.
> 

I thank that's just a tactical but not at all philosophical difference.
I support your perspective too. Our hope with Snowdrift.coop is that if
projects can get better funding, they can support their upstream
dependencies, fund their team to do some side FLO work on other things…
and we're not totally closed to the eventual idea that someone might
just list a project like "Drew's collection of FLO work" or something.

Anyway, for your business model: my philosophical position is (A) hooray
for whatever successfully funds FLO like SourceHut without compromising
values and conflicts-of-interest like we see with GitLab and their VC
investors and (B) I want to see maximum adoption of ethical FLO projects
like SourceHut and not see anyone turn away because of a paywall (else
they will go to or stay at GitHub etc)

I want SourceHut to have enough income to easily accommodate all
expenses, including buffer etc. Ideally, it does so while gaining as
much adoption as possible and while users *understand* the economics and
see everyone as cooperating together to fund this public value (rather
than see it as a mere business transaction they make independently with
SourceHut).

As an analogy, Ardour (the music software) is fully FLO but they have a
paywall in order to get binaries from them (source is available under
GPL and anyone can distribute a binary). To the extent this funds it,
great. But I'm concerned that this discourages adoption. Better 500
funders and a million users than 500 funders and only 1,500 users. It's
not in itself bad to have additional users who aren't donating — unless
their freeriding discourages the donors. I also don't like that Ardour's
model reinforces the idea that paywalls for software are normal (because
that promotes the normalization of proprietary software).

In short, I just want the most FLO serving the public interest.
Snowdrift.coop's crowdmatching is just one way to work in that
direction. I support whatever else works.

I'd be most concerned if SourceHut were struggling to cover expenses.
That would be the least sustainable and most troubling scenario.

In harmony,
Aaron
Reply to thread Export thread (mbox)