Hacker News new | comments | show | ask | jobs | submit login
Ask HN: I wrote a Slack compatible server. Can I open source it?
101 points by sysk on May 22, 2015 | hide | past | web | favorite | 53 comments
I had to implement a chat server for a project I'm working on and since I had never done this before, I used Slack's documentation as a roadmap and ended up re-implementing pretty much their whole API (I went a bit overboard I know).

I would like to open source this code but was wondering if it was legal for me to do so or would I be infringing on Slack's IP.




In general, re-implementing a software product from open specifications has been protected by the courts. There are numerous examples, from the original IBM BIOS to Microsoft BASIC to PostGres and BSD Unix. That said, the Google case is casting a shadow on programatic APIs, but 'look and feel' are essentially fair game.

What are protected and protectable are Trademarks. So using the word 'Slack' in the name or anything that looks like it came from the Slack web site (see the recent "Open Trello" flare up) will cause you legal issues and should be avoided entirely.

The most interesting "middle" case is if you want to host third party integrations which work on your system and Slack's then you're going to get some push back. But again, caveat things like patents, being enough workalike (or my favorite phrase bug-for-bug compatible) is well trodden and has consistently been shown to be ok. (see the latest Keurig fiasco for that!)


I'd like to add... the key test for trademarks is whether or not the use will cause confusion in the marketplace as to the origin of the product.

So calling something "Open Slack" would almost assuredly not be fair game... while claiming that the product is "mostly compatible with the Slack API" would probably be fine, especially since it almost self-evidently implies that the product is not Slack.

In any case, best to tread lightly with the use of their name at all, and certainly don't use it for marketing or promotion. Unlike patents and copyright, the only way to obtain and keep a trademark is to use it and defend it, so companies are rightfully aggressive in that regard.


Can you share more info on the "Open Trello" thing? I didn't hear about that and it sounds interesting to see how it was resolved.



I'd do it, but keep the references to Slack to a minimum. So, don't call it "OpenSlack", for example. Just give it a nice name, mention that it's Slack API compatible and you should be fine. At most, I suspect they'll just C&D you and then you say sorry and take it down. I can't imagine you'll get in any trouble.

Not a lawyer though.


I'd agree with that except the part about mentioning Slack compatibility. I wouldn't mention Slack at all without their permission.

Since the OP says that this is for another project, they might get not only a C&D for the chat code, but the original project might be infringing as well. Even if it's not actually infringing, it might result in some legal fees.


APIs themselves aren't copyrightable, as we saw in Google's recent lawsuit. The documentation is though, so be sure you're not infringing on that.

Any license agreement you or your company have with Slack might "ban" you from doing this; you might e.g. lose your access. That will be a contractual matter between you and them though, not anything criminal.

IANAL; you should probably get actual legal advice.


>APIs themselves aren't copyrightable, as we saw in Google's recent lawsuit.

The most recent ruling said that APIs, by themselves, are copyrightable[0].

The case is back to the district court now to determine whether the wholesale copying and reimplementation an API falls under the fair-use defense.

[0] https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google...


Google however are trying to take the case to the Supreme Court to get that API ruling overturned. IMHO they will succeed, as the federal circuit's ruling is controversial to say the least. I doubt there's anything to worry about here but strictly speaking, we'll have to wait and see.


That cases raises an interesting precedent issue that I have not been able to find the answer to. Let's assume that the Supreme Court decides not to take the appeal, so the decision of the Court of Appeals for the Federal Circuit that APIs are copyrightable stands.

What courts is this precedent for?

Generally, the way precedent works is that if appeals from court X go to court Y, then the decisions of court Y are precedent for court X. If court Z is not on the appeals path from X, then the decisions of court Z are not binding precedent for X.

For copyright cases, appeals normally do NOT go to the CAFC. They go the Courts of Appeal for the circuit in which the court appealed from resides. E.g., copyright cases from district courts in the 2nd Circuit go to the 2nd Circuit Court of Appeals.

In general, that is the appeals path from the Federal district court. Copyright cases aren't specifically singled out.

Oracle vs. Google was tried in the 9th Circuit. If it has just been a copyright case, the appeal would have went to the 9th Circuit Court of Appeals. However, it was also a patent case, and patent cases are singled out. They are explicitly diverted from the normal appeals path and go to the CAFC. If the case is also some other kind of case, such as a copyright case or an antitrust case, the CAFC is allowed to hear those aspects too.

So does this mean that if P sues D in the 9th circuit over copyright, with no patent issues or any other issues that would bring the appeal to the CAFC, then the district court would only use the 9th Circuit Court of Appeals for precedent (which I believe disagrees with CAFC), and ignore CAFC's Google vs. Oracle copyright ruling?

Even more confusing, suppose P sues D over copyright and patents in the 9th Circuit. The district court figures that the case, if appealed, will go to the CAFC, and so follows CAFC precedent for the copyright aspects. Now suppose after the court rules, neither party appeals the court's decisions on any of the patent issues. The only appeal copyright issues. Does the case still go to CAFC? Or does it go the 9th Circuit? If it goes to the 9th Circuit, do they apply their own copyright precedent or CAFC precedent?


Depressing indeed. Are there any other open source projects that are API compatible with a proprietary product/service? Is it ethical? I feel like it is but would be interested to hear HN's opinion.


A blackbox implementation (no access to original source code) is clearly ethical. The purpose of an API is specifically to allow interoperability with software that you don't write; the presence of a competitor (open source or not) who re-implements the server side of your API is a Good Thing for a competitive market place.


to extend on that idea, I'm fairly certain that a "clean-room" reverse engineering of a competitor's product HAS been shown to be legal. That is to say, as long as you can prove that the person(s) doing the reverse engineering didn't have any access to proprietary information about the workings of the product they were reverse engineering.


The classic example is the reverse engineering of the IBM BIOS for 'IBM compatible' machines. And it was done with 2 teams, one analyzing and one implementing.

But that predates my existence :-)


Which is why the appeals court decision was so shocking.


Linux is a reimplementation of proprietary Unix interfaces.

WINE is a clone of the Windows API. ReactOS is another one.

Also, we should include implementations of software that encodes or decodes data formats, such as audio/video/image codecs. There are numerous examples of free implementations of software that works with proprietary formats, which are analogous to a proprietary API.


Several open source cloud projects (OpenStack, Eucalyptus, CloudStack, OpenNebula) implement the Amazon EC2 API. Eucalyptus is the only one that formally obtained a license from Amazon.


As far as I know, AWS Aurora (not open source) is supposed to be a 100%-compatible implementation of MySQL API.


Errbit is API-compatible with Airbrake

https://github.com/errbit/errbit


Can't they use something trademarked in the api? for example you have to send 'Slack chat connect' to connect the api so open source stuff can't connect without violating their trademark?


AFAIK trademarks don't work that way. You can "use" a trademark in a text or computer program more or less freely. What you can't do is do business under the trademarked name, or offer a competing (or substantially similar) product for sale that uses the trademarked name. Trademarks aren't so much about "IP protection" as they are about preventing consumer confusion, thus the standards are different. IANAL.


Trademarks are about IP protection, but the exclusive right in the mark -- the thing that is property -- is the right to use the mark to market products in a particular domain.


Makes sense, then maybe this would prevent him from listing slack anywhere on the repository as it might confuse users that this is a legitimate client.


It's a matter of degree. CentOS infamously chose to refer to Red Hat as "a prominent North American Linux vendor" and completely deleted the term "Red Hat" from everything out of an abundance of caution after receiving threats from Red Hat's lawyers, but that's probably overboard. It's generally allowed to use trademarks as "nominative uses", i.e., in direct reference to another's product that's not designed to create confusion. He would probably be fine to put in his README something like "An open implementation of the chat API provided by Slack". He definitely shouldn't use the term "Slack" in the name of the repo.

Like most non-flagrant potential IP violations, no one can really say for sure until a court hears the case and makes a judgement as to whether the use is fair or unfair, or likely to cause confusion among consumers or not.

IANAL.


This is something Apple does in their 'DSMOS' (don't steal Mac OS X) code (but they use copyright, not a trademark).

Mac OS X looks for a set of firmware variables containing a non-formatted version of following haiku (reproduced for the purpose of artistic comment):

    our hard work 
    by these words guarded
    please dont steal
    © Apple Computer Inc
If you shipped a transparently Mac-compatible x86 machine, you'd have to include this haiku (in some form) in the firmware.


Sega tried this to prevent third party games from running. It didn't work: because their string was required for functionality, it wasn't protected by copyright. See http://en.wikipedia.org/wiki/Sega_v._Accolade for details.


Serious question: if I made a computer with the purpose of booting Mac OS X, noticed that it aborted after trying to read some bytes from the firmware, then wrote a program to iteratively test longer and longer sequences, would I be committing copyright infringement? What if I never look at the output of the program as text, but only as hex values?


IANAL, but speaking generally, the courts seem to take a dim view at technical workarounds, and instead focus on the actual intention and result.

In this particular case, I believe what you would have produced would be classified as a "circumvention" device under the DMCA (https://en.wikipedia.org/wiki/Anti-circumvention).

The state of "IP" law makes me very sad.


Cute. I remember some anti-spam outfit trying to "protect" emails with a copyrighted poem in the headers: http://www.oblomovka.com/writing/habeas%3A_the_antispam_haik...

I wonder how far back in OS(X) it dates?


It was introduced as part of the Intel transition, prior to public release.

Internally, Mac OS X ran on commodity PCs for quite some time before that and didn't include DSMOS.


If GNU is copyleft, is this then copy far right?


That's bloody depressing.



IANAL but I don't think API compatibility is infringement[1]. At least, I've seen projects that advertise this as a feature - for example, errbit[2] is API-compatible with Airbrake.

[1]: https://en.wikipedia.org/wiki/Application_programming_interf...

[2]: https://github.com/errbit/errbit


That's because AirBrake made their plugin open-source. Errbit was making their product api-compatible with an open source project.


If you do open source it, don't use Slack in the name


That's really the key.

Recall CentOS before RedHat was brought back into the fold. RedHat was always referred to as PNAELV, a "Prominent North American Enterprise Linux Vendor" to avoid running afoul of trademark issues.


What technologies did you use? XMPP? Node? ... I don't think your are infringing any copyright as long as you are not making profit from it. Reverse Engineering is legal, specially when done with the aim of interoperability... and what you are seeking is an interoperable server right?

http://en.wikipedia.org/wiki/Reverse_engineering#Legality


Ah, interesting question. I had never implemented a chat server before and initially read the IRC/XMPP specifications but Slack felt like a "superset" of both (federation/p2p wasn't a priority for me) and I was more familiar with web protocols.

The stack is Node.js and PostgreSQL (I probably reinvented some kind of message queue). There is a "dumb" websocket server that just receives/sends events from/to the backend server. Both the websocket and backend servers can scale horizontally.

I haven't written any XMPP/IRC gateways for now though I suppose it wouldn't be that difficult to do.


Fun. From everything noted about Slack, thats all they've got as their 'core' as well (PHP/MySQL I think, with maybe nodejs websockets).



Profitability has nothing to do with determining copyright infringement. For example, if I made a soda called Coke+ and gave it away for free, I'd still be infringing.


That's not copyright infringement it's trademark infringement... In this case if the author were to prominently mention Slack, then they might also be afowl of trademark.

Beyond that, there's still some gray area, legally speaking, with concern to the API interfaces themselves being either patentable or copyright... not even just the documentation of.


Slack is pretty much just IRC with an indexer, a pretty web interface, a mobile interface and a bunch of of cool datafeeds/bots. These things aren't hard to build, and many people build them internally in companies all the time.

Their value proposition isn't the technology, their value proposition is the packaging. It all just works. People actively maintain the interfaces and the GUI. They have ops teams that keep it up. The integrations are maintained and are literally plug and play. You can pretty much just sign up and within an hour its all done for not much money.

For these reasons, I have doubts as to whether or not they'd mind, regardless of IP concerns.


No clue where you're based, but in the EU, this is legal. You are allowed to replicate and reverse engineer systems, as long as you do not use the original source code.

APIs/functionality/data models/etc can't be copyrighted (again, in Europe). See http://www.bloomberg.com/news/articles/2012-05-02/copyright-....


You could ask Slack if they would mind you open sourcing it?

Just make it clear that the only reference to Slack is when you say its "Compatible with the Slack API".


IP can be broken down into its constituent parts. Patent, Copyright, trademark, and trade secret. The rules for each are different and sufficiently complex that the question should be treated as these four parts.


Without a lot more information your question is un-answerable.

For one, the jurisdiction that you're in is critical, for another the process is in some cases as important as the end result.

You should consult a lawyer that you pay for.


Did you manage to connect the regular Slack client to this? Is it enough to redirect the traffic to "myorg.slack.com" wherever your daemon is running? That would be kinda neat.


Host it in China and advertise directly to their current customers.


talk to an actual lawyer


For a solid advise, talk to a lawyer.


If you would like to use it as a reference, and dont want any sort of troubles, make sure it does not reach mass adoption. Some exotic build instruction or complicated deployment will do.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: