[License-discuss] Request Discussion Pre-Reviews For New Licenses (chewkeanho-rlos, chewkeanho-cos, chewkeanho-gpos)

Wed Oct 2 02:52:05 UTC 2024

On Tue, Oct 1, 2024 at 11:58 PM Pamela Chestek <pamela at chesteklegal.com> wrote:
>
> To add to this, IIRC the BSD-Clear license is not an OSI-approved
> license specifically because it is meant to withhold patent rights.
>
> Pam
>
>
>> On Tue, Oct 1, 2024 at 11:47 PM Josh Berkus <josh at berkus.org> wrote:
>> The BSD-2-Patent license specificially *grants* limited patent rights.
>> Your license specifically *denies them*, so I don't understand how it's
>> "based on" the approved license.

My bad. I misinterpreted BSD-2-Patent but the context understanding is
correct. Basically, I have 2 options:

1. Drop those 2 clauses; OR
2. Update those 2 clauses to grant the permission.

I won't do (1) because I personally think it's irresponsible for the
downstream (as in, kicking the can down the road) to wildly figure out
what to do with the Registered IPs. Not something I'm proud of or have
the passion to maintain.

If I do (2), then rlos becomes cos. Hence, the convergence. Well, it's
not a bad thing because:

(a) 1 less license to maintain.
(b) The cos license value becomes higher.

I may have to re-title the cos license (maybe "Commercial & Libre" -
clos) to better represent the convergence.

On Wed, Oct 2, 2024 at 1:28 AM Bruce Perens <bruce at perens.com> wrote:
>
> The word "SHALL" must not be used in a license. Please replace all occurrences of "SHALL" with "MUST" and see https://www.plainlanguage.gov/guidelines/conversational/shall-and-must/ for the reasons you must do so.
>

That website is a great resource! Thank you so much for sharing. I
will work on it.

> I am assuming you are not a legal professional, I think one would not have missed that issue by now.

You are absolutely right. I'm a software developer at core now dealing
with multimedia work. I'm also a CI tool maintainer+developer that
facilitates more than just source code development.

> In my own license drafting, I am very careful not to propose that anyone use the text until my own lawyer has revised it for legal correctness. Please see 1.6 at https://perens.com/static/DEVELOPMENT_LICENSE.txt for the disclaimer I apply, which also states why it is a bad idea for a non-legal-professional to inflict a license upon the Open Source developers.
>

Noted. I shall add the warning notice asap. Thanks for sharing your
template. I will reference it for the next upgrade.

> I was expert witness in the appeal of one of the first Open Source license cases, which resulted from Larry Wall drafting the Artistic License 1.0 without the knowledge of a legal professional, resulting in the lower court judge parsing it as a simple dedication to the public domain. The lawyer I worked with was the dean of law at a big college. We, and the court, all spent a lot of time fixing something we would not have had to fix had Larry used a lawyer. In his defense: no lawyer would help us draft licenses at the time, indeed few would talk with us at all and many of those only in anger. But that is different today.
>
> You should also not assume that OSI or this mailing list is your legal review. They aren't your lawyer and a good many lawyers do not participate in this activity due to liability and other issues of giving legal advice to people they aren't contracted to.
>

All right. Point taken. I just need to find a way to raise funds for
hiring a lawyer to review at least 1 time.

> On Tue, Oct 1, 2024 at 11:47 PM Josh Berkus <josh at berkus.org> wrote:
>
> Can you explain this goal in more detail?  I think this is the
> interesting part to discuss.

Basically I'm attempting to create a foundational license framework to
meet today's composite project needs (e.g. a single repo can release
source codes, images, video, audio, etc) in a single release. As we
all know, each element has its own license. Example:

(1) Source codes - Apache 2.0;
(2) Images - CC-BY-SA-4.0;
(3) Video - CC-BY-ND;
(4) Website - Apache 2.0? for HTML and the other web components are --
well that's another cycle of complications.

So in a single release based on the example above, my outbound license
has a minimum of 3 types since Apache-2.0 is specifically for software
and CC can't offer what Apache 2.0 can. The general practice is to
staple all the licenses into 1 thick file so complex to know which is
what for; pass it down to the customers; pray they don't come back
with a dispute.

That's the initial reason I started the effort - to make sure the
outbound license is only 1 single type carries the same legal effect
for all kinds of files so that customers (including non-legal folks)
can understand it. That's where the: "cos", and "gpos" are drafted
where "gpos" is based on GPLv2 with strong copyleft while "cos" is the
one without.

Note that the "gpos" is written based on what I understand from my
past linux kernel development experience (no offense: FSF's GPLv2 is
so hard to read). There is a slight difference: "gpos" can designate
"Externally Usable Interface" where the copyleft is bounded mainly for
removing the fear of copyleft effect when using the product as
specified (based on what I observed from Linux kernel in the past).
Consumers can be both commercial entities and the general public.

The naming conventions using simple terms were intentional since the
primary target audience is non-legal developers or artists (usually
without legal attorney).

Then that AI training drama came in, I basically just added a license
trigger where the currently disputing "Right to Learn" comes after
"Right to Use" (as in you have to use the dataset with read permission
in order to learn). This forces those AI data harvesters to comply
with the license rather than that "I didn't use it so I don't have to
comply" attitude.

Then along the way, after analyzing a bunch of licenses, I realized
there is a missing fallback "proprietary" license for the case of
"excited junior executive" who loves sharing IP to social media
without much consideration. That's why I purposely drafted the
"proprietary" license alongside the "cos" license based on CC "rights
of use" identification. The idea is:

1. When a project is created - it shall always be the "proprietary"
outbound license first. When a junior executive accidentally leaked
stuff, the proprietary license's effect is in so the senior executive
and the attorney can still have a chance to fire-fight. It also
simplifies the CI tools developer as we only need to issue 1 type of
license and tell the users where and how to re-license.
2. The proprietary license can also use "License Grant" with
overriding t&c acting like how we consumers can understand - Right to
Use, How to pay, Open Core, Tivoization, or whatever funky licenses
claimed to be "open-source" etc.
3. The product owner can also re-license to any open-source license anytime.

Yes, I know - the proprietary license is not open-source. I am just
stating the relation and why it was born; not planning to submit to
OSI for review. Disclaimer: the "proprietary" carries its general
terms; as in, not specific to/from me.

Then towards the clean-up, when I cross checked with MYIPO, I realized
existing licenses missed out other registered IPs apart from patent
(Industrial Design, IC Layout Design) and new identifiers
(geographical indicator (GI), designation indicator (DI), Protected GI
(PGI), Protected DI (PDI)), etc. Hence, I also looked into USPTO,
EUIPO, and CNIPA before performing another upgrade.

These new licenses must not deter and restrict the use of existing
licenses. They must not carry anything specific to me (except I'm an
author and my name for SPDX application in case they are approved).
That's all my intention - some upgrades & updates here and there +
simplify things for a composite project.

Since OSI governs "Open Source" definitions, hence, here we are,
making sure those open source licenses are truly open-source.

Thanks for your time and patience with me. I was very scared entering
into the legal industry.

Regards,
Holloway