Legal stuff¶
Author: | Uli Fouquet |
---|---|
Version: | n/a |
About license files, source headers, fair use and friends
Licenses, Fair Use and Friends¶
If you’re a developer, if you plan to create a new software package and chances are, that this package will be made publicly available, then you have to fiddle with licenses and legal stuff.
Here you can find some hints, how to design your software package layout in a way, that satisfies most people that are seriously concerned with legal issues. The hints given here are often so-called “good practices” known to work. This means: they are rules, not laws. In the end it is up to you.
In short, it comes down to this:
When you create a package:
add a
LICENSE.txt
or similar file to the root of your project (i.e. besidesetup.py
andbuildout.cfg
).If you reuse code from others with different licenses, add these licenses as well. You might then have a
ZPL.txt
,LGPL.txt
in your project root.Warning: Projects hosted on
svn.zope.org
should usually be covered by ZPL only. See your Zope Committer Agreement for exceptions from this rule.set the apropriate attributes in your project’s
setup.py
like this:#... license='ZPL 2.1', classifiers=[ ... 'License :: OSI Approved :: Zope Public License', ... ] #...
or similar, depending on the license you picked. Make sure the license you set here is the same as mentioned in
LICENSE.txt
.If your code is covered by multiple licenses, you should add an appropriate classifier for each and set the
license
attribute to something like'ZPL + BSD'
.[maybe optional] mark each header file in your sources with a license header like this (if you use ZPL as license):
##############################################################################
#
# Copyright (c) 2010 Zope Foundation and Contributors.
# All Rights Reserved.
#
# This software is subject to the provisions of the Zope Public License,
# Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution.
# THIS SOFTWARE IS PROVIDED "AS IS" AND ANY AND ALL EXPRESS OR IMPLIED
# WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
# WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS
# FOR A PARTICULAR PURPOSE.
#
##############################################################################
This step is not optional if your project contains code covered by different licenses. Adding this header you tell which of your source files is covered by which license.
If all your code is covered by one single license, you don’t have to do this (but you can).
Again, the text you use in header depends on the license you’ve chosen in step one.
Licenses¶
Each package that goes into public should be licensed. This way you can tell people the conditions under which they can use, reuse, modify and distribute your code.
Who is allowed to choose a license?
The only one that has the right to choose a license for a package is the author of the package. If there are several authors, all of them have to agree with a license (or a license switch).
What license should I pick?
In the grok eco-sphere we usually use open-source licenses like BSD, GPL, LGPL, or ZPL. You can pick whatever license you want as long as you have the right to do so and the license is compatible with your hosting location and other special circumstances.
- Warning: People that host their code on
svn.zope.org
should- pick the ZPL! See your committer agreement for exceptions from this rule.
Why is setting the license in ``setup.py`` not enough?
Because some distributors like Debian, Ubuntu, etc. require explicit license files for every source package they package in their distributions. If you add a license file and release your project on PyPI, the license file will become part of the uploaded sources and hence satisfy these requirements.
Can I use multiple licenses with a project hosted on ``svn.zope.org``
Yes, you can. But it’s a bit more complicated. If possible, you schould try to avoid such situations.
If, however, you have to make use of some code already covered by a non-ZPL license, you can avoid submitting the code to
svn.zope.org
by providing a script in your project, that downloads and packages the additional code on your local workstation. This code can then be tested, built and submitted to PyPI (which has no license restriction).See hurry.yui (section about preparing releases near bottom) for an example.
Code from others on svn.zope.org
¶
You can and you should use code from others. Hosting your code on
svn.zope.org
you might try to follow some rules as follows.
Am I allowed to reuse code already hosted on ``svn.zope.org`` code in my project?
Of course you can reuse code that’s already hosted onsvn.zope.org
. The best way to make clear that you use other peoples code here is to svn-copy it over from the other location onsvn.zope.org
to your project. This way others can follow the history of your code better:
$ svn copy -m "Copy foobar from baz." \
svn+ssh://myusername@svn.zope.org/repos/main/foo/trunk/src/foo/bar/baz.py \
svn+ssh://myusername@svn.zope.org/repos/main/myproj/trunk/src/myproj/baz.py
If that would be too much (as you might only need a little function from another module, for instance), you might want to add a comment telling where the function comes from. This might also be helpful when problems occur due to changed dependencies/changes in other packages.
# Copied verbatim from zope.app.spammachine.
# This way we don't depend on z.a.spammachine anymore, as we only need this piece.
def spamtheworld(target_num='20 zillions'):
"""Spam the world.
"""
...
In other words: if you use code from others, tell it somehow.
Am I allowed to commit code from other locations (outside ``svn.zope.org``) to ``svn.zope.org``?
As long as the other author(s) agrees and the foreign code is not covered by a non-ZPL license, it might be okay. You might want to ask on
zope-dev
first, before you submit such code.Submitting code that can also be found at other (non
svn.zope.org
) locations is not a problem, if the code is a small snippet that represents an ‘obvious’ solution for some problem. I.e. if your code would become artificially blown-up only to avoid repetition, then it’s likely that this is a case of fair-use.If you want to submit code that is not yours, not covered by fair-use, and not covered by ZPL, then this is almost certainly a problem, even if the original author agrees with your ‘borrowing’.
If in doubt, ask on
zope-dev
first before submitting.
Code on svn.zope.org
¶
Code hosted on svn.zope.org
should comply to the general policy of
the Zope Foundation (see below).
For developers there is a package available to ease this task.
Download and build
zope.repositorypolicy
:$ svn co svn+ssh://<USERNAME>@svn.zope.org/repos/main/zope.repositorypolicy $ cd zope.repositorypolicy/trunk $ python bootstrap.py $ ./bin/buildout
This generates helper scripts to check your project for repository compliance.
Run:
$ ./bin/zope-org-check-project <PATH-TO-CHECKOUT-OF-MY-PROJECT>
This will tell you what is missing or wrong in your package from
zope.repositorypoliy
-point of view.If you get no output, nothing is wrong with your package and you’re done.
If you get some output, you can fix the problems manually or run:
$ ./bin/zope-org-fix-project <PATH-TO-CHECKOUT-OF-MY-PROJECT>
to automatically add missing files, fix headers or existing LICENSE files, etc.
After running
zope-org-fix-project
you should make sure, that any new generated files are registered with SVN and update the history (CHANGES.txt
).Commit the changes.
Appendix: files, headers, forms¶
On http://foundation.zope.org/agreements you can find (amongst other things):
- The Zope Foundation Committer Agreement
- Zope Public License (current version, 2.1 as time of writing)
There are also general hints for new contributors and contributors-to-be: