Slack

Mark Miller: 

We’re choosing to talk about Slack because virtually every technology company is using Slack. It’s ubiquitous. It’s almost like de facto standard for communication. 

One of the things that I found, and maybe you appreciated this too, is when I went through the documentation, which is just pages and addendums, whatever. But it’s not legalese. It’s not legal jargon, which I very much appreciate 

Joel MacMull: 

First of all, let’s talk about the manner in which it’s drafted. To their credit, a lot of it is very much in plain speak. Sometimes when you’re going to talk about the exclusive jurisdiction in which a litigation can arise, it’s going to get a little legalize. That’s just the nature of the business. But to its credit, it’s very much written in plain speak, and I think it’s digestible. It suffers from, I think, of this kind of “incorporated by reference herein” and then those incorporations then leading back to no less than I counted five separate agreements.

Mark Miller: 

I’ve got ’em listed here. Yes. 

Joel MacMull: 

Yeah, that they set out in separate hyperlinks. The more I read these and I joked about that, there’s something here from a legislative perspective that needs to be addressed. Because you can imagine just how unruly it is to go from main document to sub link to maybe back to the main document, perhaps to another sub link. As users, I believe at least we’re entitled to understanding the four corners of a single document that may govern my relationship with these various platforms, particularly when they involve the surrendering of my intellectual property rights and for that matter, an intrusion into my privacy.

 I understand that that’s the trade off for using these platforms, and I’m willing to play with you. But tell me in a understandable, coherent fashion what the terms of engagement are. That’s all I’m asking. 

Mark Miller: 

One of the terms that I came up with to try to get a picture of what’s going on, I’m going to start calling this, it’s fractal documentation. 

Joel MacMull: 

Fractal documentation. That’s nice. and it does seem should I change my last name to Mandelbrot?

Mark Miller: 

Fractal documentation defined as each branch of a document leads to at least two, if not more branches of extension of that document. It’s in some instances, even with Slack, where we complimented them on clarity, when you go to something like their privacy policy and there are 15 extended individual sections in the privacy policy. And within those, are links, you start to get the idea of how fractal this thing is. 

Joel MacMull: 

I don’t know enough about fractal geometry to know that it one necessarily leads to two, but I do get it as a concept. I think That’s a great way to describe them, at least in my limited understanding of fractal geometry. So good on you, Mark. 

Mark Miller: 

I’m going to start here with this because I want to read what they said when they said, okay, first things first. They actually say that in their documentation. 

These user terms are legally binding. Okay? If you can get through all this stuff, I guess it’s legally binding, but I’ll come back to the same point that you and I talk about in every show. If it’s not possible to consume this because of the quantity and how it is laid out, how much of this is legally binding?

Joel MacMull: 

I don’t think volume can ever be an excuse for a lack of enforceability. You can’t say there was too much. Or you can say it, I just don’t think it’s going to carry the day. I think the better argument if I were a plaintiff’s lawyer, as I sometimes am, at least as it relates to these policies is, there is not a clear expression that allows me as a participant on these platforms to understand that which is being asked of me. 

Slack, very interestingly is saying you user are essentially the guest of the customer. And the customer, so says Slack, is the one and only entity with whom we as a company are contracting. 

So to put it a little differently, if you are a user and you’ve been invited to someone’s Slack channel as we all have, you have no rights vis-a-vis Slack, the entity. So says Slack, your sole remedy is against the customer for all things including a misuse of your data. We are just essentially the vehicle by which you may be transmitting that data, but we don’t have any skin in the game. So it says Slack.

I’m making a couple of assumptions there. I’m going to assume as a user of these platforms, to be distinguished from a customer, at least with respect to the way Slack has articulated the relationship, is that I’m presumably going to take issue with something that they’re doing with my data.

 My argument would be that notwithstanding Slack’s efforts to disclaim liability and say at the end of the day that any disagreement between me as a user and my customer host, I could imagine, I’m sure there are crafty plaintiff lawyers out there that will do this if they haven’t done so already, that will make the argument that no Slack knew or should have known of the customer’s use of my data or the manner in which it was being used or misused and therefore may not disclaim liability as it attempts to do in its user terms of service. We’ve talked about that, the way Slack, divides and conquers between customer and user I thought was really interesting.

And by the way, this plays out throughout the agreement. you know, If someone is now going to the agreement after this discussion, and then we look at limitation of liability. it says as much. The first sentence reads in relevant part, if we believe that there’s a violation of the contract user terms, the acceptable use policy, or any of our other policies that can simply be remedied by customer’s removal of certain customer data, or taking other action, we will, in most cases, ask customer to take action rather than intervene.

And that just underscores its entire business model, which by the way is consistent with every other platform we’ve looked at. You talk about Amazon and brand registry or something like that. Amazon takes the position if there’s a dispute as between two purported trademark holders we’re out of it. 

Mark Miller: 

Along those lines, talking differentiating customer types, one of the things that they say… and this is in a headline, “this is not intended for consumer purposes.” That is a cover your ass statement because they follow that with, “Slack is a workplace tool intended for use by businesses and organizations and not for consumer purposes. 

The reason they define consumer? “To the maximum extent permitted by a law, you are hereby acknowledge and agree that consumer laws do not apply.” 

Joel MacMull: 

Except where they do, of course, and Slack can’t opt out of it. the example they give is Australia. The Competition and Consumer Act of 2010, precludes an entity position like Slack, namely, I’m assuming any entity including those on the internet from opting out of that. Therefore, there is a kind of mandatory consumer protection law that applies. 

Mark Miller: 

Slack has the ability to add plugins that will hook you up to a Trello board. It has things that you can hook up to Zendesk, so you could actually be running, your issue tracking system through Slack. How far do these terms of agreement go when you’re using plugins? Again, fractally to reach out to other systems. We’re going to spitball this thing. Sure. So I’m going to hook it up to Zendesk, which has all of my issues, my tracking issues of things that are going wrong, the stuff that I’m working on. 

When I’m using Slack to actually expose those issues within Slack that are coming from Zendesk, at what point do I cross the boundary to say, now you are in Zendesk’s terms of agreement. This has nothing to do with us. That’s the dilemma I see with having an extended use of plugins that pull in your whole system of management and just integrate it using Slack as a dashboard.

Joel MacMull: 

Not exactly my wheelhouse, but I think from a data privacy perspective, I find that really interesting. Zendesk is actually a perfect example because I have some clients that are running their customer service quality assurance, management through Zendesk.

So to your point, you phrased it beautifully. Where does the Zendesk begin and the Slack and or vice versa. And as we both know, the more portals you have, the more opportunity you give to bad guys to infiltrate your system and harvest data that they shouldn’t be touching.

 It’s a really interesting perspective because, and it gives rise just off the top of my head to a couple of different issues. 

Number one is what is the cybersecurity plan that a company similarly positioned, like the client I just described. has in place for something like that. We know that if there’s not already law, there’s certainly good practices that there’s a notification requirement. I need to now notify the customer but my understanding is regardless of whether or not the data breach that’s verified I know today implicates my client’s data, good corporate practice suggests in 2023 that I should nevertheless be proactive about it and advise my client that there is a potential, a mere potential, for the unauthorized access of their data.

 The other thing that this raises from a lawyer’s perspective, at least mine, is what does this mean for your cybersecurity insurance? Certainly any company worth their salt these days has a cybersecurity policy that is designed to safeguard against the kinds of breaches we’re talking about.

The question becomes though is your carrier or is even your broker, but your carrier, aware of all of these various data entry points we’re talking about. The synapse, if you will, between Slack and Zendesk in the manner in which you’ve described it. I have been involved in procuring cybersecurity insurance, and there’s a whole host of disclosures that has to go on. But if that’s constantly changing at the speed of light, in terms of, to your example, you’re adding plugins on day one and you’ve got, something in the hopper on Monday, you’re adding something on Friday, are you keeping up with your cybersecurity disclosure requirements to your carrier? Or are you, unfortunately, essentially eviscerating your policy? Because either you’re going beyond the scope of the policy or you’re not keeping them updated. Both of which, by the way, would be a position for your carrier to turn around and say, sorry to hear that, but we’re not covering you.

So that million dollars that you just spent on a premium, sorry. It’s money down the drain. 

Mark Miller: 

I want to roll back a little bit to customer responsibility Customer responsibility, that’s a big heading in there and it says you agree that it is solely the customer’s responsibility to inform you and any authorized users of any relevant customer policies and practices, blah, blah, blah. 

What they’re saying at that point, I think is what you just said, which is Slack is saying, got nothing to do with me. The customer is responsible to inform everybody that’s using their channel. 

Joel MacMull: 

That’s right. And I had to actually read that provision a few times because I wanted to, I was surprised by it. and not because it does anything wrong or anything, but because it, as I said, it shifts the entire burden really on the use and collection of data back to the customer and takes it away from the platform.

Mark Miller: 

It’s funny, the perception though, Joel, is that if I’m using Slack myself, I think of myself as the customer. 

Joel MacMull: 

Yeah, exactly. Of course. So do I. So do I not withstanding the fact that you are running a channel and you might invite me, that doesn’t in my mind either, as a consumer alter the framework in terms of my understanding of like I, I think frankly we’re just a couple of kids hanging out and we’re both using Slack. Yes. Thank you for the invitation and I am glad to be part of the conversation, but I don’t appreciate, or certainly not instinctively, that there’s a legal difference in terms of your relationship with the platform and my relationship with the platform, which by the way, as a user, right as we go down this daisy chain as a user, because I’m, quote unquote at the mercy of your invite.

Mark Miller: 

In order to participate on Slack, I have to sign up through the Slack interface and Slack has all my information in order to allow me to access the channel I was invited to. 

Joel MacMull: 

…or put differently, I have to accept Slack’s terms of service to participate, in which they are then saying, by virtue of me accepting their terms, that your only recourse at the end of the day is to the guy that or gal who invited you. 

I understand why you say you disagree with it. It’s certainly interesting. I can’t say that there’s anything wrong with it other than it’s unusual. It’s not the way I’ve ever read the dynamic between parties before and the kind of bifurcation that exists between customer and user in the agreement is really an interesting one. It creates burdens and responsibilities that I am sure, as we’ve often said on the show, that users of the platform are entirely unaware of. No doubt, because they haven’t read it, but again with respect to those laypersons, even if they did read it, wouldn’t appreciate those distinctions. 

Mark Miller: 

I want to clarify that Slack is different than the other apps that you and I have been talking about in other shows. Slack is actually for business. It’s stated as much. This is for businesses to manage communications.

 If you are going to be using this for business, I would expect that you would have legal look at this before you allowed your company or organization to use it. As opposed to if this is an app that I’m putting on my phone, then the onus is on me to understand what’s going on.

I’m thinking that because this is business software, there might be a much more likelihood of it actually being read and analyzed the way you and I are doing it because it’s business related and going to hold business data. 

Joel MacMull: 

I think you’re right. I think those businesses that are savvy enough before they put it on their systems are going to, if for no other reason, as I mentioned, to make sure that it dovetails with their cyber insurance policy. or they’re, they’re head of whatever you want to call it, that is in charge of these kinds of things, new product development, whatever, are aware that there are implications in signing this up. I don’t know, I don’t know is general counsel, even at a, a thousand person business looking this over? Probably not. My guess is it falls to IT in a lot of these sort of mid-market companies.

IT is going to say, Hey, here’s something that they may have fallen in love with, right? It’s a tweak on teams. They like the interface better. To your point, it’s got more functionality. They might be pushing it and the next thing you know, the company is rolling it out.

 Depending on the background of general counsel, which certainly there was a time, I’m not so sure this is the case now, but there was a time maybe in 5 or 10 years ago where, if you’re general counsel at a mid-size company, you’re going to be far more, I suspect you’re going to be far more in tune to employment and labor issues as it relates to, regulatory work. You may not be so savvy when it comes to, the, I guess the repercussions, the technical repercussions and the data breach issues that may arise from essentially bringing this tool on board.

Mark Miller: 

It’s a problem with any company when you’re rolling out enterprise software that, the legal aspect of it, if you’re using it for business, I would look much more closely at it than I would if it was for an app. In the, acceptable use document they have 22 bullet points of things you cannot do. This is one of the things that got you and I started here, is when you have a litany like this, when you have so many caveats, when you have so many things that are outlined like this, at what point does the user’s eyes glaze over and say, screw it. I’m just going to hit the accept button.

Joel MacMull: 

There’s a really interesting, and it’s a little legally, it’s a little legalese and it’s a little nerdy, but when I read these, a couple of things jumped out at me. and of course they’re not numbered, right? So they become difficult to reference.

I noticed that right away. Yes. Yes. 3, 4, 5, and look at five. 

It says you may not attempt to reverse engineer, decompile, hack disabled. Which is your standard kind of confidentiality, non-disclosure stuff. Under the Trade Secrets law in this country, there’s nothing wrong with reverse engineering something. That’s exactly why we bake it into the contract is because the contract and the provisions in the contract are going to restrict you more than our common law otherwise would. 

But what’s interesting is the one that’s two more down, which reads in its entirety, “access the services in order to build a similar or competitive product or service or copy any ideas, features, functions, or graphics of the services.” 

It’s the first part of that I’m troubled by. 

Mark Miller: 

That’s where I come to you as a lawyer and say, is this really enforceable? That specific part.

Joel MacMull: 

There’s two competing interests, right? It has to be broad enough that it would presumably capture everything that Slack wants to basically put in that bucket. Because if it’s too narrow, then the crafty lawyer like myself is going to say, get outta here, it falls outside the scope of what you were trying to limit. The problem is, you can imagine this, that if I’m creating another tool that tangentially is similar or competitive… Do you see how broad that is within the context of this? That could conceivably be anything.

 Our contracts also have to be specific. It has to be very clear as to what’s allowed or what’s not allowed. And what I found very interesting here is it’s basically saying Slack is saying you shall not use our widget to build a better widget. If Slack were to take the position that provision is somehow enforceable, yeah, I’d have a lot of issues with it and I can imagine there being a number of arguments that could be made to suggest that’s unenforceable, not the least of which is, and again, there’s a long way to, you’d have to prove this. Okay. And the devil’s in the details, but not the least of which is it is an anti-competitive argument that arguably runs afoul of our anti-trust laws.

Now to establish an antitrust claim, there’s lots of things we’d have to establish as a wouldbe plaintiff, including that Slack has quote unquote a definable market. That it has exclusivity or dominance in that market. All kinds of like legalese things we’d have to prove.

But the language is troubling and I think sets them up for more trouble than I think the provision is worth. 

Mark Miller: 

We can actually refer back to something that probably happened about 10 years ago when Amazon tried to protect the functionality of one-click. They said, this is something that we created, a one-click buying mechanism and somebody copied.

 the essence of the functionality, not by using Amazon’s code or anything, but just saying, Hey, that’s a damn good idea. Let me do something like that on my site. And Amazon, no, we own one-click. I think it is part and parcel of a movement that has been occurring over the last 10 or 15 years in the patent space, where method patents or business method patents that were once upon a time handed out as easily as business cards at a cocktail party, particularly as it relates to software, are almost nonexistent now. the, The American Invention Act, which is an outgrowth of a couple of Supreme Court decisions, there was a very famous decision, the Alice decision, which basically said at the end of the day, and I’m really, I’m not doing this justice, but said, if you have a software application that does not result in the better performance of hardware, it is not amenable to patent protection anymore, period.

Joel MacMull: 

Now you had the other side say, wait a second, that goes way too far. Software is so nuanced. You’re basically cutting off the head of development in this country. You’re not supporting entrepreneurs. We’re really doing ourselves a a disservice.

And that tension has consistently played out, certainly in some of the writings and in the court materials. It’s pretty clear now that, to your point exactly where you have an Amazon that is trying to lay exclusive claim to, one button clicking, so to speak, right? Like it’s an image and it says, buy now and you click and then it’s all processed. That’s dead as a protectable patent in this country. 

And I think, rightly so, although there are no doubt exceptions to that, and I could be convinced that, Alice maybe has gone too far. And I’m sometimes often reminded about that when clients come to me and say, I’ve got this concept, or I’ve got this software. Is it protectable? is it amenable to patent protection? And 99 point percent of the time, the answer is no, because it does not directly impact or otherwise enhance the hardware. 

Mark Miller: 

In general, how do you feel about the Slack agreement compared to the other ones we’ve looked at so far? 

Joel MacMull: 

The Slack agreement is interesting because as I said earlier, it creates obligations on the part of, users and customers. It also bifurcates the relationship between the invitor and the invitee. As someone using Slack who’s not operating a channel but rather is a participant in a channel, their user terms are worth looking at, so that you understand that your sole recourse, if any, including if you dive into all of the sub links that are layered in that agreement, is with the customer, meaning you are the person who invited you to the channel. 

Mark Miller: 

So let’s do a thumbs up, thumbs down for Slack, terms of agreement. Thumbs up, thumbs down. Neutral. 

Joel MacMull:

 I’m going to go sideways, to the extent that I’m being difficult. I’m going to go sideways. There are things to celebrate, but I also think there are things that, if I was general counsel to Slack and I’m putting these things together, I’d want to spend a bit more time defining and refining.

Mark Miller: 

I want to remind people that you’re a lawyer, but you are not their lawyer. 

Joel MacMull: 

…at least not yet.

Mark Miller:

Thanks for joining us for this week’s “You’re kidding me… that’s in my EULA??” We’d appreciate your comments on today’s show page, located at WhatsInMyEULA.com. You’ll also find information on how to get in touch with Joel. While you’re on the page, tell us what other EULAs we should investigate. If we use your suggestion, we’ll give you a shoutout in that episode.

“That’s in my EULA??” is published weekly. Special thanks today to Katy, that’s with a ‘T”, Kadi, that’s with a “D”, Edwin, and Tracy for the awesome voiceover work at the beginning of the show. Music today is provided by Hash Out from Blue Dot Sessions. 

We’ll see you next week.

This was a Sourced Network Production.

If you’re interested in talking with Joel about some of the issues in this episode, shoot him an email.

Joel G. MacMull | Partner
Chair, Intellectual Property, Brand Management and Internet Law Practice
(973) 295-3652 | JMacmull@mblawfirm.com