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

Wed Jun 26 14:41:49 UTC 2024

 Then tell Melissa Campbell to stop setting all my email accounts and phone numbers up for failure. Thank youSteven Pyle 7656603659
   ----- Forwarded Message ----- From: Roland Turner via License-discuss <license-discuss at lists.opensource.org>To: "license-discuss at lists.opensource.org" <license-discuss at lists.opensource.org>Cc: Roland Turner <roland at rolandturner.com>Sent: Wednesday, June 26, 2024 at 10:21:06 AM EDTSubject: Re: [License-discuss] What's wrong with the AGPL?
  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

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

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/20240626/553fad92/attachment-0001.html>