<html><head></head><body><div class="ydpc94c3ae9yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div></div>
<div>Then tell Melissa Campbell to stop setting all my email accounts and phone numbers up for failure. </div><div>Thank you</div><div>Steven Pyle </div><div>7656603659</div><div><br></div>
<div id="ydpc94c3ae9yahoo_quoted_9689571984" class="ydpc94c3ae9yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>----- Forwarded Message -----</div>
<div><b>From:</b> Roland Turner via License-discuss <license-discuss@lists.opensource.org></div><div><b>To:</b> "license-discuss@lists.opensource.org" <license-discuss@lists.opensource.org></div><div><b>Cc:</b> Roland Turner <roland@rolandturner.com></div><div><b>Sent:</b> Wednesday, June 26, 2024 at 10:21:06 AM EDT</div><div><b>Subject:</b> Re: [License-discuss] What's wrong with the AGPL?</div><div><br></div>
<div><div id="ydpc94c3ae9yiv0628918177"><div>
<div class="ydpc94c3ae9yiv0628918177moz-cite-prefix">On 26/6/24 20:42, Dirk Riehle wrote:</div>
<div class="ydpc94c3ae9yiv0628918177moz-cite-prefix"><br clear="none">
</div>
<blockquote type="cite">
<pre class="ydpc94c3ae9yiv0628918177moz-quote-pre">On 20.06.24 02:35, Josh Berkus wrote:
> A lot of this discussion has been around the AGPL "failing" startups
> who wanted to use it to protect themselves from web service competition.
>
> This is not that the AGPL was written for.
>
> The AGPL was written for projects like CiviCRM, which had a direct
> threat of "embrace and extend" by proprietary vendors. The AGPL did,
> and still does, a fine job of preventing nonprofit OSS projects from
> having their code modified, extended, and improved by proprietary
> service vendors without back contribution.
It works for CiviCRM (non-profit) like it works (worked) for SugarCRM
(commercial). If you can AGPL the whole application without additional
permissive client library shims etc, it works as intended. It doesn't
work for the component vendors that came later and which needed more
complicated licensing; the vendors problem is that they can't separate
potential customers from hyperscalers through licensing strategy.</pre>
</blockquote>
<p>It might be worth taking a moment to consider the objectives of
open source licensing with respect to commercially-produced
software (and commerce generally). The objective is not to weaken
protections to whatever extent a class of investors might find
profitable, it's to preserve user and developer freedom, and as a
secondary concern to facilitate whatever commercial opportunities
might exist therein. That is, it's about freedom, not about
investment. In particular, any variant of "separate potential
customers from hyperscalers through licensing strategy" is likely
to be incompatible with free or open source licensing, because the
objectives at that point are diametrically opposed.</p>
<p>There is an important problem here, and I don't yet have a view
as to how it might be solved. It's that one of the areas that's a
particularly strong candidate for F/OSS collaboration is also one
of the areas that's strongest for IaaS and PaaS cloud service
provision, meaning that cooperation is always going to be
difficult:</p>
<ul><li>Werner Vogels (Amazon CTO) describes it as "undifferentiated
heavy lifting".</li><li>I think it's close to what you're describing as components.</li><li>I'd describe it as engineering investment in artefacts and
capabilities that aren't determinative for purchase decisions by
the organisation's customers.</li></ul>
<p>When you move "undifferentiated heavy lifting" from an
organisation selling widgets to a cloud service provider, you
change who the organisation is, and therefore who its customers
are:</p>
<ul><li>Prior to the move, the engineers in the widget maker were free
to cooperate with their peers in other makers of different
widgets because their respective organisations weren't engaged
in zero-sum competition with respect to any of their customers,
or even with direct competitors so long as what they're
co-operating on is not differentiating for their respective
customers.<br clear="none">
</li><li>After the move, the "component" now is the product (or the
service of hosting it is) and the customers are the makers of
various widgets that integrate the component somewhere in their
product or internal processes, so the component is very much
differentiating. At this point, the opportunity for cooperation
disappears.</li></ul>
<p>I'm not sure any sort of IP strategy can resolve this. The
economic forces are overwhelming. I'm not opposed to looking for
approaches of course.<br clear="none">
</p>
<p><br clear="none">
</p>
<blockquote type="cite">
<pre class="ydpc94c3ae9yiv0628918177moz-quote-pre">> The struggle that startups are having is that they don't want code
> contributions, they want money. Copyleft is not a business model.
Commercial open source application providers can use copyleft as a
successful anti-competition strategy, commercial open source component
vendors have not found a good way (yet).
So I also think that the component vendors are barking up the wrong
tree, blaiming their failure to find a solution to on the tools they
were using (the available licenses).</pre>
</blockquote>
<p>Sure. As above, there's a real problem with trying to trying to
turn cooperating developers into paying customers, while still
sustaining cooperation. So far as I can tell, something has to
give.</p>
<div id="ydpc94c3ae9yiv0628918177yqtfd12421" class="ydpc94c3ae9yiv0628918177yqt4991901696"><p><br clear="none">
</p>
</div><blockquote type="cite"><div id="ydpc94c3ae9yiv0628918177yqtfd22044" class="ydpc94c3ae9yiv0628918177yqt4991901696">
<pre class="ydpc94c3ae9yiv0628918177moz-quote-pre">The bad part: The other side, the hyperscalers, seem to be in cahoots
with the vendors, because they also want to see the AGPL considered
ineffective.
So we have two opposing parties, both claiming the AGPL is no good, for
their own reasons, both wrong IMO.</pre></div>
</blockquote>
<p>I'm not seeing evidence for this, but perhaps I have missed it.
Which hyperscaler(s) is/are <b>demonstrably</b> breaching AGPL?
(i.e. no casting of aspersions, an actual violation)<br clear="none">
</p>
<p><br clear="none">
</p>
<p>- Roland</p><div id="ydpc94c3ae9yiv0628918177yqtfd36858" class="ydpc94c3ae9yiv0628918177yqt4991901696">
<p><br clear="none">
</p>
</div></div></div><div class="ydpc94c3ae9yqt4991901696" id="ydpc94c3ae9yqtfd37575">_______________________________________________<br clear="none">The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address.<br clear="none"><br clear="none">License-discuss mailing list<br clear="none"><a shape="rect" href="mailto:License-discuss@lists.opensource.org" rel="nofollow" target="_blank">License-discuss@lists.opensource.org</a><br clear="none"><a shape="rect" href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="nofollow" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br clear="none"></div></div>
</div>
</div></div></body></html>