[OT] Hybrid open-source licenses?

[Adriaan de Groot]

On Sunday, 24 January 2021 20:36:28 CET Bogdan Tanygin wrote:
> Maybe you could advise whether it's worth digging in the following
> direction? I'm thinking a lot about the possibility of introducing a
> certain deserved reward of the open-source community efforts to an OSS
> license itself while keeping the open-source spirit unchanged. 

As Johannes Zarl-Zierl already said: the general advice when drafting a new 
Open Source license is "don't". More specifically, "don't". After that, 
there's a fairly straightforward process if you *actually* are interested in 
Open Source. I don't doubt your intentions, but I mention it because there are 
a fair number of licenses that enter this process not for the Open Source 
aspect, but for business-model reasons want an Open Source label.

Anyway: the steward of the Open Source definition, which is what just about 
everyone follows, is the Open Source Initiative. See
	https://opensource.org/licenses
and in particular, on that page the link for the review process,
	https://opensource.org/approval

In the past, organizations and individuals would write licenses themselves; 
nowadays you are recommended to lawyer up *first* so that you don't make basic 
mistakes in license drafting that would get the license rejected out-of-hand. 
There's a few hundred "top names in Open Source lawyering" around the world, 
there should be one near you (not that physical proximity matters much, 
really).

> Something
> like a permissive license except the case of intellectual property selling
> decisions by some of the contributors of the project and its forks.
> Business operations should be kept fully royalty free though. I drafted
> some license text
> <https://github.com/SafeOSS/oss-licenses/blob/main/LICENSE-BOSS.txt>.

Before even looking at this: "Open Source" does not allow field-of-use 
restrictions; remember also the Four Freedoms, where freedom zero is the 
freedom to use the software, for any purpose. As soon as you add "this 
software cannot be used for .." you're steering very close to the edge. See 
e.g. MongoDB, Elastic, ... with the SSPL which is **not** Open Source.

So now -- I'm not a lawyer, although I've been hanging out in this space for a 
long time -- I'm going to read the license and give some comments.


> I'm trying to avoid the dual-licensing approach, and to introduce some
> license which includes both elements per se. I'm also trying to avoid some
> issues faced by Qt or MariaDB. Such attempts have been made a few times
> (like Sourcegraph’s Fair Source License, Cockroach’s Community License,
> etc.).

Paragraph line 13:
- I think you'll find enough folks who disagree with the premise ("leave few 
possibilities").
- I do like the quick sketch of the inbound-and-outbound license problem with 
dual-licensing.

Paragraph line 15:
- The comparison with MLM is apt. You *do* know that MLM is a much-reviled 
organizational structure, known more for being exploitative than empowering?
- So the BOSS license is concerned with the "value chain" of forks (presumably 
also re-packaging and simple distribution, since it can be really hard to tell 
a fork from a non-fork -- I wonder if there's a language mix-up here, where 
"fork" on GitHub is something you do as a matter-of-course, while "fork" in 
older Free Software conversation is a project-maintainence action that is 
unusual.)

Paragraph line 17: it would be convenient to indicate where the text of APLv2 
is being used verbatim, just so reviewers can think "we know this bit already"

Paragraph line 47:
- If you are an individual (a natural person) contributing to the work, you 
may not die unless your heirs / executors are able to enter into contract 
negotiations with the stated contributors.
- If you are contributing as an organization, then M&A needs to know that 
negotiations with an unnamed, possibly growing group of stated contributors 
may be necessary at some point in the future.

I think this paragraph opens up a giant can of Bobbitt Worms, which are 
singularly unpleasant. I suppose that submitting work without becoming a 
stated contributor might reduce the administrative burden downstream, although 
in some (many?) jurisdictions you hold copyright even withou the magic 
incantation of being a stated contributor.

Brighter people than me have said "Open Source is not a business model". All-
in-all I think this license won't fly for general Open Source work -- I have 
doubts it would pass the OSI -- but it might vaguely make sense to use for a 
work that is developed by an industry consortium, with funding and contracts 
between the first-generation contributors so that clause 2 does not trigger 
meaningfully for them. Oh, and clause 2 only triggers on copyright transfer, 
so the license also does not solve the thing SSPL tries (and fails) to solve 
which is using unmodified software as a business / service.

I can see a profitable (for lawyers, paper-pushers and hangers-on) side-
venture in BOSS-runaround shell companies (an LLC is cheap) to ensure that 
copyright transfers don't happen.

My non-lawyerly advice? Get someone to look at this much more closely, if 
you're really serious, and then follow the OSI review process.

[ade]




> 
> Does it make sense to work on? I don't have a particular goal. It's my
> hobby, I heavily used OSS for my scientific research while contributing and
> cooperating. I work in commercial IT now and have a feeling that the
> efforts of the OSS community are so great and important that different
> forms of monetization must be thought of fundamentally there.
> 
> Thank you in advance for your advice!
> 
> *Kind regards**,*
> *Bogdan Tanygin <https://www.linkedin.com/in/btanygin/>*

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20210125/b20eabcd/attachment.sig>