Bioclipse is an Open Source chemo- and bio-informatics toolkit (rich client) developed by Ola Spjuth and colleagues and a wide virtual community (including me). It’s Open Source (LGPL). Under the heading Bioclipse pirated Christoph Steinbeck writes
A company called InfoCom, located in Arizona, advertises a product called iBioTech , which by all evidence is identical with Bioclipse. They say their iBioTech product has a plugin for chemoinformatics call “bc_cdk” (surprise :-)) and one called “bc_jmol” for 3D visualization.
While this is something that we have explicitly not tried to prevent; still it is kind of appalling to see it happen. My personal expectation on having my/our code being used by others was always that they would offer additional services and still acknowledge the original authors.
The case that we are currently seeing includes renaming and the pretension that the prodcut has been created by them (citation: iBioTech from InfoCom laboratories). The question here is of course: Is this covered by the Bioclipse license or not.
I was surprised that my first two attempts to dig into the Bioclipse license led into nowhere. There was no such thing as a LICENSE file in the top level directory in bioclipse trunk. The next thing to do was to look at the code of net.bioclipse.BioclipsePlugin.java, which in my opinion should contain a header clearly stating the license for this code. Nothing there.
But of course, the Bioclipse website has a full coverage of the license issues with Bioclipse. I would clearly say that the redistribution of a number of parts of Bioclipse, including CDK, requires the distributor to make it clear to the customer where the source code is available, which then automatically implies giving proper credit.
PMR: There is further discussion on the mailing list (https://lists.sourceforge.net/lists/listinfo/bioclipse-devel).
All of us know when we write Open Source is that others may re-use it. Most licenses allow commercialization without the permission of the authors. Almost all licences require that the modified version acknowledge the provenance and authors of the earlier version. So far, so good.
But there are also ethical considerations. I may take a piece of Open Source and develop it for my own purposes but in so doing I create a Fork. As the WP article says:
Free (libre) or open source software is, by definition, that which it is possible to fork without permission of the original creator. However, licensed forks of proprietary software (e.g. Unix) can also be important.
On the matter of forking, the Jargon File says:
- “Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissioning of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.”
PMR: This expresses the Community Norms (the Science Commons phrase). It’s not illegal, but it may cause massive problems.
In the current case my problem (and I suspect most of the other authors) is:
- The company has not acknowledged the identity of the code (they have simply renamed it)
- The company has not acknowledged the provenance of the code or the contributions of the authors
- The company has not (at least from current reports) included a licence which indicates that the software is based on Open Source.
I wait to see confirmation that these are all incompatible with the licence.
There is also the likelihood that the code will devealue Bioclipse. It confuses the community. There may be mutant versions. If the mutant versions cause bugs this brings unjustified criticism on Bioclipse. Any restrictions imposed by the company make be confused with Bioclipse policy, etc.
In my own case (JUMBO) I use Artistic licence which specifically requires third parties to (a) acknowledge the provenance and (b) choose different name for the software.
This post is a first reaction. I – and I assume the rest of the Bioclipse team – would be grateful for any experiences of this and how it should be treated.
No, it’s actually licensed EPL, as is Eclipse itself.
(1) Thanks and my apologies. (some of the libraries are/were LGPL)
I certainly deplore the actions taken my Infocom here – whether legal or not they are certainly antisocial.
However, I don’t think that it’s forking that is the issue here. Quoting from Christophe’s blog:
“The case that we are currently seeing includes renaming and the pretension that the prodcut[sic] has been created by them”.
This is nothing to do with forking. Forking a project explicitly acknowledges the origin of the codebase, but simply involves a new direction for further development, which generally speaking will also be in the domain of free software – witness the projects listed in the jargon file’s definition above. None of these involved a new project obscuring the origin of any of the codebase, or appearing to claim other people’s work as their own.
The reason why forking is sometimes considered bad is entirely separate, and has no bearing on IPR.
Contrariwise, Infocom’s actions are to be deplored because of the apparent dishonesty in their actions – they don’t appear to be operating within the free software world at all.
A genuine fork of Bioclipse would be clearly legal, and quite possible a perfectly ethically defensible action as well. For example, I maintain a fork of Jmol for my own purposes, which I sometimes redistribute to a few users. I don’t imagine anyone has any problems with that.
Your discussions have been brought to my attention today 2008/3/28. There are some issues I would propose you consider.
Code changes have been made by InfoCom Laboratories to the Bioclipse application that we feel make it a different product.
As with any Open Source application that we distribute we include per the origin’s requirements their attribution, location of source code and a copy of all original licenses. I believe that the requirement is that this information be included in the distribution itself and not necessarily in a marketing piece.
When we discuss this product with either a prospect or customer we are careful to mention that that a different version is available from the Open Source community and they may choose that as an option. In thoses instances we provide fee based support.
We would, of course, like to develop a better relationship with this Open Source organization. It is our very strong position that while Open Source projects such as Bioclipse are superior in their development and feature/function what remains lacking is a strong marketing and support function. This results in many organizations not being aware that a product such as Bioclipse even exists and denies them the benefit of the use of it or a branch of it. That is what we do – marketing, promotion, reengineering where it makes sense to do so, support and training and education.
I welcome any suggestions on how we can work together to the benefit of all.
Regards,
J. Gallagher
InfoCom Laboratories, Inc.
(4) Thank you for posting