[issue14759] Berkeley DB License conditions are onerous (and poorly documented)
New submission from Jeff Laing : As part of an audit of license compliance, I was looking at the terms in the LICENSE.txt that describe the Berkeley DB product. I had thought this would be under the standard Berkeley license, but Oracle have added their own zinger. * 3. Redistributions in any form must be accompanied by information on *how to obtain complete source code for the DB software and any *accompanying software that uses the DB software. The source code *must either be included in the distribution or be available for no *more than the cost of distribution plus a nominal fee, and must be *freely redistributable under reasonable conditions. So, my application, which embeds Python (rather than running it as python.exe) and includes the standard runtime library, must distribute my source code. This page: http://mail.python.org/pipermail/python-dev/2008-September/082316.html suggests that this is not the case for regular Python, but it makes no statement about "embedding". Sadly the Oracle page it links to suggesting this is not an issue, does not exist. The general "License" page on the Python websites makes no reference whatsoever to Berkeley DB license obligations. I note that there are other modules mentioned on the Licenses webpage that are not in the LICENSES.txt file, and vice versa. I have no idea whether this is deliberate, or an oversight. -- assignee: docs@python components: Documentation messages: 160238 nosy: Jeff.Laing, docs@python priority: normal severity: normal status: open title: Berkeley DB License conditions are onerous (and poorly documented) type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14759] Berkeley DB License conditions are onerous (and poorly documented)
Jeff Laing added the comment: With all due respect, I think that the 2.7.3 License Page is still being actively used by people as a reference, and it should be accurate. I agree that the code developers can't do anything, but the documentation for all releases, particularly in such a sensitive area as licensing, should be as up to date as possible. Similarly, the 3.0 License page talks about a "_random" module which presumably is going ahead. It has a license agreement displayed on the web page but I did not see that text copied into the regular LICENSE.txt that is part of the Python3 distribution, and that I assume meets the "supporting documentation" clause that all the module licenses seem to demand. Ditto socket. Ditto asyncore and asynchat. Ditto Cookie. Ditto trace. Ditto xmlrpclib. etcetera. I agree this is all a documentation exercise - perhaps there is another bug tracker I should be reporting it in? -- ___ Python tracker <http://bugs.python.org/issue14759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14759] Is LICENSES.txt up to date?
Jeff Laing added the comment: @Jesús, as has been pointed out already, the Berkeley DB stuff is not part of Python 3 so I don't see any point in discussing this with Oracle. We don't actually use or need the bsddb module, it's just part of the standard runtime library that we ship. We will be removing the bsddb module from our distribution of the runtime library, while our app is embedding the 2.7 interpreter. Once we go to 3.0, the problem becomes moot. When discussing issues related to licensing, a visible audit trail is essential to show that one followed a genuine process in a timely fashion. When the lawyers come howling to our door, I want to be able to point at archived documentation that showed we were not knowingly continuing to violate a license condition once we became aware of it. With respect to mail.python.org mailing lists, the http://docs.python.org/bugs.html page explicitly says "if you want a more persistent record of your issue, you can use the issue tracker for documentation bugs as well". That suggested to me that there were more than just "developers" listening here. I feel like it's getting a bit meta if I raise an issue here requesting that the website be clarified to note that the documentors don't really look at issues here. :-) Thanks to all, my immediate problem is resolved, and I now know that I need to dig a lot deeper into all the documentation each time we upgrade, rather than assume that it's all consistent. -- ___ Python tracker <http://bugs.python.org/issue14759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
