Back in February a developer outside of Facebook sent a GitHub pull request which included this pull to refresh functionality. At the time we believed that the developer wrote the code themselves and thus didn't realize that it actually came from Shaun's open source library EGOTableViewPullRefresh. I'm sorry that we messed this one up. Three20 has over a dozen different contributors (http://github.com/facebook/three20/blob/master/AUTHORS) and we try really hard to give credit where it is due.
As for fixing this, the code clearly came from EGOTableViewPullRefresh and we're updating the four file's within Three20 to directly reflect that and link back to Shaun's project. This patch will be pushed to GitHub shortly.
While it isn't the most well known address, please always feel free to email opensource@facebook.com or me directly at davidrecordon@facebook.com.
I've used Three20 a ton, and actually build my Hacker News iPhone app using it.[1] I've used the drag-to-refresh header a bunch. This code was added to the Three20 framework months ago via somebody on GitHub. One pull request, and it was in the main repo.
The project is currently maintained by Jeff Verkoeyen, a full-time student. Three20 makes use of a ton of other open-source projects (JSON parser, etc.). Whoever submitted this code just didn't add any attribution. When Facebook updated their app, it was probably only 2-3 lines to add. And since it's been in the codebase for months now, and a bunch of other apps use it, they probably figured it was no problem.
Although flaming blog posts feel good to write, a much more constructive action would be to call up Facebook and talk to them. Or email Jeff. Or post to the Three20 Google Group (almost 1k people). Or submit an issue on GitHub. Or anything really.
Not to mention the fact that they stole it from Loren Bricher (Tweetie) in the first place...
<del>I hate to say it, but the current system (i.e. all commits through jverkoey) has the major drawback of putting code accountability in nobody's hands but Joey's.</del>
It's nothing more than Jeff Verkoeyen being the gatekeeper for the project's repo, the same way a tightly controlled SVN repo might be. He's supposed to review every line of code that goes into it, and the commit it himself.
But everyone knows thats a daunting task, and theres no reason to review a simple thing like this to question where it originally came from. Right?
Git is awesome, because it helps prevent these situations, but it's only a tool. Different people will use it differently, and based on the comments of the blog post, once he found out that it was copyrighted code, he rectified the problem. http://github.com/facebook/three20/commit/204673eea141acf4ee...
I'm not trying to pass blame, but I do believe that jverkoey never had the intention of stealing this code. None the less, Facebook.app ended up on the sour end of a situation they could have solved months ago, but they had no idea there was a problem until now.
agree that it would've been wiser to contact jeff directly before the press-friendly call out. jeff is straightforward, and this looks like an honest mistake.
Flaming blog? It seemed pretty tame to me. The worst thing he said was "not cool" and just asked to be credited for the work that's far from flaming. No threats, cursing, or ranting at all.
The majority of developers don't understand the nuances of copyright law; and, so OSS code is often mis-integrated and mis-attributed. I hazard most times an honest developer is informed of their missteps, they handle it similar to how we're seeing here.
"The majority of developers don't understand the nuances of copyright law; and, so OSS code is often mis-integrated and mis-attributed. I hazard most times an honest developer is informed of their missteps, they handle it similar to how we're seeing here."
What you just said, if it's true, is a problem.
The basics of copyright aren't hard (if you didn't write what you're including, you have to have permission to include it). Even dealing with the basic software licensing options (NewBSD/free-for-all/CC; OldBSD/free-with-attribution/CC-BY; GNU GPL/free-share-alike/CC-SA; etc.) aren't that hard (the CC folks have done a good job of coming up with easily understandable terms that capture the spirit).
It's not until you get into the real esoterica (largely in music and movies, IMO) that you have to really understand things at a weird level (I still don't quite understand where things went wrong for Sita Sings the Blues).
While this may be an easily fixed error, what should we be doing to make sure people "get" basic copyright law as part of the software development profession? More than that, what do we have to do to get people to think in terms of simple fairness: I should give credit to others for their work.
The basics are less simple than you indicate. What does it mean to have permission? Who has the right to give that permission? What happens if you include something because someone told you it was OK, and that person was mistaken? When is borrowing fair use?
It isn't just in music and movies that the weird stuff starts cropping up. (And that is before you get into the license debates. Or such subtle questions like whether it is better to treat the GPL as a copyright license, or to take steps to get a contract instead.)
No, there is nothing simple about this invented notion we call copyright.
I disagree. The basic rules for copyright are fairly simple. (If you include something because someone told you it was OK, but didn't do at least some minimal work to verify that it was in fact OK, then you have erred.)
Start from 'no' (that is, you don't have permission to copy something you didn't write). Even if you do have permission to copy something[1], you probably don't have permission to claim that you wrote it. Even if you do have permission to claim that you wrote it (because it's in the public domain), you would be a first-class jackass to do so.
The cases you point out are subtle, and were attempts to expand what copyright covers. (This is similar to the discussion some months ago about the copyright-ability of one's tweets, with the general consensus being that they cannot individually be copyrighted, but one's "tweet-oeuvre" would be. Single words and short phrases are too short to be individually unique.) Yet, neither of these cases change the basics (assume you don't have permission, don't try to claim what you didn't write as yours).
Fair use is a more subtle item because it's based on case law instead of regulation or explicit law.
I never said that copyright law wasn't hard, or that copyright issues couldn't get complicated quickly. But getting the start of things right? It's not hard at all.
Not so fast. If you include something that someone told you you could, that is a defense against copyright infringement if you are willing to take measures to stop infringing once you are informed of this. (This is the spirit, though not the letter, behind the DMCA safe harbor provisions.)
Secondly there are ways in which someone can write something, truly believe they own it, but actually don't own it. So the question of who has permission is not so simple.
Thirdly the cases I pointed to were arguments about what copyright already covered. There were good arguments both ways under existing legislation and previous case law. The right answer to those questions is based on existing case law, and is hardly simple. (I was caught by surprise when I learned that it was OK in the USA to take someone else's copyrighted binary, and reverse engineer what is pretty much their header file out of it, and include that header file in your own copyrighted work without any kind of attribution!)
Of those licensing schemes, which are compatible? There's the spirit and there's the complex reality.
This code, on my screen is copy-paste'able.
And it's 'open source.'
That means I can use it!
If it's an education issue, do we hit 'em in university? Primary school? Make a slick website: canicopyit.org?
wrt. to the "simple fairness," it's striking the number of people who have chimed in with (paraphrased), "How do we know it's copied? There can only be so many ways to write this!" That says to me the speaker doesn't write code, but rather puts it together.
And that's a group with very different motivation than you and I.
The three20 code has shuffled around a lot in the last 8 months or so, but if you look at the change log here http://github.com/facebook/three20/blob/master/CHANGES#L93 you can see that the maintainer, Jeff (who was a college student at the time and has worked his butt off on three20) is thanking a 3rd party for contributing that code.
There's attribution for other code in three20, so I think it's safe to say that Jeff didn't know.
It's also possible that there was simply a miscommunication somewhere along the chain. I wouldn't assume this is anyone being evil or devious until we hear the full story, and I expect the lack of attribution will be fixed quickly.
The files do essentially the same thing. So consider: is it possible that two development teams, implementing the same feature, will use the same style of implementation?
The code diff he presents seems to be UI code. How many ways are there to set a label's font? (though having the same exact pixel values is perhaps a bit odd)
The code is structured differently, named differently, and (to my untrained eyes) even appears to differ in some implementation details (such as setUpdateDate, which uses NSDateFormatterShortStyle, versus setCurrentDate, which uses its own custom format). Perhaps the author is simply feinting at shadows.
It's a bold claim to say that your particular implementation has been "taken" when this sort of open idea and algorithm reuse happens all the time. In this situation, I'm sure once the dust clears credit will be given where it's due.
Tangent: Who wants to guess that some of the HN commenters up-in-arms about this are some of the folks who are cry foul about software patents?
It's not about setting the label's properties in the exact same way & order (okay, that's also fishy), it's that they named all their UI elements the exact same names: _lastUpdatedLabel, _statusLabel, _arrowImage and _activityView.
I'm not sure why you said it's named differently, all the UI elements are named the same according to the screenshot they posted.
I wondered that, too, but if you go in and look at the projects, the pedigree is clear. Even if you're going to use a similar implementation style, the likelihood that you independently come up with the exact same instance variable names and initialize them in the exact same order is pretty small.
That said, this really seems like an out-of-proportion response to me. As much as I dislike FB, they're pretty decent OSS citizens. I think you have to give them a chance to make it right before throwing up a blog post.
The title is somewhat misleading since the author of the post (and also the coder of the OSS feature used) is not against Facebook using it on its iPhone app. He talks about how they use his code on their three20 library without attribution.
Yeah, that wasn't very polite. But... didn't they do exactly what the license asks of them? If you don't want people to be able to use your code that freely, then don't use such a permissive license.
Back in February a developer outside of Facebook sent a GitHub pull request which included this pull to refresh functionality. At the time we believed that the developer wrote the code themselves and thus didn't realize that it actually came from Shaun's open source library EGOTableViewPullRefresh. I'm sorry that we messed this one up. Three20 has over a dozen different contributors (http://github.com/facebook/three20/blob/master/AUTHORS) and we try really hard to give credit where it is due.
As for fixing this, the code clearly came from EGOTableViewPullRefresh and we're updating the four file's within Three20 to directly reflect that and link back to Shaun's project. This patch will be pushed to GitHub shortly.
While it isn't the most well known address, please always feel free to email opensource@facebook.com or me directly at davidrecordon@facebook.com.