Approval of IWL - Consolidated Response

[Gernot Heiser]

Folks,

Please excuse me for sounding naive, but this whole process has
totally lost me, and I'm looking for some explanation on how it's
supposed to work.

We really tried to do the right thing. We looked for an OSI-approved
license to match our requirements, and the closest we could find was
the SleepyCat license, which is not re-usable.

So we applied minimal changes (plus some clarifications) to make it
re-usable. This would seem like the obvious approach.

We also avoided a vanity license, by choosing a name that is not
derived from the name of the company or one of its products.

We didn't assume that this would automatically get it certified, so we
looked at the criteria, which we understood to be the OSD. We could
not find any reason why our license doesn't conform with the OSD.

It seems to me that arguments are boiling down to OSD compliance not
being sufficient. So the OSD isn't the definition of what's open
source, but just a partial list of requirements? And the full list
isn't available anywhere?

We certainly didn't attempt (as seemed to be implied by some comments)
to subvert open source in any way. The OK Labs team is full of people
who for years have played prominent roles in the open source movement
in Australia, we're serious about this.

Please help me understand.

Gernot
CTO and Founder
Open Kernel Labs

-----Original Message-----
Subject: Re: Approval of IWL - Consolidated Response
From: Bruce Perens <bruce at perens.com>
To: Brendan Scott <lists at opensourcelaw.biz>
Date: Tue, 27 May 2008 08:57:28 -0700

Brendan Scott wrote:
> To that end, OKL is operating from the understanding that all of the substantive issues with the licence relate to clause 1(c)(ii) of the licence text.  If this is not the case, please let me know.
>
I don't think anyone has bothered to focus on smaller issues of the
license after seeing that the bigger ones would keep it from passing.
These will have to be addressed once the larger problems are fixed.
> Further, comments on clause 1(c)(ii) have related to OSD #6 and OSD #9 (by Mr Perens and Mr Flaschen).  Despite Mr Perens' subsequent post it is not clear to OKL that clause 1(c)(ii) results in an issue with either OSD #6 or OSD #9.  More importantly, if it does result in an issue, why  - if it is to be remedied OKL will need to understand the cause of the concern.  Is the main issue here the one raised by Mr Rosen (that the licence may overstep the bounds of (US) copyright law)?
>
It's not just the law. An OSD-compliant license should not encumber
programs that just _use_ it, and the OSD provisions noted read against
that sort of use.
> In addition there have been some comments about the use of a program licensed under the IWL.  The licence permits the use of the program.  Each of the conditions 1(a)-(d) in the licence is preconditioned on there being a "redistribution".
Yes, but this is a redistribution containing 1) the IWL program, and 2)
a program that just makes use of it but is to be encumbered.

So, I think it's not a problem with the license text, so much as it is
that what you are trying to do just doesn't work in an Open Source
license. You are not the first to hit this issue, it's been a problem
for MySQL, because their main product was a server and there were
non-GPL libraries that could access it. I think you can write some sort
of shared-source or proprietary license that does what you want. As
Rosen said, it has to be through contract law.

    Thanks

    Bruce