#163 Licensing issue

closed-fixed
nobody
None
5
2011-06-27
2011-05-19
Toshio Kuratomi
No

I started packaging a snapshot of current svn in order to get our docutils package building on python-3.2 and noticed the addition of the docutils.math code. Unfortunately, the code appears to be licensed under the Apache v2 license. Is this intentional? If so, this is a major change in licensing as Apache 2 is not compatible with the GPLv2. Please consider contacting the author(s) of the code and switching it to BSD, MIT, Python license, public domain, or another license compatible with both the GPLv2 and GPLv3 ( http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses ).

Also, if the license is not changed to Public Domain, the COPYING.txt file needs to be updated to show which files are under another license (and if it stays Apache 2, that the note about GPL compatibility is updated to reflect that it is no longer compatible with GPLv2; only with GPLv3.)

Discussion

  • Part of what you're interpreting there is backwards. The GPLv2 *is* compatible with Python's current license. It is not acceptable as a license on code to be included in the python stdlib. Since being included in the stdlib is the goal of the docutils license policy we should take a look at what licensing requirements. Reading the PSF FAQ, the docutils licensing policy may need some additions. My impression is that everyone who contributed code to docutils will need to sign a contributor license agreement with the PSF in order for the code to go into the stdlib as the contributor agreement is what gives the PSF permission to relicense the code under the python license, not the Apache license. According to the next section of the PSF licensing FAQ: http://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#Why_can.27t_I_contribute_code_under_the_PSF_License.3F

    the reason the PSF requires the apache or Academic Free license is explicitly because of the patent protection clauses. That means that you probably need to clear with the PSF that public domain is a valid state for the code you contribute to them without a signed contributor agreement stating a different license. Finally, the PSF contributor agreement also includes a section where the signer enters what license they are submitting their code to the PSF under so it wouldn't matter whether the external docutils is licensed apache or not (for instance, the external simplejson library is licensed MIT)

    With those in mind, I'm not sure that the requirement to be licensed Apache for the eventual inclusion of docutils into the stdlib makes much sense.

    On the debit side, allowing Apache (and as you point out, Academic free license which would cause more drastic problems for GPL licensed code) excludes people writing GPLv2 apps from using the code until it goes into the stdlib and is relicensed to the python license.

    If you believe that you can get value from having contributions licensed Apache despite the above thoughts on the stdlib contribution process, one solution would be to dual-license. If you license (Apache OR any GPLv2 and 3 compatible license) then people writing apps under the GPLv2 can make use of docutils now and it wouldn't hinder pushing into the stdlib anymore than now.

     
  • Günter Milde
    Günter Milde
    2011-05-24

    • status: open --> open-fixed
     
  • Günter Milde
    Günter Milde
    2011-05-24

    COPYING.txt is updated in revision 7038

    The pypi page describes version 0.7. An update is required with the next release.

     
  • Günter Milde
    Günter Milde
    2011-05-24

    correction COPYING.txt is updated in revision 7040

     
  • Günter Milde
    Günter Milde
    2011-06-27

    The parts of Docutils released under the Apache 2 license in the devel version are now re-licensed under
    the 2-Clause BSD license by their authors.

     
  • Günter Milde
    Günter Milde
    2011-06-27

    • status: open-fixed --> closed-fixed