[License-review] Approval: OIN License (Open Innovation License)

Roland Turner roland at rolandturner.com
Sun Dec 27 06:39:57 UTC 2020


Hi Andrew,

Given the importance of limiting the number of authorised licenses in 
order to maintain their value for ease of selection and for 
interoperability, I'd suggest that a fundamental test is whether you've 
identified a substantial use case which the existing approved licenses 
either can't serve at all, or where there is some material problem with 
doing so. You don't appear to have done anything like this.

You've mentioned the desirability of an open source license not being 
specific to software. Although true, this ground is already very well 
covered by Creative Commons. If OSI were to authorise licenses of this 
type, it would appear that selected CC licenses might be a better 
starting point as they have the benefit of years of review and iteration 
by lawyers in dozens of jurisdictions and a almost a billion covered works.

You've mentioned data formats, however these aren't covered by copyright 
law so lie outside the gamut of licensing.

Others have commented on the contradiction ("agrees to ... not legally 
enforceable"), apparently arising from your desire to embed a mission 
statement. The usual way to handle this in the construction of legal 
instruments is to shift statements of principle into a preamble, either 
a section specifically headed Preamble (e.g. Gnu licenses) or more 
traditionally a section starting with the word "whereas" which contains 
a series of statements of belief (recitals). Either is fine, but 
explicitly wording in the fashion of a license condition and then rowing 
it back in the following paragraph invites abuse. There's no reason to 
do this. Note that it should generally be the case that the license 
conditions are those reasonably necessary to implement the recitals. 
Without this relationship, a court is going to have real trouble 
discerning the intentions of the parties.

You've made several aggregate statements characterising existing 
approved licenses, but you've not provided a license-by-license 
analysis. This invites the interpretation that your claim is incorrect 
because it's missed an appropriate existing license. I'd suggest 
providing a table with a row for each existing approved license and a 
column for each of the claims that you're making about the 
inapplicability of the existing licenses. If your claim holds then it 
will pretty quickly be apparent from this sort of analysis.

"technology for the betterment of humanity not meant with the intention 
to harm a human being" ... "technologies that are harmful to human 
activity". Apart from the abuse risk inherent in such ambiguous phrasing 
(the most obvious example is that armaments both harm and protect, but 
there are many others) (the enormous legal cost to resolve the ambiguity 
is a material harm; so is the threat of such costs), this is more 
broadly a present area of difficulty for OSI:

  * On the one hand society at large is becoming more aware of harms
    done by people and organisation previously unobserved and wants to
    do something about it.
  * On the other hand, the knee-jerk response to impose any obstacle
    within our control in the path of evil-doing or -doers — including
    use limits in software licenses — amounting to limits on use in
    particular fields of endeavour. I've previously referred to UN
    OHCHR's test for determining when to use such measures and that in
    general licensee-self-service software licensing is an
    inappropriately blunt tool for this.

This is more or less a repeat of the observation above about embedding a 
mission statement in the license text. I wonder, would you consider 
instead moving the mission statement into a separate manifesto which is 
not part of the license, and including a license condition that all 
copies include a verbatim copy of it? I have no idea whether OSI would 
approve such an arrangement, but it simultaneously solves the problem of 
making clear that statements of belief/mission don't form enforceable 
obligations and advances reuseability in that different projects are 
likely to have quite different statements of mission or belief.

- Roland

------------------------------------------------------------------------

On 26/12/20 8:50 am, Andrew Nassief wrote:
> Hi, I would like to submit my license for approval. The LICENSE.md 
> file can be seen on GitHub 
> <https://github.com/StarkDrones/OIN/blob/main/LICENSE.md> with its 
> available markdown. For sake of simplicity, here is the raw text of 
> the license:
>
>
>     *Released under the Open Innovation License*
>
> Copyright © // Insert information of license holder
>
> /Version 1, 10th November 2020/
>
> /Copyright © 2020 Stark Drones Corporation/
> /Copyright © 2020 Andrew Magdy Kamal/
>
> This project is licensed under the /Open Innovation License/. This 
> means any code, file, diagrams, data format, or other innovation 
> containing this license within it can be copied, modified, 
> redistributed, published, or even used for commercial purposes within 
> the context of this license.
>
>
>           Any code, file, diagrams, data format, or other innovation
>           containing this license is understood to be fully "AS IS",
>           no claims are made in regards to safety, security, warranty,
>           usability, or other form of merchantability and
>           market-readiness. In no events are copyright holders,
>           authors, or publishers are to be held liable for any claims,
>           damage or results from usage of what have been licensed
>           under this license.
>
> The context of this license includes: Keeping this original license 
> text verbatim and permissive notice, as well as the copyright notice 
> included in any redistribution of said project. Project is defined as 
> what is using this license. For purposes of context, the copyright 
> notice above version and year is meant to be modified for whomsoever 
> publishes or releases "any code, file, diagrams, data format, or other 
> innovation", so that they can include their information. After 
> modifying, the comment saying "// Insert information of license 
> holder" which starts with // can be removed. This current paragraph 
> however, will remain in-tact.
>
> Anybody who releases software under the "Open Innovation License" 
> agrees to at goodwill, build or release technology for the betterment 
> of humanity not meant with the intention to harm a human being. They 
> agree to a prima facie moral duty through consequential deontology to 
> understand that technology should be within the concept of moral good 
> or outcomes that are morally right and/or ethical. They agree at 
> goodwill to promote the advancement of humanity and civilization as a 
> whole. They agree to a sense of adventurement, edification, and the 
> expansion of the human mind.
>
> Said agreement which is within the last paragraph prior to this 
> sentence is meant to be taken as a general consensus, but not legally 
> enforceable. Again for context, the last paragraph which starts with 
> "Anybody" and ends with "human mind" minus quotations, is outside of 
> the boundaries of being legally enforceable and within the duties of 
> oneselve's actions. The rest of the license which includes the 
> copyright notice and its context is within a legally enforceable 
> context. For secondary context, the rest of the license refers to 
> anything outside of that said paragraph.
>
> ____
>
> /Rationale:/
>
> I wanted to release this license for a variety of different reasons. 
> Infact, I made many posts in regards to why this license is unique and 
> valuable, and found many developers willing to adapt this license 
> through small innovation challenges. The license was made on the basis 
> of promoting a mission statement on ethical technology within the 
> license as well as not being specific to only software i.e. files, 
> diagrams, data format or any other innovation.
>
> We also wanted to make sure that the license is adaptable. Many open 
> source licenses require you to put tons of header files for 
> compliance. We wanted to make a license that just requires you to 
> contain the license file in your directory. While many other open 
> source licenses also do that or follow in similar footsteps, we 
> weren't able to find one that met all these unique qualities.
>
> Currently, a big inspiration for this license was the idea of 
> promoting free and open software as well as a mission statement on 
> ethical technologies. We found that many of the big tech companies 
> that are hailed as heroes of open source or doing open source 
> initiatives, built technologies that are harmful to human activity. A 
> technically non-legally enforceable mission statement within an 
> enforceable open source license was the way to go. We also made sure 
> to go out of our way to promote the ideals of open source and free and 
> redistributive software.
>
> /Distinguish:/
>
> I looked at a variety of different open source licenses. The standard 
> being MIT, then BSD+Patent, ZLib, CDDL, CPAL, CPL, CAL, BSL, and the 
> AFL license. I feel like MIT, ZLIB, and the Boost licenses focus on 
> redistribution and code. Those are the standards. The open patent 
> licenses and other licenses focus on derived original work. However, 
> none of them tried going to the same extent I wanted in terms of being 
> specific in regards to data formats or general consensus and mission. 
> I believe this is an important thing to take into account.
>
> /Legal review:/
>
> Currently I have submitted this to SPDX as well for review through 
> their GitHub/Website. However, the review time to get approval and 
> receive SPDX identifiers can be many months. I submitted in November 
> and decided to submit to OSI while I wait. As for reviewing the 
> context of language myself and actual legal review, I have thought out 
> reviews through my own legal council and self judgement as a 
> researcher familiar with these types of languages.
>
> /Proliferation category:/
>
> I don't necessarily need to be in a Proliferation category as of now, 
> as many of the licenses on your site are not in a category. However, I 
> would eventually want to get into the /Licenses that are popular and 
> widely used or with strong communities /category./
> /
>
> //
>
>
> _______________________________________________
> The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Communication from the Open Source Initiative will be sent from an opensource.org email address.
>
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20201227/02068211/attachment-0001.html>


More information about the License-review mailing list