<div dir="ltr">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:<div><br><div><div>1. I created this code.</div><div>2. I seek to display it for others to see. Perhaps comment, improve, or at least recognize me for it.</div><div>3. I seek to allow many people to use this code too.</div><div>4. For a particular set of reasons, I don't want some people or entities to use my code.</div><div>5. I want people who can use my code to be unable to circumvent my restriction in #4.</div><div>6. I might have other statements I want to make that are preserved in the project.</div><div><br></div><div>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.</div><div><br></div><div><div>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: "<i>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.)</i>" </div><div></div></div><div><br></div><div>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: "<i>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.</i>"</div><div><br></div><div></div><div>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.) </div><div><br></div><div>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. </div><div><br></div><div>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). </div><div><br></div><div>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.</div><div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><p style="margin:0px;font-family:"Verizon NHG DS",Arial,sans-serif;font-size:1em;text-align:left;line-height:100%;color:black"><span style="font-weight:bold">Gil Yehuda: </span>I help with external technology engagement</p><p style="margin:0px;font-family:"Verizon NHG DS",Arial,sans-serif;font-size:1em;text-align:left;line-height:100%;color:black"><br></p></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2020 at 9:21 AM Russell Nelson <<a href="mailto:nelson@crynwr.com">nelson@crynwr.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/11/20 10:05 PM, andrew.dema wrote:<br>
><br>
> > There is no mutual ground for discussion<br>
><br>
> I'm glad you've come to such a decisive conclusion. If you don't mind, <br>
> we all get to make that decision for ourselves as well as when to stop <br>
> soliciting feedback. If you have nothing to add or feel it is not <br>
> compatible, that's fine you may be right but others may have more or <br>
> other viewpoints to support your claim, or not. Last I checked this <br>
> was a discussion not a trial.<br>
><br>
Rather than say "but people might disagree", it would be more productive <br>
if you actually disagreed. What mutual grounds do you believe exist <br>
between Open Source and Ethical Software? Besides the concept of tagging <br>
some software as usable for a purpose?<br>
<br>
<br>
<br>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>