During his review of the Mersenne Twister code (in python/nondist/sandbox/twister), Martin raised a question for python-dev about the best way to handle the copyright notice in the original code at http://www.math.keio.ac.jp/~matumoto/MT2002/emt19937ar.html . I incorporated the copyright notice into the head of _random.c, but the notice seems to indicate that it should also be in the documentation (either in librandom.tex or random.py). I don't think having multiple copies of the copyright notice or having clutter in the LaTeX docs is desirable. Inclusion by reference or footnote may be sufficient. Do you guys have any thoughts on the best way to resolve this one? It is my only unanswered review comment for the module before loading it for the alpha release. Raymond Hettinger
python@rcn.com wrote:
The usual way to deal with this is to include a .txt/.doc file in the module directory where the module is placed. Examples are the LICENSE.txt file and the various .doc files we already have in the std lib directory. I'd suggest to include a twister.txt file together with the module which then includes the copyright notice. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Can you give a few examples? I could not find a file LICENSE.txt (you probably meant LICENSE), and no .txt or .doc file I checked was relevant to licensing.
I'd suggest to include a twister.txt file together with the module which then includes the copyright notice.
My concern is that people who produce binary distributions will have to include this text file in their distribution as well. People who embed Python (in a way that includes _random.c) will have to include the text file in their applications. Do we really want this? Regards, Martin
Martin v. Löwis wrote:
Have a look at the /usr/local/lib/python2.2/ dir. The LICENSE.txt file has the Python copyright notice. profile.doc has the license for the profiler.
If that's what the licenses want, there's no way to drive around this I guess. Note that people redistributing the code can also take these .txt files and add them to their application documentation to meet the license requirements. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Have a look at the /usr/local/lib/python2.2/ dir. The LICENSE.txt file has the Python copyright notice.
Ah, I see. It is renamed to LICENSE.txt when installed.
profile.doc has the license for the profiler.
Right. It appears that ActivePython is breaking InfoSeeks copyright, by not including this file in their distribution...
If that's what the licenses want, there's no way to drive around this I guess.
There are certainly various options: a) we could refuse to incorporate the code in question, or postpone that until an alternative implementation comes along that does not have such requirements, or b) we could try to contact the authors of the code in question, to find out whether they would accept other means of acknowledgement (e.g. mentioning their names in the ACKS file, and putting some text into the copied source - as Raymond already did) It is certainly the case that we haven't been very careful with such things in the past (in particular in binary distributions), but that is IMO no excuse to be more careful now. Regards, Martin
On zondag, dec 29, 2002, at 00:13 Europe/Amsterdam, Martin v. Löwis wrote:
This sounds like overkill.
This is probably a good idea. Alternatively, there's another option: c) Add a special directory (Misc/Licenses comes to mind, copy it to lib/python2.3/config/Licenses on install) that has the text files for the various packages that require their license to be in a file of its own. We could even get all fancy, and install only those licenses for which the corresponding code is actually used.
MacPython has always been fairly careful about this, and I wouldn't be surprised if the same holds for PythonWin. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Jack Jansen wrote:
MacPython has always been fairly careful about this, and I wouldn't be surprised if the same holds for PythonWin.
As Tim points out, the Windows distribution incorporates a number of add-on libraries with their own copying conditions, which aren't always followed. For example, the db 1.85 package which was the basis of bsddb on Windows still has the original Berkeley advertising clause (which was waived now); it also has the requirement that The Regents of the University of California are acknowledged and their license terms be included in binary-only distributions; I don't think this requirement was followed. The same holds for other copies of the BSD license, e.g. the one in getaddrinfo.c requires that the WIDE project is acknowledged (I'm guilty of incorporating that one into Python). pcre-int.h says that the origin of PCRE must not be misrepresented by omission [of Philip Hazel's copyright]. regexpr.c says that Tatu Ylonen's text must appear in all copies. xmlrpclib.py says that Secret Lab's copyright text must be mentioned in documentation. And so on. Does MacPython acknowledge all these people and organizations, in the documentation? Regards, Martin
On zondag, dec 29, 2002, at 01:24 Europe/Amsterdam, Martin v. Löwis wrote:
Does MacPython acknowledge all these people and organizations, in the documentation?
Oops, you're right: MacPython acknowledges all the stuff that *I* added, but of course I never thought about the things in the core:-( On the other thread: will including the copyright notices/acknowledgements in the documentation be good enough if we don't always ship the documentation? Or should we put this in a special section that is always shipped, even with binary installers that don't include documentation? -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Jack Jansen wrote:
This is exactly my concern. It is essentially for people producing binary distributions to decide how they want this to be organized.
For the specific case in question, I think MAL's suggestion of adding yet another file is sufficient - maintainers of binary distributions then need to collect all those text files and distribute them. Complying with the various licenses is really something that the packagers most solve for themselves - the source distribution can only prepare things in a way that makes complying simple. Of course, if the license says that you must have certain words in the documentation of a binary distribution, then you really must have those words somewhere: either in text files that you "declare" to be documentation, or (probably more to the spirit of these clauses) in a place where users of the binary distribution won't overlook them. My feeling is that this can get quite annoying both for people producing binary distributions, as well as for people using them. So I would rather negotiate terms with the authors, or consider rejection of contributions that have such clauses. Of course, if nobody but me is annoyed by such clauses, I won't fight windmills. Regards, Martin
Martin v. Löwis wrote:
In a later mail I suggested adding these licenses to the standard Python license file. This should probably be done as new section explaining to which code the license applies and where the code was obtained from. Then binary distributions would only have to include this one file (which they have to include anyway, since the Python license requires this). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
This would suit us (ActiveState) just fine. In general, we don't mind doing whatever is necessary to give credit where credit is due (as well as comply with the license in general, of course) -- but the simpler it is, the more likely it is to actually be carried through -- the more automatable the better as well. --david
David Ascher wrote:
So what's the general feeling ? Should we take this approach ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
Jack> On the other thread: will including the copyright Jack> notices/acknowledgements in the documentation be good enough if we Jack> don't always ship the documentation? Is there any reason the copyright builtin can't be embellished to spit out all the necessary copyrights? Skip
On Sunday 29 December 2002 06:23 pm, Skip Montanaro wrote:
A requirement could be added to the PEP 2 that would require a copyright disclosure be included in the package/module so that the name "copyright" would retrieve the relevant copyright for that package/module. A copyright that did not require disclosure would return None. (BTW, PEP two is titled "Procedure for Adding New Modules". Should that be renamed "Procedure for Adding New Modules and Packages"?)
The copyright builtin could be extended to add a search of all imported libraries to retrieve all of the copyrights that are used in an application.
Michael> A requirement could be added to the PEP 2 that would require a Michael> copyright disclosure be included in the package/module so that Michael> the name "copyright" would retrieve the relevant copyright for Michael> that package/module. Excellent idea. I would name it "__copyright__" though. Skip
Though it makes the copyright accessible in a binary distribution, I don't think it fulfills the license requirements of being in printed in the documentation. So far, the simplest thing that gets the job done and minimizes the PITA factor is to have a section in the docs for licenses, paste them in a verbatim block, and make a link to them from the module docs. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
>> A requirement could be added to the PEP 2 that would require a >> copyright disclosure be included in the package/module so that the >> name "copyright" would retrieve the relevant copyright for that >> package/module. A copyright that did not require disclosure would >> return None. Raymond> Though it makes the copyright accessible in a binary Raymond> distribution, I don't think it fulfills the license Raymond> requirements of being in printed in the documentation. Ah, but now you have a "machine" that will generate the bit of documentation you desire as part of the install process (binary or source). Skip
Skip Montanaro wrote:
Ah, but now you have a "machine" that will generate the bit of documentation you desire as part of the install process (binary or source).
The question still is what is easiest for people producing Python binaries. Do they want to paste files from the CVS to fulfill the requirements, or would they prefer to print a variable in Python? I agree with Raymond that collecting the statements alone in copyright won't help, since it does not meet the licensing criteria of some of the licenses. Regards, Martin
"Martin" == Martin v Löwis <martin@v.loewis.de> writes:
Martin> Skip Montanaro wrote: >> Ah, but now you have a "machine" that will generate the bit of documentation >> you desire as part of the install process (binary or source). Martin> The question still is what is easiest for people producing Martin> Python binaries. Do they want to paste files from the CVS to Martin> fulfill the requirements, or would they prefer to print a Martin> variable in Python? You simply have an automated post-install or binary distro build step which does the little find-the-copyrights dance and dumps the result to something like LICENSES.txt or LICENSES.tex or LICENSES.hlp in the appropriate directory and either declare it to be documentation or incorporate it into the documentation delivered with the distribution. People distributing Python with another package will have to do this sort of thing themselves, but that's not our concern. Skip
Martin v. Löwis:
pcre-int.h says that the origin of PCRE must not be misrepresented by omission [of Philip Hazel's copyright].
Discussion of this requirement for Scintilla (where I won't accept contributions with attribution requirements) led to this from Philip Hazel: % Yes. The licence says you must acknowledge PCRE in any software you % distribute that includes it. So Scintilla should acknowledge it. % However, the licence does not say that you have to impose this condition % on anybody who subsequently distrubutes other software that includes % your software. At least, that's one way I can read the licence. % % I'll put a sentence in if I can find some wording that says that % reasonably concisely. However, the current PCRE license still reads to me to require attribution no matter how deeply embedded it is. http://www.pcre.org/license.txt Neil
Martin v. Löwis wrote:
The license is also copied in the documentation for that module, so I believe everything is OK.
-1 Adding a few license text files to the module directory or a separate section of the Python documentation shouldn't keep us from including the code.
-0 While this would certainly be a much better solution, I don't think it is required. Instead, we should come up with a way which satisfies the licenses. Since most licenses require a copy of the text to be included in the documentation, I think the easiest and most reliable way of achieving this is to add a new licenses section to the documentation and Python's LICENSE file itself (Latex allows including text from other files in the docs, so adding new licenses to the LICENSE file would suffice if LICENSE is included verbatim in the Latex docs).
Agreed. Since you have already scanned much of the code, perhaps you could summarize your license findings in a new sandbox file until we have come up with a solution that satisfies everyone ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
python@rcn.com wrote:
The usual way to deal with this is to include a .txt/.doc file in the module directory where the module is placed. Examples are the LICENSE.txt file and the various .doc files we already have in the std lib directory. I'd suggest to include a twister.txt file together with the module which then includes the copyright notice. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Can you give a few examples? I could not find a file LICENSE.txt (you probably meant LICENSE), and no .txt or .doc file I checked was relevant to licensing.
I'd suggest to include a twister.txt file together with the module which then includes the copyright notice.
My concern is that people who produce binary distributions will have to include this text file in their distribution as well. People who embed Python (in a way that includes _random.c) will have to include the text file in their applications. Do we really want this? Regards, Martin
Martin v. Löwis wrote:
Have a look at the /usr/local/lib/python2.2/ dir. The LICENSE.txt file has the Python copyright notice. profile.doc has the license for the profiler.
If that's what the licenses want, there's no way to drive around this I guess. Note that people redistributing the code can also take these .txt files and add them to their application documentation to meet the license requirements. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
Have a look at the /usr/local/lib/python2.2/ dir. The LICENSE.txt file has the Python copyright notice.
Ah, I see. It is renamed to LICENSE.txt when installed.
profile.doc has the license for the profiler.
Right. It appears that ActivePython is breaking InfoSeeks copyright, by not including this file in their distribution...
If that's what the licenses want, there's no way to drive around this I guess.
There are certainly various options: a) we could refuse to incorporate the code in question, or postpone that until an alternative implementation comes along that does not have such requirements, or b) we could try to contact the authors of the code in question, to find out whether they would accept other means of acknowledgement (e.g. mentioning their names in the ACKS file, and putting some text into the copied source - as Raymond already did) It is certainly the case that we haven't been very careful with such things in the past (in particular in binary distributions), but that is IMO no excuse to be more careful now. Regards, Martin
On zondag, dec 29, 2002, at 00:13 Europe/Amsterdam, Martin v. Löwis wrote:
This sounds like overkill.
This is probably a good idea. Alternatively, there's another option: c) Add a special directory (Misc/Licenses comes to mind, copy it to lib/python2.3/config/Licenses on install) that has the text files for the various packages that require their license to be in a file of its own. We could even get all fancy, and install only those licenses for which the corresponding code is actually used.
MacPython has always been fairly careful about this, and I wouldn't be surprised if the same holds for PythonWin. -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Jack Jansen wrote:
MacPython has always been fairly careful about this, and I wouldn't be surprised if the same holds for PythonWin.
As Tim points out, the Windows distribution incorporates a number of add-on libraries with their own copying conditions, which aren't always followed. For example, the db 1.85 package which was the basis of bsddb on Windows still has the original Berkeley advertising clause (which was waived now); it also has the requirement that The Regents of the University of California are acknowledged and their license terms be included in binary-only distributions; I don't think this requirement was followed. The same holds for other copies of the BSD license, e.g. the one in getaddrinfo.c requires that the WIDE project is acknowledged (I'm guilty of incorporating that one into Python). pcre-int.h says that the origin of PCRE must not be misrepresented by omission [of Philip Hazel's copyright]. regexpr.c says that Tatu Ylonen's text must appear in all copies. xmlrpclib.py says that Secret Lab's copyright text must be mentioned in documentation. And so on. Does MacPython acknowledge all these people and organizations, in the documentation? Regards, Martin
On zondag, dec 29, 2002, at 01:24 Europe/Amsterdam, Martin v. Löwis wrote:
Does MacPython acknowledge all these people and organizations, in the documentation?
Oops, you're right: MacPython acknowledges all the stuff that *I* added, but of course I never thought about the things in the core:-( On the other thread: will including the copyright notices/acknowledgements in the documentation be good enough if we don't always ship the documentation? Or should we put this in a special section that is always shipped, even with binary installers that don't include documentation? -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
Jack Jansen wrote:
This is exactly my concern. It is essentially for people producing binary distributions to decide how they want this to be organized.
For the specific case in question, I think MAL's suggestion of adding yet another file is sufficient - maintainers of binary distributions then need to collect all those text files and distribute them. Complying with the various licenses is really something that the packagers most solve for themselves - the source distribution can only prepare things in a way that makes complying simple. Of course, if the license says that you must have certain words in the documentation of a binary distribution, then you really must have those words somewhere: either in text files that you "declare" to be documentation, or (probably more to the spirit of these clauses) in a place where users of the binary distribution won't overlook them. My feeling is that this can get quite annoying both for people producing binary distributions, as well as for people using them. So I would rather negotiate terms with the authors, or consider rejection of contributions that have such clauses. Of course, if nobody but me is annoyed by such clauses, I won't fight windmills. Regards, Martin
Martin v. Löwis wrote:
In a later mail I suggested adding these licenses to the standard Python license file. This should probably be done as new section explaining to which code the license applies and where the code was obtained from. Then binary distributions would only have to include this one file (which they have to include anyway, since the Python license requires this). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
M.-A. Lemburg wrote:
This would suit us (ActiveState) just fine. In general, we don't mind doing whatever is necessary to give credit where credit is due (as well as comply with the license in general, of course) -- but the simpler it is, the more likely it is to actually be carried through -- the more automatable the better as well. --david
David Ascher wrote:
So what's the general feeling ? Should we take this approach ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
Jack> On the other thread: will including the copyright Jack> notices/acknowledgements in the documentation be good enough if we Jack> don't always ship the documentation? Is there any reason the copyright builtin can't be embellished to spit out all the necessary copyrights? Skip
On Sunday 29 December 2002 06:23 pm, Skip Montanaro wrote:
A requirement could be added to the PEP 2 that would require a copyright disclosure be included in the package/module so that the name "copyright" would retrieve the relevant copyright for that package/module. A copyright that did not require disclosure would return None. (BTW, PEP two is titled "Procedure for Adding New Modules". Should that be renamed "Procedure for Adding New Modules and Packages"?)
The copyright builtin could be extended to add a search of all imported libraries to retrieve all of the copyrights that are used in an application.
Michael> A requirement could be added to the PEP 2 that would require a Michael> copyright disclosure be included in the package/module so that Michael> the name "copyright" would retrieve the relevant copyright for Michael> that package/module. Excellent idea. I would name it "__copyright__" though. Skip
Though it makes the copyright accessible in a binary distribution, I don't think it fulfills the license requirements of being in printed in the documentation. So far, the simplest thing that gets the job done and minimizes the PITA factor is to have a section in the docs for licenses, paste them in a verbatim block, and make a link to them from the module docs. Raymond Hettinger ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
>> A requirement could be added to the PEP 2 that would require a >> copyright disclosure be included in the package/module so that the >> name "copyright" would retrieve the relevant copyright for that >> package/module. A copyright that did not require disclosure would >> return None. Raymond> Though it makes the copyright accessible in a binary Raymond> distribution, I don't think it fulfills the license Raymond> requirements of being in printed in the documentation. Ah, but now you have a "machine" that will generate the bit of documentation you desire as part of the install process (binary or source). Skip
Skip Montanaro wrote:
Ah, but now you have a "machine" that will generate the bit of documentation you desire as part of the install process (binary or source).
The question still is what is easiest for people producing Python binaries. Do they want to paste files from the CVS to fulfill the requirements, or would they prefer to print a variable in Python? I agree with Raymond that collecting the statements alone in copyright won't help, since it does not meet the licensing criteria of some of the licenses. Regards, Martin
"Martin" == Martin v Löwis <martin@v.loewis.de> writes:
Martin> Skip Montanaro wrote: >> Ah, but now you have a "machine" that will generate the bit of documentation >> you desire as part of the install process (binary or source). Martin> The question still is what is easiest for people producing Martin> Python binaries. Do they want to paste files from the CVS to Martin> fulfill the requirements, or would they prefer to print a Martin> variable in Python? You simply have an automated post-install or binary distro build step which does the little find-the-copyrights dance and dumps the result to something like LICENSES.txt or LICENSES.tex or LICENSES.hlp in the appropriate directory and either declare it to be documentation or incorporate it into the documentation delivered with the distribution. People distributing Python with another package will have to do this sort of thing themselves, but that's not our concern. Skip
Martin v. Löwis:
pcre-int.h says that the origin of PCRE must not be misrepresented by omission [of Philip Hazel's copyright].
Discussion of this requirement for Scintilla (where I won't accept contributions with attribution requirements) led to this from Philip Hazel: % Yes. The licence says you must acknowledge PCRE in any software you % distribute that includes it. So Scintilla should acknowledge it. % However, the licence does not say that you have to impose this condition % on anybody who subsequently distrubutes other software that includes % your software. At least, that's one way I can read the licence. % % I'll put a sentence in if I can find some wording that says that % reasonably concisely. However, the current PCRE license still reads to me to require attribution no matter how deeply embedded it is. http://www.pcre.org/license.txt Neil
Martin v. Löwis wrote:
The license is also copied in the documentation for that module, so I believe everything is OK.
-1 Adding a few license text files to the module directory or a separate section of the Python documentation shouldn't keep us from including the code.
-0 While this would certainly be a much better solution, I don't think it is required. Instead, we should come up with a way which satisfies the licenses. Since most licenses require a copy of the text to be included in the documentation, I think the easiest and most reliable way of achieving this is to add a new licenses section to the documentation and Python's LICENSE file itself (Latex allows including text from other files in the docs, so adding new licenses to the LICENSE file would suffice if LICENSE is included verbatim in the Latex docs).
Agreed. Since you have already scanned much of the code, perhaps you could summarize your license findings in a new sandbox file until we have come up with a solution that satisfies everyone ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (10)
-
"Martin v. Löwis" -
David Ascher -
holger krekel -
Jack Jansen -
M.-A. Lemburg -
Michael McLay -
Neil Hodgson -
python＠rcn.com -
Raymond Hettinger
-
Skip Montanaro