[OT] Hybrid open-source licenses?
Adriaan de Groot
groot at kde.org
Mon Jan 25 10:05:48 GMT 2021
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
and in particular, on that page the link for the review process,
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,
> 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
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,
Paragraph line 13:
- I think you'll find enough folks who disagree with the premise ("leave few
- I do like the quick sketch of the inbound-and-outbound license problem with
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
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.
> 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...
Size: 659 bytes
Desc: This is a digitally signed message part.
More information about the kde-community