[License-review] Submission of OSET Public License for Approval

Meeker, Heather J. hmeeker at omm.com
Mon Sep 7 17:49:21 UTC 2015

Thanks, Gerv--

Re: The first point, thanks for the clarification.  I was responding to the insistence that we use GPL3 instead of our license.

Re Notices.  I remember the discussion about "unbloating" the licenses notices when we were working on MPL2.  We prefer to include this requirement for the time being, for the information we hope it will preserve.  As you note, that might be an impractical hope.   If it becomes a practical issue, we might consider a modification.

Re: Compatibility of various "flavors" that might result from variance of terms under 3.5B.  We understand this could become an issue.   As steward of our software projects, we hope we can sort out downstream variances on a practical level by harmonizing  contributions upstream.  


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Thursday, September 03, 2015 1:38 AM
To: License submissions for OSI review
Cc: Gregory Miller; John Sebes; Meeker, Heather J.; christine at osetfoundation.org
Subject: Re: [License-review] Submission of OSET Public License for Approval

On 01/09/15 23:18, Meeker, Heather J. wrote:
> The Open Source Election Technology Foundation (OSET) is pleased to
> submit the OSET Public License (OPL) for OSI license review and for
> discussion with the larger community.

Hi Heather,

A few thoughts, based on the Rationale document which helpfully explains
the difference from the MPL 2.0:

A) "In addition to our license, the software may alternatively be
licensed under the GNU General Public License (GPL) version 3.0 or the
GNU Lesser General Public License (LGPL) version 3.0."

As a matter of fact, both the MPL 2.0 and the OSET licence as written
permit dual licensing under the GPL _2.0_ or later or the LGPL _2.1_ or
later, which is a broader permission than this restatement.

B) "3.1 Notices. We added language requiring licensees who modify the
software and distribute their modified versions to include prominent
notices stating that the files have been changed. We borrowed this
language from the Apache Software License version 2.0."

What led you to do this? To my mind, this clause in Apache is:

1) generally ignored
2) a pain in the ass to comply with
3) pointless

1), because I rarely see Apache-licensed files, reused in other
projects, which contain a "This file has been modified on 2015-04-03"

2), because it adds to header bloat, and you have to remember to do it
every time, and teach all your engineers and community members about the

3), because the next person who changes it can remove the older notices
that the files have been changed and include only their notice (unless
this clause is a restriction on modification, which I hope it is not) so
the information from the "this has been changed" notice can tell you
nothing useful for certain. In these days of distributed source control
mechanisms and good diff algorithms, there is nothing that such a notice
can tell you that such a system could not tell you in a much better and
more convenient form.

For these reasons, we did not carry over the similar clause from the MPL
1.1 to the MPL 2.0. How did you come to a different conclusion? What
good purpose can this added information serve?

C) "3.5B Application of Additional Terms. We allowed additional
conditions specifically to address national security or public interest
concerns as well as state and federal procurement regulations. This is
an important aspect of the unique target audience for this license –
federal, state, county, and/or municipal elections administration
agencies. "

How do you assess the OSET license's compatibility with versions of
itself with different provisions added under this clause?


More information about the License-review mailing list