[License-discuss] What's wrong with the AGPL?

[Roland Turner]

On 26/6/24 20:42, Dirk Riehle wrote:

> 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.

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.

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:

  * Werner Vogels (Amazon CTO) describes it as "undifferentiated heavy
    lifting".
  * I think it's close to what you're describing as components.
  * I'd describe it as engineering investment in artefacts and
    capabilities that aren't determinative for purchase decisions by the
    organisation's customers.

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:

  * 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.
  * 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.

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.


> > 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).

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.


> 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.

I'm not seeing evidence for this, but perhaps I have missed it. Which 
hyperscaler(s) is/are *demonstrably* breaching AGPL? (i.e. no casting of 
aspersions, an actual violation)


- Roland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20240626/01763f8d/attachment.html>