Most definitions of success for an open source project includes widespread adoption: while the value of the satisfaction you get from writing a great bit of code shouldn’t be undervalued, it’s a great deal more satisfying when something you’ve built gets used by hundreds, thousands, or millions of people. A lot of value can be drawn from a very large adopter base, but that’s a discussion for another time…
So, I respectfully submit that every open source project needs adoption. If you care about adoption, then you need to care about your adopters. If you care about your adopters, then you need to care about intellectual property (IP) management.
Wikipedia defines IP: “Intellectual property (IP) is a term referring to a number of distinct types of creations of the mind for which a set of exclusive rights are recognized—and the corresponding fields of law.” So your thoughts rendered as source code is IP. IP is generally accompanied by some form of license that grants certain rights to others. A license might, for example, allow you to use a bit of IP under a certain set of circumstances, but not others. Or it may place requirements on you if you use it: you may, for example, be required to make derivative works, or linked code available under a similar license. The Wikipedia entry I cited above is distributed under a Creative Commons license that grants me the right to share and adapt, but requires attribution (there’s more to it, but that’s the simple version).
Adopters need to have confidence that the code they’re consuming is clean from an IP point-of-view. If it turns out that a license has been violated, the downstream implications can be pretty serious. Adopters are exposed to possible litigation, may be required to take code out of service, and more. In short it can be a real mess.
So, there are some things that you need to think about while you’re working on your open source projects.
If you need to use somebody else’s code–be it snippits of code, files, or entire libraries–that code needs to be vetted. You need to be assured that the people who claim authorship of that code are indeed the authors. You need to be assured that the people who claim ownership of that code are indeed the owners (code written under contract is not
necessarily the property of the authors). You need to be assured that the owners truly agree to the terms of the license. You need to confirm that the terms of the license is compatible with the project license (for most Eclipse projects, this is the Eclipse Public License [3]).
This is a lot to think about. It sounds a little painful, and if you had to do it yourself it certainly would be. Fortunately, we have some processes in place at Eclipse to help with this. The Eclipse IP Due Diligence process will help you understand how to work with the Eclipse IP Team to mitigate the risk (generally using a Contribution Questionnaire). The Eclipse IP Team is responsible for making sure that the questions posed above are adequately answered. Of course, we also have a pretty huge community of folks who have “been there” and “done that” who can help; if you’re new to a project, ask your fellow committers, the project lead, or the project mentors for help. If all else fails, send a note to emo.
There’s more to discuss on this topic, but this post is already too long, so I’ll save that follow up discussion for another day.
FWIW, I’m pretty sure that nothing here can be considered legal advice. Regardless, I feel compelled to ensure that the reader is aware that I am not a lawyer and that nothing I say should be considered legal advice. If you want legal advice, check with your lawyer.
