M.-A. Lemburg 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.

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

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

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

Jack Jansen wrote:

On the other thread: will including the copyright notices/acknowledgements in the documentation be good enough if we don't always ship the documentation?

This is exactly my concern. It is essentially for people producing binary distributions to decide how they want this to be organized.

Or should we put this in a special section that is always shipped, even with binary installers that don't include documentation?

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

M.-A. Lemburg 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).

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

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:

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?

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"?)

...

...

import mycoolpackage mycoolpackage.copyright 'All rights to the use of mycoolpackage are hereby granted to the PSF. \n\n enjoy - authors of mycoolpackage\n'

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.

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.

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 ################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################

On Monday 30 December 2002 01:11 am, 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.

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).

+1 A script to generate the section in the documentation would keep the binary distribution in sync with the paper docs.

...

...

...

...

"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 wrote:

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...

The license is also copied in the documentation for that module, so I believe everything is OK.

...

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

-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.

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)

-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).

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.

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/

[MAL]

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).

This seems to be the most straight-forward way to go. If everyone agrees, I'll start the ball rolling by adding the verbatim text for the MersenneTwister code. Raymond Hettinger