4 ms·

It's not public as in an utility. It has its own Terms of Service.

josephcsible 4y ago
The point is it's not fair that Terms of Service can impose that restriction. Just like it wasn't fair when you were only allowed to use phones that you rented from your phone company.
- tptacek 4y ago
  Why isn't it fair? They run the service. What gives other people the right to tell them how to run it? If you don't like their terms, there are about 100 alternative projects you can use. There are pretty clear, practical reasons you might want to control the client of a commercial network service.
  - josephcsible 4y ago
    What part of your argument wasn't true of the phone company too?
    - edmundsauto 4y ago
      The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)
      - josephcsible 4y ago
        If Slack isn't the sole-source provider, then neither was the phone company, since you could also communicate by sending letters.
        edmundsauto 4y ago
        That's a different medium, although I understand your point: Slack is the sole source provider of communicating on the Slack network. Personally, I don't think this is a problem or should be fixed because of how I see the tradeoffs and side effects. Similarly, I want Apple to run their own app store and not allow sideloading because I prefer the set of tradeoffs that come with that, versus the other reality.
    - wpietri 4y ago
      Phone companies are different in that they were monopolies with special legal status. Slack, on the other hand, is just one of many private companies offering roughly equivalent services. You can still argue your case, of course, but phone companies are a bad analogy here.
  - tadfisher 4y ago
    There are reasons, but it's also not smart. Organizations that pay for Slack pay for the service, not the shitty client.
    - gtirloni 4y ago
      You want to reduce Slack Inc to an API provider. They want to be a client provider too and they own the API server. Do you see where this won't work?
      - tadfisher 4y ago
        The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.
        gtirloni 4y ago
        You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.
        tadfisher 4y ago
        > But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far. Only because it's next-to-impossible to call the API, because of the way they lock features to their client!
  - tumult 4y ago
    Author of Ripcord. You’re wrong, and creating and using software compatible with services is fair.
    - chii 4y ago
      i do agree it's fair, but it's also true that the service provider could argue that they are supposed to be in total control of the service, including the front-end. It's by societal consensus that this can be made fair, and to convince people that it is fair, there needs to be a logical, indisputable argument that it's fair. Otherwise, the service providers can always just hide behind the counter-argument of being in control and TOS etc.
      - tumult 4y ago
        In the case of Discord, for example, the terms of service doesn't even mention third-party clients. Also, these services are accessible from web browsers, which are made by third parties. There are more reasons, like users being able to run whatever they want on their own computers, but just the ones above are enough.
        gtirloni 4y ago
        "You may not copy, modify, create derivative works based upon, distribute, sell, lease, or sublicense any of our software or services" This seems to make it pretty clear they don't want you to create 3rd-party clients for their service.
        tumult 4y ago
        Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.
        gtirloni 4y ago
        If I rephrase it like this, does it make it clear? "You may not create derivative works based upon any of our services"
Perseids 4y ago
I assume your argument is that Slack has the "freedom of contract", the right to create and offer you contracts of their choosing (and you are free to accept or decline them). That right is not absolute. Workers rights limit it, sanctions limit it, cartel and competition laws limit it. There is no reason society can't agree to limit the options of keeping an API locked down in such contracts, especially for well established companies like Slack. And I think the advantages of such a law are very clear: More competition on front-ends could very likely create much better user experience (better organization of chats, better message and image editor, better notifications, show users whether messages have actually been sent). Laws are made to serve the public [1]. Being nice to companies is a means to an end, not the goal itself, and the discussion about whether API should be legally accessible to third party vendors (or devices/cars/… should be legally repairable by third party repair shops) should focus on whether we get better user experience, service, and so on, and have the question of whether companies will still want to offer backend-service like Slack under such a law as a facet. [1] At least they should be and everybody complaints when they aren't.

The point is it's not fair that Terms of Service can impose that restriction. Just like it wasn't fair when you were only allowed to use phones that you rented from your phone company.

tptacek 4y ago
Why isn't it fair? They run the service. What gives other people the right to tell them how to run it? If you don't like their terms, there are about 100 alternative projects you can use. There are pretty clear, practical reasons you might want to control the client of a commercial network service.
- josephcsible 4y ago
  What part of your argument wasn't true of the phone company too?
  - edmundsauto 4y ago
    The phone company is the sole-source provider and you couldn't opt for another platform. The more relevant analogy is soda fountains in a restaurant - the provider chose Coke, but I want Pepsi. (My OSS founder wanted Slack, I want discord.)
    - josephcsible 4y ago
      If Slack isn't the sole-source provider, then neither was the phone company, since you could also communicate by sending letters.
      - edmundsauto 4y ago
        That's a different medium, although I understand your point: Slack is the sole source provider of communicating on the Slack network. Personally, I don't think this is a problem or should be fixed because of how I see the tradeoffs and side effects. Similarly, I want Apple to run their own app store and not allow sideloading because I prefer the set of tradeoffs that come with that, versus the other reality.
  - wpietri 4y ago
    Phone companies are different in that they were monopolies with special legal status. Slack, on the other hand, is just one of many private companies offering roughly equivalent services. You can still argue your case, of course, but phone companies are a bad analogy here.
- tadfisher 4y ago
  There are reasons, but it's also not smart. Organizations that pay for Slack pay for the service, not the shitty client.
  - gtirloni 4y ago
    You want to reduce Slack Inc to an API provider. They want to be a client provider too and they own the API server. Do you see where this won't work?
    - tadfisher 4y ago
      The value of Slack Inc is their API, which is currently de-facto locked to their client. People would still pay for Slack if they could use alternative clients, because the client is not the value.
      - gtirloni 4y ago
        You can argue that their client is not as good as it could be, that you have greater skills to deliver a better product, etc. But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far.
        tadfisher 4y ago
        > But it has value, otherwise we'd all be using curl to access the Slack API with no downsides. That's clearly not the case by far. Only because it's next-to-impossible to call the API, because of the way they lock features to their client!
- tumult 4y ago
  Author of Ripcord. You’re wrong, and creating and using software compatible with services is fair.
  - chii 4y ago
    i do agree it's fair, but it's also true that the service provider could argue that they are supposed to be in total control of the service, including the front-end. It's by societal consensus that this can be made fair, and to convince people that it is fair, there needs to be a logical, indisputable argument that it's fair. Otherwise, the service providers can always just hide behind the counter-argument of being in control and TOS etc.
    - tumult 4y ago
      In the case of Discord, for example, the terms of service doesn't even mention third-party clients. Also, these services are accessible from web browsers, which are made by third parties. There are more reasons, like users being able to run whatever they want on their own computers, but just the ones above are enough.
      - gtirloni 4y ago
        "You may not copy, modify, create derivative works based upon, distribute, sell, lease, or sublicense any of our software or services" This seems to make it pretty clear they don't want you to create 3rd-party clients for their service.
        tumult 4y ago
        Ripcord isn't a derivative work, both practically and in the legal sense. It's implemented from scratch. Ripcord isn't a resell of their service or a sublicense of their service.
        gtirloni 4y ago
        If I rephrase it like this, does it make it clear? "You may not create derivative works based upon any of our services"

Perseids 4y ago

I assume your argument is that Slack has the "freedom of contract", the right to create and offer you contracts of their choosing (and you are free to accept or decline them). That right is not absolute. Workers rights limit it, sanctions limit it, cartel and competition laws limit it. There is no reason society can't agree to limit the options of keeping an API locked down in such contracts, especially for well established companies like Slack. And I think the advantages of such a law are very clear: More competition on front-ends could very likely create much better user experience (better organization of chats, better message and image editor, better notifications, show users whether messages have actually been sent). Laws are made to serve the public [1]. Being nice to companies is a means to an end, not the goal itself, and the discussion about whether API should be legally accessible to third party vendors (or devices/cars/… should be legally repairable by third party repair shops) should focus on whether we get better user experience, service, and so on, and have the question of whether companies will still want to offer backend-service like Slack under such a law as a facet. [1] At least they should be and everybody complaints when they aren't.