[License-discuss] Thoughts on the subject of ethical licenses

Gil Yehuda gyehuda at verizonmedia.com
Thu Mar 12 15:12:53 UTC 2020


If you strip away dog whistling and provocative terms that often bring out
less productive discussions, there is something similar here to other
"source-available but restricted" ideas. The generic shape of the argument
in simplified form:

1. I created this code.
2. I seek to display it for others to see. Perhaps comment, improve, or at
least recognize me for it.
3. I seek to allow many people to use this code too.
4. For a particular set of reasons, I don't want some people or entities to
use my code.
5. I want people who can use my code to be unable to circumvent my
restriction in #4.
6. I might have other statements I want to make that are preserved in the
project.

A lot of the conversation focused on the first part of #4 (or the details
of #6). Those reasons could be a cloud vendor's use of my code impacts my
revenue projections. It could be I simply don't want to enable a
competitor, or enable a commercial entity to make money from something I
gave away. Maybe I want to discriminate against a group of people because I
don't like them. Let's agree that some reasons will be hard to justify,
some easy. But all test the provisions of the OSD. The details of #4 get
emotionally charged (understandably), but then we miss the rest of the
story.

For many open source authors, their publication is like a gift to the
world, offered with liberal permission to use, and a clear disclaimer for
warranty (and perhaps a share-alike provision). Their message: "*Do what
you want, don't blame me if it this fails to work, don't make me feel
guilty if you do something bad with it. (And maybe ensure this code stays
this way, etc.)*"

But for some authors, that fully-open position invites consequences they
don't want. So they need to maintain a tether between the author and code
user. The message: "*Do what *I* want you to do with this code. If you do
something upsetting to me, I realize I enabled that to happen. I will try
to make sure it does not happen again.*"

If you are a VC-backed startup that sells services or features in support
of an open source product, you care about how the open source code is used.
It impacts your revenue plans. In a somewhat similar way the ethical source
movement encourages the creator of code to remain attached and concerned
about users of their code -- to carry a sort of guilt that they became an
unwilling accomplice to wrongdoing, or even a profiteer of human rights
abuse. (I'm sorry about how emotionally charging that sounds, but that's
what I'm seeing.)

A few weeks ago I asked this list about their thoughts on the tethering of
the author to the project because I think this is at the crux of the issue.
The Open Source movement encourages a detachment between the "my" and the
"code."  I don't think that posture works for the Ethical Source Movement.
It certainly does not work for the "open source business" model either.

When it comes to businesses, I understand that licensing is going to be the
go-to tool. It carries legal significance and is part of the conversation
when the customer pays for the other services. But I'm unconvinced that
licensing will carry the day for the ethical source movement. The
conversation about carrying responsibility feels a lot more like the
messaging used in some religions about guilt/debt (see: chapter 3 of "Debt:
The First 5000 Years" by David Graeber and his analysis of primordial debt
in Christianity, Hinduism, and other religious/moral systems). If I feel
guilt for the actions of others (that I may have enabled) or feel indebted
to repay for a gift that is too great to fully pay for, then a more
historically common solution is a ritual, coinage, credo statement,
or talisman. e.g. congregating with like minded people and reviewing shared
texts, a donation to a cause, an additional clause to a README, a sticker
on the laptop, a badge on the repo, etc. More interesting ideas in that
book, BTW. And while I'm recommending books, "Hacking Diversity" by
Chistina Dunbar-Hester has an interesting analysis challenging the tacit
assumption that "open culture" people seem to have that they can solve hard
social issues using the same methods they used to solve hard technical and
licensing issues. More in that book about other social issues that we
struggle with, related to diversity and representation in open source (not
a licensing issue, more of a code of conduct thing).

Neither use case fits into the current OSD formula.The business-revenue use
case seems to be best addressed by what people refer to as 'source
available with restrictions' licenses, a.k.a 'not fully open', 'faux-pen',
or 'open for some' and the acknowledgement that whatever you call it, it's
not "open source" but something close.

Gil Yehuda: I help with external technology engagement



On Thu, Mar 12, 2020 at 9:21 AM Russell Nelson <nelson at crynwr.com> wrote:

> On 3/11/20 10:05 PM, andrew.dema wrote:
> >
> > > There is no mutual ground for discussion
> >
> > I'm glad you've come to such a decisive conclusion. If you don't mind,
> > we all get to make that decision for ourselves as well as when to stop
> > soliciting feedback. If you have nothing to add or feel it is not
> > compatible, that's fine you may be right but others may have more or
> > other viewpoints to support your claim, or not. Last I checked this
> > was a discussion not a trial.
> >
> Rather than say "but people might disagree", it would be more productive
> if you actually disagreed. What mutual grounds do you believe exist
> between Open Source and Ethical Software? Besides the concept of tagging
> some software as usable for a purpose?
>
>
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20200312/99c201ff/attachment.html>


More information about the License-discuss mailing list