Re: Proposed Grail and JPython Licenses
[I'd suggest cc'ing Guido in replies in this thread to (that's as I think
he's not subscribed to the list ? Guido, the thread is archived as
http://www.de.debian.org/Lists-Archives/debian-legal-9901/msg00211.html]
john@dhh.gt.org (John Hasler) wrote:
> Guido van Rossum writes:
> > A note on clause 4 (about OROmatcher, a regular expression package for
> > Java), which only applies to JPython. I expect that this may be a
> > show-stopper for Debian, since OROmatcher is only available in binary
> > form.
>
> It keeps the package out of main. It theoretically could go in non-free,
> but personally I find the clause so repugnant that I would rather not see
> it on any Debian servers at all.
Well, since OROmatcher easily can be removed from JPython (leaving Python
without regex support for the time ;-), this should be no showstopper--at
a later point, it should ne possible to replace OROmatcher with a free
replacement such as gnu.regex.
With the OROmatcher package removed, I guess the implications of (4) just
would be void, and we could distribute the package in main--certainly
adding a comment to /usr/doc/jpython/copyright that OROmatcher has been
removed to avoid this legal problem for Debian. That's to say: This
license grants Debian the necessary rights to remove OROmatcher and
redistribute an OROmatcher-less JPython in main, right ?
> > Let me know if this license works for Debian, and if not, what problems
> > it has.
>
> Without clause 4 it is just a verbose version of the modified BSD license
> and is therefor DFSG compliant.
>
> You should get rid of the "CLICKING ON THE SOFTWARE RELEASE BUTTON" stuff,
> though. It makes no sense in the context of a Debian package.
Can I summarize this as follows: The license looks DFSG-free and
therefore ok for us apart from (4).
(7) sounds a little bit obfuscated, but in the end it only says something
like "if you breach this license, we will try to tell you to stop
breaching, and if you didn't stop, we will terminate the
license", which sounds perfectly reasonable.
The bits about "pressing the button" etc. don't make sense in the license
document that accompies the source distribution.
Regarding (4): If possible, I think this could be resolved by splitting
the JPython license in two parts. The first one is the CNRI License
agreement, that applies to the code written by CNRI. The second part
would be the OROmatcher License agreement, which governs ORO's code.
Through the web interface or the binary installer, the licensee would
accept both licenses by clicking on the button. In the Debian
distribution, we could remove the could distributed under ORO's license,
and therefore also remove the ORO license agreement from the document.
To me, this looks like a perfect solution, isn't it ?
Gregor
Reply to: