Wednesday, July 09, 2008

The "Facebook" case: reviewing code "re-use" in the workplace and on campus; what about OOP? What about "reverse engineering"?


Recently on my Book blog I reviewed Aaron Greenspan’s “Authoritas” and talked about the “Facebook controversy” there (lawyers affectionately call it "The Battle of the Kids") and on my Trademark blog, too. The story is pretty complicated, involving Harvard, at least one company (Greenspan’s) and several former Harvard students. I would say that I hope it gets settled amicably and that the entrepreneurs can move on to better things, but there are some general things about the battle over intellectual property rights and Facebook that are fairly generic to many workplace.

In most corporate workplaces, it is very common for designs and code for modules or subsystems to be cloned and “reused” in other similar applications. Of course, some of the concepts of “object oriented programming” (inheritance) specifically address this need in practice, to come up with systems that have the minimum amount of redundant code to maintain. In practice, many older shops with in-house mainframe systems (largely in COBOL) have many jobs with code that was cloned from other programs and re-adapted.

Intellectual property rights generally don’t come into play right away with employees who are salaried, and whose compensation is just the salary, benefits, and 401K, and maybe some bonuses. The employer owns it all, and generally the code is considered a “trade secret” legally. Employers gradually started to pay more attention to their ownership of the rights to their code in the 1970s, even if employees sometimes didn’t yet grasp the legal issues; after all, employees sometimes took work home for legitimate work purposes and sometimes might want to reuse coding techniques (perhaps not quite legally) in other jobs after leving. But as companies (starting particularly in the early 90s) started using purchased software (like Vantage) the need for strict control over intellectual property rights, even getting down to copies of software manuals, started to emerge. Furthermore, when companies hire many W-2 consultants (which is so common now), there is always the possibility that a consultant could take code from one place and use it somewhere else. Often, in the past, work like this was done with a certain informality, which poses certain risks for both source code and customer data.

Before system designs were as wide open and used so many reusable components, ownership was relatively straightforward with PC software for home or office use. At work, licenses sometimes controlled how many computers or sub-installations a given copy (for a particular version, like architect’s or developer) could be used. (Java café was like that.)

In universities, professors often assign complex projects, and a good question would be who owns the solutions to assigned problems afterward. That issue could have complicated all the issues at Harvard as in Greenspan’s book (as well as the issues that he discusses, like secure and encrypted logons to his systems).

Many techniques in system design are likely to recur in various shops and repeat many of the same features. For example, a financial institution might run a legacy system, run replications to a mid-tier and have a OOP data access layer to distribute to end customer service users. There are pretty standard ways to design and write these data access layers regardless of the company.

People will work in companies or study at universities and work on projects there, and see opportunities to take what they have “learned” to launch global, extremely profitable ventures. It is not always simple to determine when what they deploy really came from someone else’s copyrighted intellectual property. It does seem like it is hard to determine what “fair use” means in the software world.

There are various cases to be found on the Internet. For example, a case with a Kansas software company Evolution, and some banks is discussed by Lauren Gelman on Stanford law school’s site here.

There is an interesting discussion on Findlaw by Chris Sprigman, dating back to Sept. 2002, about whether software vendors can enforce “boilerplate” licenses and prevent customers from “reverse engineering” their “shrinkwrapped” products for re-use in other areas. The link is here. There is an issue with whether states can pre-empt doctrines in federal copyright law with “extra elements” in order to protect the business profitability models apparently necessary for software vendors (and likely enforced by software publisher’s associations). This makes for interesting reading and I wonder if any of the ideas here could apply to the Facebook situation.

By I do hope that the parties settle, and then move on.

Update: Aug. 26

The book "Born Digital" by John Palfrey and Urs Gasser maintains Facebook has settled the main claim (with the other roommates and "ConnectU") out of court, on p 228. (See my books blog Aug. 26.)

Here are a couple of other references: From Techdirt, Apr 16, 2008, "Another Failed Harvard Social Network Takes 'Legal Action' Against Facebook: from the if-connectu-could-do-it... dept", discussion of Greenspan's action, here.

The New York Times
reported Greenspan's action Aug 29, 2007, article by John Markoff, "Who Founded Facebook? A New Claim Emerges", link here.

No comments: