[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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 ?


Reply to: