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

Roland Turner roland at rolandturner.com
Sun Dec 27 07:20:13 UTC 2020


I meant to comment on the name:

On 26/12/20 11:36 pm, Andrew Nassief wrote (in reply to McCoy Smith):

> The only other inquiry you have is that OIN may accidentally suggest 
> affiliation with Open Innovation Network. The term open innovation is 
> used alot in technology and the Open Innovation Network is not 
> considered an open source license. I was originally going to be using 
> OIL as an acronym, but I think it may present unwarranted liabilities 
> making an acronym for a license after a commodity. Also I was going to 
> adapt OINN, but I didn't see a need to have two Ns. Since there are 
> actually no license agreements using OIN as an acronym, I still think 
> it should be fine. The Open Innovation Network acquires patents and 
> licenses them as royalty free as long as people who use them don't 
> agree to make patents against Linux Systems (See 
> http://xml.coverpages.org/OIN-Announce.html 
> <http://xml.coverpages.org/OIN-Announce.html>). If we were going to be 
> using the same logic on acronyms one can say that the COPL license 
> might have people confused w/ Concurrency Oriented Programming 
> Languages or that NTP may be affiliated with New Trade Policy or 
> India's New Telecom Policy or Nordic Innovation's NTP program. Outside 
> of specific license acronyms like ZLIB, the same can be said about 
> other licenses. Since OIN isn't an open source license identifier 
> currently, I still want to proceed with it as an acronym and think for 
> simplicity's sake it should be fine for now.

Given the proximity of OIN's work to open source generally, I'd suggest 
that there's a real problem here that doesn't exist in the other 
examples. In the context of open-source licensing, it would seem a 
surprising fact that "the OIN license" had nothing to do with OIN. The 
other examples wouldn't be surprising in the same way because they 
aren't organisations working solely or primarily on a major problem for 
open source software.

I'd suggest that effort expended arguing for sustaining a confusing name 
might better be spent finding another. There's any amount of room...

  * You could adopt the German style: OpInLi.
  * You could use minimally-identifying consonants: OInL, although this
    still risks confusion with OIN.
  * You could be clearer about your purpose: The safety-promoting open
    innovation license, although the acronym may not appeal.
  * Etc.

- Roland


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

>
> 	
>
>
> On Sat, Dec 26, 2020 at 10:02 AM McCoy Smith <mccoy at lexpan.law> wrote:
>
>     This one probably needs some careful legal and grammatical review
>     as it is very awkwardly drafted and potentially confusing/legally
>     ambiguous. Its current draft is probably not approvable.
>
>     The grant itself is drafted in a way that could be read to
>     restrict the license to only commercial uses, which obviously
>     would violate the OSD.
>
>     The context statement could also be read as a legally binding
>     restriction on the license grant (the use of “agree” is mainly the
>     problem), although it seems the intent is **not** to have those
>     statements to be legally binding but instead merely suggestions.
>     I’m not sure the language used accomplishes that goal.
>
>     The interesting issue this license raises is whether legally
>     non-binding statements that would, if legally binding, violate the
>     OSD, can nevertheless satisfy the OSD. I tend to think if they are
>     drafted in a way that they are unambiguously non-legally binding,
>     they probably would be, but it does present an interesting test of
>     the OSD and I suspect once a license of that sort is approved, you
>     will likely have many submissions of licenses with non-legally
>     binding statements of ethical principles following.
>
>     I’d also suggest the use of “OIN” as the shorthand name of the
>     license is likely a problem and it would likely suggest an
>     affiliation with the Open Invention Network, which I’m pretty sure
>     this license isn’t.
>
>     *From:* License-review
>     <license-review-bounces at lists.opensource.org
>     <mailto:license-review-bounces at lists.opensource.org>> *On Behalf
>     Of *Andrew Nassief
>     *Sent:* Friday, December 25, 2020 4:50 PM
>     *To:* license-review at lists.opensource.org
>     <mailto:license-review at lists.opensource.org>
>     *Subject:* [License-review] Approval: OIN License (Open Innovation
>     License)
>
>     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 <http://opensource.org> email address.
>
>     License-review mailing list
>     License-review at lists.opensource.org
>     <mailto:License-review at lists.opensource.org>
>     http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>     <http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org>
>
>
>
> -- 
> Andrew Magdy Kamal
> http://andsocialrew.wall.fm <http://andsocialrew.wall.fm>
>
> _______________________________________________
> 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/cf81caf9/attachment-0001.html>


More information about the License-review mailing list