I would like to understand better the licensing policy of Bioconductor. According to http://www.bioconductor.org/about/, the open source policy is:
Open source. The Bioconductor project has a commitment to full open source discipline, with distribution via a public subversion (version control) server. All contributions exist under an open source license such as Artistic 2.0, GPL2, or BSD. There are many different reasons why open source software is beneficial to the analysis of microarray data and to computational biology in general. The reasons include:
We try aggressively to require strictly open-source licenses, but a limited number of packages have non-open-source licenses for historical reasons, overlooked vetting on our part when the package was accepted, or occasionally other considerations. I encourage you to contact the package authors directly and express your dissatisfaction. I will soften the wording on the about page to make it more consistent with reality than with aspiration.
Maybe adding a badge to the packages with either `License_restricts_use: yes` or `License_is_FOSS: no` in their DESCRIPTION file is a more fine grained approach to warn users about these licensing issues, but I understand it also requires a bit more work to implement it. Thanks for the clarification anyway!
I think you are confusing 'a commitment to' with 'an absolute requirement of'. We strongly recommend all incoming packages be released under an Open Source license. However, not all package authors are able to comply with that, for various reasons. As an example MotifDb IS Artistic 2.0, but there are some data that come with that package, from different sources, that are under a more restrictive license. The other two you mention are free for academic but not commercial, for whatever reason.
I don't think you have missed any big warnings, but I don't really know what you mean by that. Warning about what?
I understand the difficulties in releasing open source packages. Copyright and licensing terms can be very complex when there are expensive datasets and multiple parties involved. But if Bioconductor has a strong open source commitment then exceptions to that commitment (with "academic only" or "non commercial" clauses) should in my humble opinion be clearly marked as such. Without a clear warning of those exceptions all parts suffer:
Commercial users are not aware that they are not allowed to use some bioconductor packages without a different license. There may now be many users in a legally vulnerable position and they are not even aware of that.
Package authors do not reach agreements with commercial users as they expect, because users don't know those agreements are required.
Bioconductor gives (was giving) a false sense of safety to commercial users and contradictory licensing terms in those packages descriptions vs the "About" page, creating confusion.
The tag-line "Bioconductor: Open Source Software for Bioinformatics" and the statement "All contributions exist under an open source license" (changed now that I asked this question) gave the impression that all Bioconductor software is open source. I was confused when I found out about the not-open-source packages. I thought that maybe I had been warned about these not-open-source packages the first time I installed biocLite("RankProd") and I had dismissed that warning, but that is not the case.
I'm not a commercial user, but I have been in the past. Fortunately I did not use any of those Bioconductor packages at the time.
I'm really on the same page as you -- we (Bioconductor) need to accurately reflect the software that we aspire to and actually disseminate. Users need to conform to licensing conditions; presumably there are organizations where some flavors of open source license are acceptable, others not. Adding a badge to make licensing more prominent is certainly something that we will explore (thanks for the suggestion!). But badges themselves are relatively new to the landing pages; the licenses are readily available, from the package landing pages, in the svn repository, and in the installed package -- ultimately, only the user can assess whether the software they are using is licensed in a way consistent with their requirements.
I understand your concerns, and they are valid to an extent. But I have a more sanguine position on such things than you appear to have. For my reasoning, let's use RankProd as an example. The author says that commercial users can't use the package without his permission. Now that's not a law, nor is it binding in any real respect. If I work at some company and I download and use RankProd, and the author finds out about it, what happens next?
I am certainly violating the wishes of the author, and maybe I should feel bad about myself because I am contravening his wishes. But the only way he can cause me to stop is to sue me and get a court to issue a ruling saying that I can no longer use RankProd. That will cost both parties some money, and as these things usually go, the party with more money gets the better lawyer, and all else equal wins the case. And this presupposes that the author of RankProd figures out that I am a dastardly corporate flack that is using his package against his will!
So in a ethical sense, there are rules and we should all follow the rules and all that. But in real-world applications, if you put your code up on a site where thousands of people can freely download and use your software without you knowing that they have done so, then putting a file in there that says corporate users have to ask first is not really how you keep that from happening.
Maybe adding a
badge to the packages with either `License_restricts_use: yes` or `License_is_FOSS: no` in their DESCRIPTION file is a more fine grained approach to warn users about these licensing issues, but I understand it also requires a bit more work to implement it. Thanks for the clarification anyway!