<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hi Andrew,</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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.<br>
    </div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">You've mentioned data formats, however
      these aren't covered by copyright law so lie outside the gamut of
      licensing.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">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.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">"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:</div>
    <div class="moz-cite-prefix">
      <ul>
        <li>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.</li>
        <li>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.<br>
        </li>
      </ul>
      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.</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">- Roland</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <div class="moz-cite-prefix">
      <hr width="100%" size="2"><br>
    </div>
    <div class="moz-cite-prefix">On 26/12/20 8:50 am, Andrew Nassief
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHgftsJ5x1AYYVVADTHaueaHwN4-2WHoQeYLLkb3EFkwhcRe2g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hi, I would like to submit my license for approval. The
          LICENSE.md file can be seen on <a
            href="https://github.com/StarkDrones/OIN/blob/main/LICENSE.md"
            moz-do-not-send="true">GitHub</a> with its available
          markdown. For sake of simplicity, here is the raw text of the
          license:</div>
        <div>
          <h2><strong>Released under the Open Innovation License</strong></h2>
          <p>Copyright © // Insert information of license holder</p>
          <p><em>Version 1, 10th November 2020</em></p>
          <p><em>Copyright © 2020 Stark Drones Corporation</em><br>
            <em>Copyright © 2020 Andrew Magdy Kamal</em></p>
          <p>This project is licensed under the <em>Open Innovation
              License</em>. 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.</p>
          <h5>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.</h5>
          <p>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.</p>
          <p>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.</p>
          <p>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.</p>
          <p>____</p>
          <p><em>Rationale:</em><br>
          </p>
          <p>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. <br>
          </p>
          <p>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.</p>
          <p>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.</p>
          <p><em>Distinguish:</em></p>
          <p>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.</p>
          <p><em>Legal review:</em></p>
          <p>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.</p>
          <p><em>Proliferation category:</em> <br>
          </p>
          <p>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 <i>Licenses
              that are popular and widely used or with strong
              communities </i>category.<i><br>
            </i></p>
          <p><em></em></p>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
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
<a class="moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org">License-review@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>