Re: Bug#856139: certspotter: long description advertises commercial service
Vincent Bernat <bernat@debian.org> writes:
> As a sidenote, I strongly think I should just shut up. This kind of
> discussions always lead nowhere and people just forget them. But...
Yeah, I've been feeling the same way. But one message in support of this
point, just to try to balance the expressed opinions a bit.
> Let's take rclone.
> Description: rsync for commercial cloud storage
> Rclone is a program to sync files and directories between the local
> file system and a variety of commercial cloud storage providers:
> .
> - Google Drive
> - Amazon S3
> - Openstack Swift / Rackspace cloud files / Memset Memstore
> - Dropbox
> - Google Cloud Storage
> - Amazon Drive
> - Microsoft One Drive
> - Hubic
> - Backblaze B2
> - Yandex Disk
> It says "commercial". Lot of commercial services. But, it would work
> with free S3 implementations and it works with Openstack Swift which is
> free. So, not in contrib, right?
> Now, it is written in Go and it depends on a lot of libraries, notably those:
> - golang-github-aws-aws-sdk-go
> - golang-github-stacktic-dropbox
> - golang-google-api
> - golang-google-cloud
> They should be in contrib. But then, rclone would be in contrib
> (packages in main cannot depend on packages in contrib). So, our users
> would just lose a software which can be used to migrate data from a
> commercial service to a free service.
Indeed.
I think it's a bad idea to push this sort of tool off into contrib. I
don't think making it harder to use free software with non-free services
is going to achieve our goals as a project; to the contrary, I think
making it easier to get data out of non-free services using free software
can only benefit free software, given the current balance of power in the
ecosystem.
If free software cloud services were overwhelmingly common and non-free
cloud services were an intruder in this space, the calculus might be
different, and it might be tactically better to freeze out the non-free
services and make it more difficult to work with them. But that's not the
shape of ecosystem that we're dealing with right now.
(Conflict of interest disclosure: I currently work for Dropbox, although
not on the product side. I think the above opinion is the same I'd hold
if I didn't work for Dropbox, and held before I took that job, but anyone
reading this thread should judge that for themselves.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: