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

[Meeker, Heather J.]

Re: Aren't you assuming that such an open source technology system will not contain any
GPL-licensed software....

No, we are not at the point of making such assumptions.  We don't expect to limit this license to only one software package, so there are many possible configurations of software and attendant licenses.   If this is a licensing compatibility concern, the OSET license is no less compatible with other licenses that most copyleft licenses already approved, and more so than some approved licenses.  If this is a question of whether election procurement managers are likely to accept our license, then that is a different question.  (Please see my prior post on this point.)  

Re: One other question: MPL 2.0 allows using different terms for
'Executable .....

So does OSET (we use the same provision as MPL2 2.0), but we are assuming that provisioning election systems will include delivery of source code -- or at least, that we need to allow for that possibility. 

-----Original Message-----
From: License-review [mailto:license-review-bounces at opensource.org] On Behalf Of Richard Fontana
Sent: Sunday, September 06, 2015 11:03 AM
To: License submissions for OSI review
Subject: Re: [License-review] Submission of OSET Public License for Approval

On Tue, Sep 01, 2015 at 10:18:59PM +0000, Meeker, Heather J. wrote:
> Our stakeholder community—elections administrators and officials—are very
> receptive to acquiring open source software-based election and voting systems
> provided the software (and related support and services) can be legally
> acquired through their procurement process.  A primary ingredient of their
> procurement process is terms and conditions of software licensing that meet
> their regulatory requirements.
> 
> While governments already often acquire open source technology on an ad hoc
> basis under existing licenses, they face more, and different, hurdles acquiring
> open source election systems.  Open source software that is merely part of a
> larger IT system is usually covered by two documents—the open source license,
> and an overarching (and often superseding) procurement agreement that fits with
> the applicable regulations.  Where an agency is acquiring an entire open source
> technology system—especially technology to be used in public elections and
> subject to competitive bidding—procurement regulations need to be handled
> properly within the four corners of the open source license.  

I'm trying to understand this particular point. Aren't you assuming
that such an open source technology system will not contain any
GPL-licensed software, perhaps not any copyleft software (perhaps not
any software under any other open source license -- in other words are
you assuming that the 'technology system' will consist solely of
software under the OSET-PL)? Because otherwise you have a
mixed-license product where only some portion of the product is
licensed in such a way as to meet your goals.

One other question: MPL 2.0 allows using different terms for
'Executable Forms', so presumably you could meet your objectives here
by way of an appopriate non-open-source license for the Excecutable
Form. Why is MPL 2.0 not suitable - is it because you expect to be
distributing 'Source Code' (as defined in OSET-PL/MPL 2.0) in a
procurement context, or is it because of some desire to be able to
claim that the license used in the procurement context is open source?

Richard
_______________________________________________
License-review mailing list
License-review at opensource.org
https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review