I don't understand this project. According to the creator, the purpose is "to make Skype open source" [1], but the project relies on binary files distributed by Skype. As a result, they have repeatedly faced DMCA notices [2] which regularly causes the source code is become unavailable.
I don't believe that this is (despite stated intent) making Skype "open source". It would be more accurate to say that this work makes it possible to create an open-source wrapper around a proprietary kernel. This wrapper could then be updated as times change to support different platforms, as long as the linkage to the kernel was compatible. This neatly steps around some legal problems because:
1) The wrapper itself is not encumbered (unless some patent issues applied)
2) Users with a legal copy of Skype on one platform can apply the wrapper themselves (though they cannot redistribute the result)
You can even imagine distributing (via, say, github) a kit consisting of the wrapper and a tool that applies that wrapper to a user-supplied Skype binary. All legal as far as I know (IANAL etc.)
Clean room requires that those creating the implementation don't have access to the original implementation. Having the same person(s) inspect the binaries and create an implementation fails this requirement.
But how can you test if you protocol/document correct?
Yes, Epycs code may have question about legit and some other stuff. But after it going to a beta or stable stage. We can use Epycs protocol documentation to write, for example, epycs.java and make it fully "clean room".
What's required (for purposes of courtroom defense) is a clearly documented procedure in which those who have access to the source being reimplemented (the spec writers and testers) NOT be the coders, and vice versa.
Another example is the SMB/CIFS reimplementation in the case of Samba. Here, because the protocol was an over-the-wire system, analyzing network packets (not covered by source analysis proscriptions) was sufficient to create a Free Software implementation.
Describing just one part of it could be sufficient to sue, but not sufficient to develop a client.
Software patents are intentionally vague, so I doubt anybody could write a working client based on a patent alone (even if whole protocol was claimed to be described).
You are probably correct, but this is an abuse of the patent system, since the quid pro quo for patent protection is the disclosure of the invention to advance the state of the art.
I cannot speak for dr_rezzy, but I wouldn't be surprised if the Skype network experienced more spam following a reimplementation of the Skype protocol. Having control over the behaviour of every client allows Skype the company to more tightly control the behaviour of the network, including automated/bulk messaging. A client that can be freely modified/scripted makes it harder to restrict/filter automated behaviour e.g. spam.
Yeah... I don't really understand what their issue is to be honest. It really is up to Skype if they want to release their protocol. You can't really force anyone into being open source. I actually disagree with their methods, its the same as a closed source company violating the GPL when they steal source code like this.
Reverse engineering has given us so many good things - Samba, OpenOffice, Wine, MAME (and other emulators) the bitkeeper debacle, which gave us git. Then there are all the Linux and UNIX drivers that were written by reverse engineering windows drivers because vendors weren't supporting those operating systems.
The guys who reverse engineered Exchange Server were acquired by Cisco.
I don't understand why the Skype case is 'evil'. distributing the binaries may violate terms of service, but it isn't illegal in large parts of the world.
In one sense, I feel "The Open Source Movement" have co-opted a plain english two word phrase.
Their introduction there can be rewritten as "Open source doesn't just mean the source is open. We claim there are also implications about the means of distribution."
It's as though someone was telling people "free beer" doesn't just mean beer that's free, it also needs to be in glass not cans - free beer in cans needs to be called something else…
I think there's a lot of "open source" software out there that is not "open source(tm)". I'm not sure "the open source movement" are doing themselves any favors by aggressively defending their particular definition of a descriptive phrase that is widely known and easy to assume you understand.
(But I also understand the need for specific technical meanings in the software field, and that phrases like "open source" end up being part of the field's jargon, and have far more specific technical meanings than the "plain english" deconstruction of the words indicate. I just think the "open source" case has backed itself into a corner where people assume a plain english interpretation of the phrase, then have the "open source movement" people need to jump on them and say "no, you're wrong". As displayed upthread.)
I don't believe that the term "open source" was in common use at all prior to the phrase being deliberately coined in a strategy discussion in 1998 http://www.opensource.org/history
I think it's rather natural to think that something called "open" can be used, not merely looked at. I think it's also natural to emulate what is observed. If I can't use what I learn by observing something, what's the point?
I understand the opposing view, which claims it's natural to mean "look but don't touch" by "open". I'll grant that it can be a plain english interpretation. But it's an interpretation that violates the instinct of the observer.
That's not the usual use of the term in tech. Even Microsoft, after some initial confusion, has settled on using "shared source" rather than "open source" to describe situations where they share the source but not under an open-source-definition-compatible license.
An earlier blog post made it to Hacker News. I found the comment at http://news.ycombinator.com/item?id=2611728 insightful.
[1]: http://skype-open-source.blogspot.com/2011/06/skype-protocol...
[2]: https://github.com/skypeopensource/skypeopensource/issues/1