WedDevRadio.com forums

This came in from Mikeal Rogers - one of the guys behind Windmill from OSAF. Reprinted with permission. Discuss and enjoy...
=====================================

Hey Michael,

I was just listening to your show and really cringing the whole time you guys were talking about copyright law and contributor agreements.

I actually happen to know a bit about this, and from a rare angle as I'm a contributor and maintainer in large projects funded by large institutions, OSAF and now Mozilla (i just got hired on), and as a single contributor and maintainer of smaller projects.

I think people like to think of the law as very black and white, and like to think of things written in to law as the last word, but it's not. The law is very open to debate and never provides black and white but lots of grey, what open source projects need to worry about is not just the actual law in place but how it is enforced and perceived at this time.

There are two types of legal action a project might want to worry about, "Cease and desist" action, and "Libel" action. And different kinds of projects needs to worry about different issues.

For ease, I'll break down the types of projects in to two buckets.
1) "Institutional Projects", being either large public benefit organizations (Mozilla, Apache, OSAF, etc)
2.) "Single Maintainer Projects", those being small libraries and frameworks with no institutional backing.

== Cease and Desist ==

When you talk about "copyright infringement" the primary litigation stemming from such an infringement is "Cease and Desist". Libel action is a whole other matter which I discuss more below.

Single Maintainer Projects shouldn't worry about "Cease and desist" action, it's not a big deal. You rip out the infringing code, kill the version history on the file, and stop distributing older releases. Not that hard to do, and it's very unlikely you'll ever get one of these anyway. Single Maintainer Projects don't need to worry about contributor agreements until they have about a dozen core developers, it's just not worth the hassle and is just going to create a barrier to contribution.

Institutional Projects can be a little more concerned about "Cease and Desist". For one thing, they have more to lose. Even if it's not a hassle to rip out infringing code they may not want to deal with _any_ bad press. If they are peddling their wares to big corporate customers a "Cease and Desist" makes them look unprofessional.

"Contributor Agreements" are a good idea for Institutional projects in this space. One thing your panel completely failed to recognize is that Contributor Agreements do very little in the way of keeping out infringing code. In fact, the last thing you should worry about is someone cutting and pasting code from another source -- it's incredibly rare and almost always isolated enough to not cause any real damage. The main function of the Contributor Agreement is that it require the signature of the contributor AND his/her employer. The agreement states that the employer does not own all works derived from the employee and agrees not to file suite against the organization for accepting such contributions.

This is an important point because unlike most of the real world cases your panel brought up, which were either minor, isolated or misinterpreted (more below), this actually happens, and it happens fairly often. An employee works on a for profit product in a specific technology, in their free time they work on similar technology in the open source community, that open source product become a more prominent competitor the employer of said contributor and they notice that he is listed on their contributor list. A "Cease and Desist" is a great legal tool to use against the project as this time, it stops development on the project, possibly for months, while the project has to remove a huge history of contributions from this developer. In addition, it's not very costly in terms of legal fees to bring this action and it's not very hard to prove.

== Libel ==

Libel law is larger than just copyright infringement, much larger. And in fact is defined loosely as "A person broke the law in full knowledge of the pain it would cause another person", and corporations are people.

Libel law is incredibly hard to prove. I mean, really really, hard to prove. It's on the shoulders of the institution bringing litigation to prove that the project either;

a) Knowingly accepted copyrighted source code to the detriment of the institution or
b) Created an environment where copyrighted source code could easily be contributed to the project to the detriment of the institution. And that the project either encouraged such behavior or rewarded it.

That can be interpreted a variety of ways but in this case the history of law in libel cases is actually on the side of open source. Libel law is normally used in civil suites against large corporations, which means there is a long history of corporate lawyers fighting to make sure there is a heavy burden of proof on the prosecution. It almost always requires a "smoking gun" to successfully prosecute an institution for libel.

Single Maintainer Projects don't need to worry about this at all. You are thinking far too highly of yourself and the importance of your project. Nobody cares enough to ever bring this kind of litigation against you, it's insanely costly and is almost never proven. No litigation has ever been brought against an individual for libel from a source code copyright violation, EVER. If they ever did, I'm sure the EFF would knock the suite out of the park for free.

Institutional Projects can easily insulate themselves from such litigation by using Contributor Agreements. It proves that you were not creating an environment where infringing contributions were encouraged and in fact made it so that in order for your institution to unknowingly break the law another person had to knowingly break the law and their agreement with you for contribution.

There isn't a whole lot of need beyond the contributor agreement.

I know it's become common place for projects using BSD style licenses to worry a lot about GPL code "infecting" their project. This a ridiculous knee jerk reaction. If you don't include modules that are GPL, and you don't knowingly take any contributions that are GPL, it's incredibly unlikely that you'll have any problems at all. The most likely place for you to take GPL code from and use it somewhere else is a project run the GNU project, and the GNU project and the FSF have never take strong legal action against another project for infringement like this. Their actions tend to be targetted at companies that are selling closed hardware running GPL software that they haven't shown the source code for (TiVo, Linksys, etc).

In fact you'll be hard pressed to find ANY case where ANYONE went after a project for less than a dozen infringing code contributions.

== SCO ==

Your panelist kept bring up the SCO fiasco. You panelist is essentially doing exactly what SCO wanted, getting concerned about unsubstantiated and to a certain extent invalid, source code and patent claims. SCO has never won a single case in any court regarding their perceived intellectual property in Linux, EVER. SCO has used the publicity of the cases they have brought to discourage Linux adoption by other vendors through legal intimidation. They are now on the verge of bankruptcy having never successfully litigated their claim.

It's doubtful another SCO will happen, and it's also insane to say that you're "worried about it happening to you". None of the solutions your panelists described would have prevented the code getting in to Linux that SCO claims infringes on their Intellectual Property. In fact, all the claims in question are ported from BSD license code that was committed under a contributor agreement from the original IP holders before SCO bought it.

SCO should never even be mentioned, it's a failed strong arm tactic that projects in the future won't need to worry about.

In general, all these concerns about contributors taking code from one project and committing it to yours are silly and so rare they are like worrying about your plane crashing because you saw it happen once on TV. The real concern is that a contributor writes original code for your project while under an IP agreement with another company, and that company happens to compete with you directly in the future -- a rare case of its own.


-Mikeal
=====================================