[Grok-dev] Legal stuff howto
uli at gnufix.de
Wed Feb 17 05:25:06 EST 2010
Martijn Faassen wrote:
> Uli Fouquet wrote:
> > Therefore I started a 'Legal Stuff' howto on grok.zope.org (not public
> > yet):
> > http://grok.zope.org/documentation/how-to/legal-stuff/
> The Zope Foundation does have some policies for the
> (see the Intellectual Property Policy document)
I included this link and will give it more attention in the whole
> Some feedback to the document:
> > Warning: Code hosted on svn.zope.org must be ZPL-covered!
> I'd write this as "Code hosted on svn.zope.org must be covered by the ZPL"
> You then say immediately the following:
> > 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.
> The problem is that this you say immediately after the svn.zope.org
> guidelines, which make this tricky.
Right, I changed the order and used more cautios expressions to express
the problems here.
> I believe from the top of my head that svn.zope.org *does* allow other
> non-copyleft licenses (i.e. no GPL), but only when special permission is
> given by, probably, the ZF board. More is likely in that PDF above, but
> I'm in a hurry. :)
Looked into the committer-agreement text and you're right again. I now
tried to consider that throughout the whole doc.
> > 3. [maybe optional] mark each header file in your sources with a
> > license header like this (if you use ZPL as license):
> I often don't do this, but I guess that's more laziness than anything
> else. I don't know whether it's required, though it is a community practice.
This might be a misunderstanding resulting from my clumsy terms: my
impression was, that you only have to use copyright-headers if it is not
entirely clear what license covers a certain file in your project.
This can normally only happen, when a project is covered by multiple
licenses. So, for normal cases (one package, one license) I don't think
you're required to mark each source file (although it might be a good
practice and I remember that Philipp alway insisted on it). That's a
guess only, though.
> > What license should I pick?
> While I agree that GPL is a legitimate license to pick, I do prefer a
> non-GPL license myself for non-applications (libraries, frameworks,
> etc). That's for the selfish reason that I don't want me or my customers
> to have to worry about the GPL provisions, which spreads around. That's
> also, as far as I understand, the general philosophy of the Zope
> project. Anyway, that's just a personal opinion, I guess it doesn't
> belong in this document.
Yup, I'll try to keep the document more neutral in that respect. The
least I'd like to do is starting another whats-the-best-license-war :-)
> Another note I have is the pattern we've picked with hurry.yui and
> that's under another license in svn.zope.org, we've instead adjusted the
> release procedure so that this code is downloaded and packaged along in
> the tarball just before the release to pypi. This way the code in
> svn.zope.org stays cleanly ZPL and we don't check in a huge ball of
> external code.
I also thought about this and included a small section about this
> Unfortunately the license field in setup.py only allows us to mention
> one license. I've used 'ZPL' there, but that is somewhat misleading. So
> perhaps we should make it "ZPL + MIT" if the project that's included is
Regarding the license field I think one can of course mention multiple
licenses in this way. One certainly should add the respective licenses
also in classifiers field, which, AFAICT also accepts multiple 'License'
entries like this::
classifiers = [
'License :: OSI Approved :: Zope Public License',
'License :: OSI Approved :: MIT License',
license = 'ZPL + MIT',
Dank je wel for all the input! That was really what I was looking for!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20100217/842d9814/attachment.bin
More information about the Grok-dev