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

Tue Sep 8 15:56:58 UTC 2015

Heather

It is true that your future success is not a useful yardstick in
general. Otoh, I think it is valid to ask whether your success will at
least be non-zero.

In other words, OSI should not approve a license which is likely to
never be used by any real world software used in production by real
users for some real world benefit. From this point of view I think
Richard's question merits a bit more detailed response. For example,
you might answer that the OSET stack intends to use Windows or FreeBSD
servers, since procurement officers at your customers will not allow
Linux.

henrik

On Tue, Sep 8, 2015 at 6:50 PM, Meeker, Heather J. <hmeeker at omm.com> wrote:
> Thanks.  I do think this is a license compatibility point, in a way.  Permissive licenses for third-party components would allow the code as a whole to be licensed under the terms of OSET.  But a copyleft license would not.  However, incompatibility with other copyleft licenses is not a problem we can solve own our own.  We have tried to do as much as we can to solve it on the outbound side with our license compatibility terms.  But on the inbound side, it's up to the third-party copyright owner.
>
> Assuming that such incompatibility does create an issue, then this question dovetails back to the question of whether we can be successful with the license.  In other words, if I can rephrase your question a bit, is it possible to build a complete enough voting system without using code under incompatible licenses?  It's a good point you raise.  But as I have commented before, our likelihood of success is not the criterion for license approval.
>
>
>
> Sent from my tablet --Heather Meeker
>
>> On Sep 8, 2015, at 8:34 AM, Richard Fontana <fontana at sharpeleven.org> wrote:
>>
>> My comment wasn't about license compatibility. Rather:
>>
>> Clearly OSET favored some kind of copyleft license, and you've made a
>> few comments about the GPL that seem to imply (possibly reinforced by
>> the comments of the CAVO folks, unless this was in response to those
>> comments) that in this open source voting systems space there is a
>> background community preference for the GPL, maybe even specifically
>> GPLv3.
>>
>> A main justification for having this alteration of MPL 2.0 seems to be
>> that the GPL license family would be inappropriate because it would
>> cause problems, possibly even contractually insurmountable ones, in
>> procurement. So my point is that this seems to assume that the
>> products being offered for procurement contain no GPL-licensed code,
>> and perhaps only contain OSET-PL plus code under noncopyleft licenses.
>> If they do contain GPL-licensed code -- for example, let's say a
>> software stack that includes the Linux kernel -- you've eliminated any
>> benefit you otherwise might have gotten from the novel features of
>> this license. (Similarly, if your stack includes any MPL 2.0 code, you
>> are stuck with the limitations of MPL 2.0 relative to the changed
>> features in OSET-PL.) One or more of the people from CAVO seemed to be
>> making a similar point.
>>
>> Thanks for the clarification about why MPL 2.0's 'Executable Forms'
>> provision is not sufficient for OSET's needs.
>>
>> Richard
>>
>>
>>
>>> On Mon, Sep 07, 2015 at 05:34:06PM +0000, Meeker, Heather J. wrote:
>>> 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
>>> _______________________________________________
>>> License-review mailing list
>>> License-review at opensource.org
>>> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
>> _______________________________________________
>> License-review mailing list
>> License-review at opensource.org
>> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review
> _______________________________________________
> License-review mailing list
> License-review at opensource.org
> https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review

-- 
henrik.ingo at avoinelama.fi
+358-40-5697354        skype: henrik.ingo            irc: hingo
www.openlife.cc

My LinkedIn profile: http://fi.linkedin.com/pub/henrik-ingo/3/232/8a7