Microsoft sends GitHub DMCA shutdown for Skype open source project
github.com
github.com
No, that's not what "Skype Open Source" project is. This is a confusingly misnamed attempt to attach code to patched copies of copyrighted official Skype clients.
Microsoft is not overreaching here; this is what anyone would expect with a lame project like this. I'd love if someone really created an open-source Skype client, but this is not a project to do that.
Code in repo contains reimplementation of skype protocol (RC4 chiper, 41 and 42 encoders) and sample tool capable of sending IM to skype peer.
There also was some tools for extracting user certificate from skype profile.
http://recon.cx/en/f/vskype-part1.pdf http://recon.cx/en/f/vskype-part2.pdf
This was the method used by Compaq to implement the IBM BIOS, back in the day.
What part of A's work involves distributing deobfuscated binaries to the general public?
Team B should only have access to the specifications developed by Team A and nothing else from them. That's the whole point of isolating them.
So what? That's not a valid excuse to distribute modified binaries to the public. If the "first" team wants to look at binaries to do their documentation, they can download the official Skype client from skype.com. Why do they need to download a hacked binary from Github?
I understand the rationale behind it, I think it is wrong and has bad implications for the future.
No it doesn't.
The Wikipeda link[1] mentions the original IBM PC clean room implementation by Columbia Data Products.
It doesn't have the complete story of that, but from memory the way it worked was CDP had one team documenting how the BIOS responded to inputs, and then a totally independent team reimplementing that behaviour.
Most clean room implementation don't have access to a specification, let alone source code.
From the ruling: "Some works are closer to the core of intended copyright protection than others. Sony's BIOS lay at a distance from the core because it contains unprotected aspects that cannot be examined without copying. The court of appeal therefore accorded it a lower degree of protection than more traditional literary works."
Thus one could try to make the same case for Skype.
If I write a script that generates the Matrix movies from the binary file of, say, Elephant's Dream, I won't be allowed to distribute that.
For example, there is no reverse engineered libraries for Facetime and iOS API. If you use Apple's libraries, they can come after you for copyright infringement.
Linux is an independent implementation of the Posix interfaces.
Skype-open-source code here: https://github.com/skypeopensource/epycs
repo was closed because i host in download section deobfuscated skype5.5 binary, my fault.
That function right there (and the vast majority of the rest of the file) is a straight decompiled version from Skype. You even use the register names and comment with addresses from the binary.
Having spent a lot of time reversing apps myself, this is a straight copyright violation. Your code is a directly derivative work from Skype.
What about you talking? Maybe you need read dictionary definitions of words bull and shit. Pay copyright rent for this words, and stop trolling us.
MS will contribute nothing to the state of the art of free voice and video calls over the internet. As is so often the case, what they purchased with the Skype deal was a user base. One that they could never obtain with the own products.
There is a way to do this without violating copyright.
Do not waste time duplicating the P2P element of Skype (the P2P protocol). P2P protocols have been done, several ways, some of them are easily good enough, maybe even smarter than Skype's (e.g., avoiding the exposure of your IP to the entire internet) and enough of the code is GPL'd or BSD licensed to keep things open. We have ample solutions for P2P. View that as the "open platform".
Now you need "apps" to run on it. First one is a softphone, but with Skype's codecs.
Focus on creating a standalone softphone using Skype's codecs.
Does MS have exclusive rights (patent rights) on Skype's codecs? Not even close. They did not develop them. The patent license could fit on a single page; it's as simple as they come: build stuff, pay nothing.
The issue is how to tap into the existing Skype userbase -- receive and make calls to Skype clients -- from an open-source client.
But all VOIP codecs are not created equal. Skype's success is not due to NAT piercing. Even though Skype easy to use, maybe easier than previous SIP alternatives, if calls sounded terrible, people would not use it. Skype's success is due to being usable and having decent sound quality. They did not use the decades old codecs other softphones used. They wrote new ones. And anyone can use them.
Using the same codec as Skype uses should not in any way bind you to their network. It has nothing to do with compatibility. It has to due with getting Skype-level sound quality. Quality that the older codecs have failed to deliver.
It's easy to get people to sign up for free voice and video calls. The key word is "free". You do not have to find inroads into the "Skype user base". Skype spread by word of mouth. If people learn about another client that works as well or better (same sound quality), and it's easy to use, they will almost certainly try it.
Forgive me if I have misunderstood what you were trying to say in your comment. But I do not understand your reasoning.
https://github.com/github/dmca/blob/db9b442f0ac68512d0ca83fe...
(rendered into human readable)
anyway, my apologies, no disrespect, have a nice day.
Demand for Immediate take-Down: Notice of Infringing Activity URL: https://github.com/downloads/skypeopensource/skypeopensource...
Its not to repo code. Its for patched binary, yes.
Apparently he had already been served with DCMA takedown requests. And talks about deofuscation. Doesn't sound like a cleanroom implementación.
Is their IP worth the trouble? Do they see interoperability as a threat? Are they afraid of misbehaving clients?
Surely it's not just a case of a lawyer having too much time on his hands.
Feel free to study current implementation stage here - https://github.com/skypeopensource/epycs
As other have said, it's better to follow the clean-room process and define the specification. Then someone else can implement it in a legally safe manner.
The specification by itself would be an enormous contribution.
From http://lwn.net/Articles/357658/
And there's a lot in that tree. Google started with the 2.4.18 kernel - but they patched over 2000 files, inserting 492,000 lines of code. Among other things, they backported 64-bit support into that kernel. Eventually they moved to 2.6.11, primarily because they needed SATA support. A 2.6.18-based kernel followed, and they are now working on preparing a 2.6.26-based kernel for deployment in the near future. They are currently carrying 1208 patches to 2.6.26, inserting almost 300,000 lines of code. Roughly 25% of those patches, Mike estimates, are backports of newer features. .. Linus asked: why aren't these patches upstream? Is it because Google is embarrassed by them, or is it secret stuff that they don't want to disclose, or is it a matter of internal process problems?