[Bioc-devel] License question

Fri Jan 11 10:33:19 CET 2008

Robert Gentleman wrote:
 > Hi,
 >
 > pingou wrote:
 >> Dear all,
 >>
 >> Packaging the Bioconductor libraries for Fedora, we are facing a
 >
 >   First it is great that you are interested in packaging (I am guessing
 > rpm or what ever variant is now popular).  I am sure many authors will
 > be glad to help you out.  I have a few comments and questions.

Hi Robert,

Great to hear that!  Yes, packages are distributed as .rpm files, but 
most packages are downloadable via the yum tool which allows easy 
installation of dependencies (much like Debian's apt-get).

 >   Could you clarify what you mean by "libraries" here? Bioconductor is a
 > loosely connected set of packages (no libraries), each with potentially
 > different licenses and some with non-standard licenses.  We do not
 > require users to adhere to any particular set of licenses, so there will
 > always be packages that do not meet pretty much any set of guidelines.

I used the word "library" loosely meaning "package", however since some 
  of the packages do not contain source code but only datafiles, I use 
the word libraries in general.

Fedora doesn't requiring a particular License (other than it be free 
software), only that the license is clearly documented in the package 
source.  For most Bioconductor packages we do find the License tag in 
the DESCRIPTION file but for some of them (multtest, affy, annaffy for 
example, there are others) the tag specifies LGPL without any version. 
For those package we assumed that the license is LGPLv2+ but that might 
not be the case.

 >> problem, that I think could be easily solved.
 >> Many packages are not clear about their license, most of them are
 >> declared to be under the LGPL license,
 >> but some of them do not precise clearly which version of this license.

 >   Some specific examples might be nice. Last time I checked most were
 > quite specific, with some exceptions (as I noted above).  You might also
 > want to check with Kurt Hornik who not very long ago sent a list of
 > anomalies to us and as far as I know most were resolved, and those that
 > were not are not easily resolvable.

An example of where the version of the License is not clear is the 
multtest package:

http://www.bioconductor.org/packages/2.1/bioc/html/multtest.html
http://www.bioconductor.org/packages/2.2/bioc/html/multtest.html

the DESCRIPTION file has:

License: LGPL

but no version is present, in the absence of the version we can assume 
*any* version of the LGPL is acceptable, but that may not be the 
intention of the author.

 >> Would it be possible to add a copy of the license used in every package?

 >   Why not do that as part of your packaging if you need it there? In my
 > experience license files get out of date, and references to standard
 > licenses in more or less standard locations tends to be a better
 > practice.  In the old days, distributing the LICENSE file was useful as
 > some folks would have had trouble locating it. But these days that is
 > just not true.

This isn't an absolute requirement for Fedora, we are just passing on 
the recommendation from the FSF that source code contain copies of the 
license when using one of the GNU licenses. I can see that it might be 
cumbersome for authors to include it, and we generally don't add it 
unless upstream does. Part of the packaging guidelines is to ask 
upstream to consider adding LICENSE files for reasons that the FSF 
states, but we obviously can't compel anyone to, and it doesn't block 
acceptance into Fedora.

 >   We do from time to time ask authors to clarify their licenses, if they
 > can (and some cannot).  Personally I am not in favor of either LGPL or
 > GPL v3, and think that such changes are so substantial that package
 > authors would need to make those decisions themselves and should
 > carefully consider the ramifications of such decisions. I would not be
 > comfortable suggesting that they adopt language of the form "or any
 > later version" in regard to the GPL or its variants (or any other
 > license for that matter).

Fedora doesn't require a particular versioning of the LGPL license, we 
only want to ensure that the we are precisely representing the intention 
of the authors chosen license. The R-project website mentions the issues 
of versioning for licenses [4]. I suspect that most people who specify 
LGPL *mean* LGPL >= 2.1 because LGPL on its own would be incompatible 
with LGPLv3 or GPLv3.

 >> In addition the GNU licenses recommend that the version of the license
 >> be added near the top of each source file (e.g. in a comment block):

 >  I can't see how that is of any real benefit to anyone, and certainly a
 > burden on package authors. But your request here may get some to do it.
 > What it does do is to make it harder to change licenses (as every file
 > needs to be modified) or to release under multiple licenses.

Again, not an absolute requirement for Fedora and this certainly 
wouldn't block the inclusion of a package, but it is an FSF 
recommendation for applying GNU licenses. But, yes it can be a pain to 
add header blocks everywhere.

 >> The GNU project page[2] and Fedora's licensing page[3] have more
 >> information.
 >
 >   Yes, and they seem to require that license changes be announced. That
 > is really not going to happen. In particular from [3]:
 >
 > A license change in a package is a very serious event - it has as many,
 > if not more, implications for related packages as ABI changes do.

 > Therefore, if your package changes license, even if it just changes the
 > license version, it is required that you announce it on 
fedora-devel-list.

The announcement of the License change on fedora-devel-list is a 
requirement for the Fedora maintainer and is not a requirement for the 
upstream developers or anybody else. It helps us consider the 
implications of license changes to other dependent packages. This is 
unlikely to be a problem in the case of Bioconductor because most 
packages don't (in general) provide .so libraries.

If we can easily find the version of the license used by a particular 
package, then we can easily see when the license is changed.  Does CRAN 
have a diff tool for changes between packages like CPAN?  Or a mailing 
list where license changes or other major changes to packages are 
announced? That would allow us to easily detect license changes.

 > Note that any license change to a more restrictive license or license
 > version may affect the legality of portions of Fedora as a whole; ergo,
 > FESCo reserves the right to block upgrades of packages to versions with
 > new licenses to ensure the legal distribution of Fedora.
 >
 > Please contact FESCo if you have any questions.

 > Seems like it imposes restrictions on us that we don't want. I am not
 > sure how you might deal with it, but there is no way we could agree to
 > these terms.

That particular part of the documentation is written for the maintainers 
of the Fedora packages and shouldn't concern the upstream developers, 
except insofar as changes of licenses might impact whether Fedora can 
distribute them.  I don't anticipate any problems in this particular case.

Thanks for your attention,

P.Yves

 >> [1] https://stat.ethz.ch/pipermail/r-announce/2007/000832.html
 >> [2] http://www.gnu.org/licenses/gpl-howto.html
 >> [3] http://fedoraproject.org/wiki/Licensing
[4] http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file