You started the open source project iText. When was that?
The first Free/Open Source PDF library I published dates from 1999. It was replaced by a new, completely refactored PDF library in February 2000: iText.
At that time, were people aware of the importance of license implications on the code level?
Not really.
One of the few licenses I was aware of when I started writing Free/Open Source Software, was the GPL. But as my PDF library wasn't an end-user product, but more like an engine, I didn't like the fact that companies wouldn't be able to use iText in closed source/proprietary/commercial applications due to some of the "restrictions" in the GPL.
I wanted my product to be used in as many applications as possible, regardless of the fact if these applications were free or proprietary, open or closed source. Note that, back in 1999, I didn't have the intention to start a company, nor to earn money with Free and Open Source Software. At that time, I chose the LGPL, because I was under the impression that there was a strict difference between "work based on the library" and a "work that uses the library" in the LGPL. The way I saw it, the "viral effect" of LGPL was inexistent as long as an application "used" the iText.jar. Only developers who opened the jar and applied changes to the library, were obliged to distribute their changes along with the product.
Several companies (and their legal departments) didn't agree. One of the reasons for not accepting libraries that were released under the LGPL, was the difference between linking at compile time and linking at runtime. As iText was written in Java, the compiled iText classes are linked with the classes using iText at runtime, resulting in one monolithic application. One could argue that code that is closely tied to iText this way, also falls under the LGPL.
I am not a lawyer (and I don't agree with this argumentation), but after a long discussion, we chose to move from LGPL to MPL, which is a license that is much more finegrained and much more clear about what is allowed and what isn't. Nowadays, we still stick to the MPL, although there has been pressure to move to other licenses (for instance the EPL).
How did you select the contributions that was included in the project's source code?
Whenever we took something from another project, we made sure the licenses were compatible. We checked contributions made by other developers, but we didn't do this systematically.
What's the first complication you did encounter due to license problems?
We weren't aware of any possible license issues till the code was scrutinized by the legal department of IBM in Canada. The Eclipse Foundation had been putting pressure on our development team to move from the MPL to the EPL. At first, we had no idea why. Then we heard about the Callisto Simultaneous Release: a plan to release a series of Eclipse products with different release cycles simultaneously. iText was used in one of these projects: Eclipse/BIRT, led by Actuate. So after the Eclipse Foundation had flooded us with mail, I was contacted by Actuate. As it turned out, end users would be able to download a series of ten Eclipse products in one bundle, but as soon as they needed PDF reporting, they would have to download and install iText separately. IBM nor the Eclipse Foundation wanted to host software that had possible license issues on their servers. Moving to the EPL would solve this problem, but that wasn't an option for us. Another solution would be to make an IP inventory of the complete code base. And that's what we did eventually: Actuate sponsored a research agreement to make a detailed IP overview of iText. During this process several license issues were encountered and solved. Most of the problems were very prozaic, involving missing or incomplete license notices. Some problems were more difficult to solve; we even had to remove a small part of the existing functionality.
How have you changed things to avoid these problems?
Checking if a code contribution can cause license issues has become a second nature. When a developer contributes code that involves more than 20 lines, we ask him and his employer to sign a Contributor License Agreement (CLA). This way, we are sure that the contributor agrees with the fact that his code will become a part of iText, AS WELL AS his employer (which is also very important). We don't look at any code if it's from a project with a license that isn't compatible with the MPL. For instance: unless we're formally asked to do so, we don't read any GPL'ed code. Whenever we use code from another project, we document, document and document!
With every new release, the list of code contributors and contributions is updated. For every given source file, we have a list of the developers that contributed code. Making this inventory and keeping it up to date, is one of the cornerstones that made a library that started off as a hobby project a professional product. It's essential if you want to do business with F/OSS.