~sircmpwn/sr.ht-discuss

6 6

Re: Discuss: proposed changes to the SourceHut terms of service

Details
Message ID
<20200603163517.0160e165@fibramid.bearbin.net>
DKIM signature
pass
Download raw message
My perspective on this: sourcehut is not supposed to be the world's
library, it is quite clearly aimed as a platform for developing free
software as its primary purpose.

Abandoned code dumped without a license or source-available proprietary
software are not something that a free-software forge should be
promoting. Practically, as a user browsing GitHub it's infuriating to
come across what could be a nice project but you can't use it because
the licensing situation is so opaque. Making free licenses required
increases user freedom, because viewers are users just as much as the
users who dumped the badly-licensed content there in the first place.

So yes, in principle you should go right ahead with this change. I do
have some reservations about the suggested wording though, in
particular the implication that all repositories will be software
projects. Including the CC licenses is certainly a good step, but I
think the ToS should be much more inclusive about non-software
projects. There are very few "pure-software" projects, and I would
think that sourcehut should enable and encourage these mixed projects
including their websites, assets and other necessary bits and bobs.

I am also concerned with the loose language about "the services". By my
reading of the proposed ToS, I would no longer be able to use sourcehut
to track issues or run a mailing list for my hypothetical non-free
project, even if the source code was hosted elsewhere (or even if my
project didn't have 'code' as such!). These features of sourcehut stand
on their own and enforcing restrictions would be an unwelcome
imposition on user freedom.

A final nitpick: the proposed restriction on crypto-mining flows really
badly:

 > You must not deliberately use the services for the purpose of:
 > [...]
 > - use of excessive resources, such as for cryptocurrency mining

Re: Discuss: proposed changes to the SourceHut terms of service

Details
Message ID
<C37KXRQKVKR5.2JZ689Z5MF1Y5@cirno>
In-Reply-To
<20200603163517.0160e165@fibramid.bearbin.net> (view parent)
DKIM signature
missing
Download raw message
On Wed Jun 3, 2020 at 10:35 AM MDT, Alexander Harkness wrote:
> I am also concerned with the loose language about "the services". By my
> reading of the proposed ToS, I would no longer be able to use sourcehut
> to track issues or run a mailing list for my hypothetical non-free
> project, even if the source code was hosted elsewhere (or even if my
> project didn't have 'code' as such!). These features of sourcehut stand
> on their own and enforcing restrictions would be an unwelcome
> imposition on user freedom.

Your reading is correct, this is by design. The goal is not to support
proprietary software endeavours in any way.

> A final nitpick: the proposed restriction on crypto-mining flows really
> badly:
>
> > You must not deliberately use the services for the purpose of:
> > [...]
> > - use of excessive resources, such as for cryptocurrency mining

Thanks for pointing that out!

Re: Discuss: proposed changes to the SourceHut terms of service

Details
Message ID
<20200604154838.196e9774@fibramid.bearbin.net>
In-Reply-To
<C37KXRQKVKR5.2JZ689Z5MF1Y5@cirno> (view parent)
DKIM signature
pass
Download raw message
On Wed, 03 Jun 2020 09:41:49 -0600
"Drew DeVault" <sir@cmpwn.com> wrote:

> On Wed Jun 3, 2020 at 10:35 AM MDT, Alexander Harkness wrote:
> > I am also concerned with the loose language about "the services".
> > By my reading of the proposed ToS, I would no longer be able to use
> > sourcehut to track issues or run a mailing list for my hypothetical
> > non-free project, even if the source code was hosted elsewhere (or
> > even if my project didn't have 'code' as such!). These features of
> > sourcehut stand on their own and enforcing restrictions would be an
> > unwelcome imposition on user freedom.  
> 
> Your reading is correct, this is by design. The goal is not to support
> proprietary software endeavours in any way.

I can't say I agree with this, even though it's a perfectly reasonable
position for a service like sourcehut to take. 

Just in the same way as private repositories are allowed to contain
non free-software content, I think allowing at least the lists, todo and
wiki services to be used without restriction is helpful to users who
want to work on their own projects without having to perform
context-switches between many different project platforms. My feeling
is that that would not compromise the mission while at the same time
enhancing usability for real-world free-software developers using
sourcehut in the main for free-software development.

Re: Discuss: proposed changes to the SourceHut terms of service

Zlatko Duric
Details
Message ID
<f0d00424-ac15-a91e-1f86-9cb89ac5efbd@mailbox.org>
In-Reply-To
<20200604154838.196e9774@fibramid.bearbin.net> (view parent)
DKIM signature
pass
Download raw message
On 04.06.20 16:48, Alexander Harkness wrote:
> On Wed, 03 Jun 2020 09:41:49 -0600
> "Drew DeVault" <sir@cmpwn.com> wrote:
>
>> On Wed Jun 3, 2020 at 10:35 AM MDT, Alexander Harkness wrote:
>>> I am also concerned with the loose language about "the services".
>>> By my reading of the proposed ToS, I would no longer be able to use
>>> sourcehut to track issues or run a mailing list for my hypothetical
>>> non-free project, even if the source code was hosted elsewhere (or
>>> even if my project didn't have 'code' as such!). These features of
>>> sourcehut stand on their own and enforcing restrictions would be an
>>> unwelcome imposition on user freedom.
>> Your reading is correct, this is by design. The goal is not to support
>> proprietary software endeavours in any way.
> I can't say I agree with this, even though it's a perfectly reasonable
> position for a service like sourcehut to take.
>
> Just in the same way as private repositories are allowed to contain
> non free-software content, I think allowing at least the lists, todo and
> wiki services to be used without restriction is helpful to users who
> want to work on their own projects without having to perform
> context-switches between many different project platforms. My feeling
> is that that would not compromise the mission while at the same time
> enhancing usability for real-world free-software developers using
> sourcehut in the main for free-software development.

Is a todo list copyrightable thing? I'm asking because I'm curious as to 
what does Drew think about things that aren't copyrightable, and 
therefore can't even have a license.



-- 
Zlatko

Re: Discuss: proposed changes to the SourceHut terms of service

Details
Message ID
<d5Ohwbxrw3dWwajDcpu3MjVtaedpScj30lkl8jK2XHrrTO8MBMOJIc-niRyCdrUzXh6g675Zxoq3C9tbvq9h-McT3KuJSG-4W5RGNYZYXKk=@protonmail.com>
In-Reply-To
<f0d00424-ac15-a91e-1f86-9cb89ac5efbd@mailbox.org> (view parent)
DKIM signature
pass
Download raw message
I want to clarify my stance on this topic. I may find this proposal acceptable and with good intentions, especially for the foss movement and 
users of foss software, but I do find it restrictive on the developers which would be your primary user of the service. I personally see 
nothing wrong with using a non-foss/open-source license if the project's current license allows for source code to be viewable by the public 
but remain proprietary.  

With that being said, I do have a couple of ideas to maintain the foss spirit of sr.ht while allowing developers to use their choice of 
license. Sr.ht could allow for only foss repos and projects to be listed on the hub as highlighted projects. The search feature could filter 
results based on its license; foss only are searchable by default, but with an option to select for non-foss results to be displayed. Sr.ht 
could even charge a very slightly higher price for hosting non-foss projects. Another could be allowing non-foss projects to be hidden on the 
platform, from the person’s profile/projects and activity and search function. Meaning the public can only interact with that repo or project 
via a direct link. 

My point is sr.ht could “punish” for lack of a better word, non-foss projects, allowing the public to mostly see foss oriented projects, 
without completely disallowing non-foss on the platform entirely. As I stated before this is your platform to administer how you see fit and 
I hope all the best of luck to you, your staff, and to sr.ht.

Thanks,

Jordan

Re: Discuss: proposed changes to the SourceHut terms of service

Details
Message ID
<d4b46a22-0ea5-50a3-5dbb-35324378c8f4@interia.pl>
In-Reply-To
<d5Ohwbxrw3dWwajDcpu3MjVtaedpScj30lkl8jK2XHrrTO8MBMOJIc-niRyCdrUzXh6g675Zxoq3C9tbvq9h-McT3KuJSG-4W5RGNYZYXKk=@protonmail.com> (view parent)
DKIM signature
pass
Download raw message
W dniu 04.06.2020 o 19:44, Jordan pisze:
> [...] Another could be allowing non-foss projects to be hidden on the 
> platform, from the person’s profile/projects and activity and search function. Meaning the public can only interact with that repo or project 
> via a direct link. 

I think this is how unlisted projects work at the moment?
And as far as I understand, this proposal would still allow
for unlisted repos to have proprietary licenses.

Re: Discuss: proposed changes to the SourceHut terms of service

Details
Message ID
<9e12f8d2-5955-4e0c-a553-49c0a2d8e0e3@www.fastmail.com>
In-Reply-To
<d5Ohwbxrw3dWwajDcpu3MjVtaedpScj30lkl8jK2XHrrTO8MBMOJIc-niRyCdrUzXh6g675Zxoq3C9tbvq9h-McT3KuJSG-4W5RGNYZYXKk=@protonmail.com> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
I would find any of these alternatives acceptable as it would still
allow me to keep all of my projects in one place, while discouraging
proprietary projects (which I sadly still have a few of that I either
can't or am not interested in open sourcing for one reason or another,
but which I'd like to be at least source-available).

—Sam

On Thu, Jun 4, 2020, at 13:44, Jordan wrote:
> With that being said, I do have a couple of ideas to maintain the foss
> spirit of sr.ht while allowing developers to use their choice of
> license. Sr.ht could allow for only foss repos and projects to be
> listed on the hub as highlighted projects. The search feature could
> filter results based on its license; foss only are searchable by
> default, but with an option to select for non-foss results to be
> displayed. Sr.ht could even charge a very slightly higher price for
> hosting non-foss projects. Another could be allowing non-foss projects
> to be hidden on the platform, from the person’s profile/projects and
> activity and search function. Meaning the public can only interact
> with that repo or project via a direct link.
Reply to thread Export thread (mbox)