I can hardly cheer for improvements on this proprietary platform, but good for its users, I guess...

JanKusanagi at 2016-04-09T13:09:48Z

On proprietary platform:

What if:

1. The web service software is proprietary, and there is neither api nor web UI function to export your data. And its EULA said you cannot modify its javascript/css when browsing it, or auto fetch and parse its HTML via curl or other similar tools or programming languages.

2. The web service software is licensed under Free Software licenses but there is no api and there is no export your data function in web UI.

3. The web service software is proprietary, but it has well designed api exposing all or more functions in its web UI.

I won't discuss 1. I think it is Proprietary from any aspects of view.

But what about 2 and 3:

Software:

Proprietary: 3; Free: 2.

For someone who wants to host a web service:

Proprietary: 3; Free: 2

It is consistent till now.

But for someone just wants to use the hosted service, do they have more freedom when using 2?

I think the result is mixed:

1. 1 does provide the freedom that the user can host the service on their own machine or on their friends' machine.

2. But for manipulating their data, 2 (Proprietary Software) provides more freedom than 1 (Free Software).

Traditional local free software does not have this issue, since it runs on your own machine. If a free software cannot save the result to disk or pipe the result, you can edit its source.

A program is free software if the program's users have the four essential freedoms:

The freedom to run the program as you wish, for any purpose (freedom 0).

For web services, there should be something like a freedom -1.

Jakukyo Friel at 2016-05-03T11:09:30Z

Good points!

However, I'll gladly offer my support to a Free Software platform which still doesn't offer a way to export data, over a proprietary platform that already does.

After all, if the FLOSS platform doesn't offer that capability, is probably because nobody has coded it yet. And I couldn't support the proprietary platform, even if it offers nice things. Especially when it's such a "gravity force" as github.com is.

Regarding the Freedom -1, well... the problem here is that a remote service is a black box for the user, whether its source is Free Software or proprietary. But that's a whole other issue. Then again, you can run your own, say, GitLab, but you can't run your own GitHub.

JanKusanagi at 2016-05-03T13:21:22Z

probably because nobody has coded it yet.

But what if the platform owner refuses to merge the feature? For traditional local software, it is never a issue.

the problem here is that a remote service is a black box for the user, whether its source is Free Software or proprietary. But that's a whole other issue.

I do not think it is "a whole other issue".

Free Software does not mention software's functionality. Because it assumes a software's functionality can be extended given the freedom to access the source. But this assumption is not valid on remote services.

That's why I think "proprietary platform" is a vague term.

Not considering self host, I personally cares 1 more than 2:

1. platform providing open data
2. platform using free software

Sure, 2 provides the freedom to self host. But sometimes self host is not possible. For example, if identi.ca is closed, I may self host pump.io (or other alternatives). But if google search engine is closed ( and releases all source code under a FLOSS license), I cannot self host google search.

Jakukyo Friel at 2016-05-09T15:39:04Z