<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 26/6/24 20:42, Dirk Riehle wrote:</div>
    <div class="moz-cite-prefix"><br>
    </div>
    <blockquote type="cite"
      cite="mid:b73560aa-e76a-4ff0-a251-3e803673c338@riehle.org">
      <pre class="moz-quote-pre" wrap="">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>
      </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>
    </p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:b73560aa-e76a-4ff0-a251-3e803673c338@riehle.org">
      <pre class="moz-quote-pre" wrap="">> 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>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:b73560aa-e76a-4ff0-a251-3e803673c338@riehle.org">
      <pre class="moz-quote-pre" wrap="">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>
    </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>
    </p>
    <p><br>
    </p>
    <p>- Roland</p>
    <p><br>
    </p>
  </body>
</html>