The GNU AGPL and Free Software Businesses

[Michael R. Bernstein]

The list has been rather quite for a while, so I thought I'd kick off a
discussion.

How do you think the new GNU AGPL[1] will affect the landscape of Free
Software Businesses?

My opinion is that the existence of a GPL-compatible & FSF-endorsed
software license that closes the 'web-app loophole' will expand the
territory of the now-familiar dual-licensing business model to hosted
user-facing web-applications, particularly where instances of such
applications participate in a larger ecology that has it's own network
effects (by sharing and federating data, for example).

What say you?

- Michael R. Bernstein
  michaelbernstein.com

[Michael R. Bernstein]

Darn, I forgot the link:

[1] http://gplv3.fsf.org/comment/agplv3-draft-2.html

On Wed, 2007-09-12 at 11:29 -0700, Michael R. Bernstein wrote:

> The list has been rather quite for a while, so I thought I'd kick off a
> discussion.
>
> How do you think the new GNU AGPL[1] will affect the landscape of Free
> Software Businesses?
>
> My opinion is that the existence of a GPL-compatible & FSF-endorsed
> software license that closes the 'web-app loophole' will expand the
> territory of the now-familiar dual-licensing business model to hosted
> user-facing web-applications, particularly where instances of such
> applications participate in a larger ecology that has it's own network
> effects (by sharing and federating data, for example).
>
> What say you?
>
> - Michael R. Bernstein
>   michaelbernstein.com

[La Monte Henry Piggy Yarroll]

Michael R. Bernstein wrote:

> Darn, I forgot the link:
>
> [1] http://gplv3.fsf.org/comment/agplv3-draft-2.html
>
> On Wed, 2007-09-12 at 11:29 -0700, Michael R. Bernstein wrote:
>  
>> The list has been rather quite for a while, so I thought I'd kick off a
>> discussion.
>>
>> How do you think the new GNU AGPL[1] will affect the landscape of Free
>> Software Businesses?
>>
>> My opinion is that the existence of a GPL-compatible & FSF-endorsed
>> software license that closes the 'web-app loophole' will expand the
>> territory of the now-familiar dual-licensing business model to hosted
>> user-facing web-applications, particularly where instances of such
>> applications participate in a larger ecology that has it's own network
>> effects (by sharing and federating data, for example).
>>    

Would you be so kind as to articulate the nature of the 'web-app loophole'?

[Thomas Lord]

Michael R. Bernstein wrote:
> My opinion is that the existence of a GPL-compatible & FSF-endorsed
> software license that closes the 'web-app loophole' will expand the
> territory of the now-familiar dual-licensing business model to hosted
> user-facing web-applications, particularly where instances of such
> applications participate in a larger ecology that has it's own network
> effects (by sharing and federating data, for example).
>
> What say you?
>  


That's a good bet and its a damn same.   It's bad for user's freedom
and the FSF should not have done this.

AGPL takes away the freedom to not share, which is the same
as taking away the freedom to share.

Dual licensing is one proprietary software strategy to exploit that
problem with AGPL.   There are other strategies.   For example,
a blog service might strip down its software a bit, offer an AGPL
version, and then collect improvements without any obligation
to distribute their own improvements.   Companies could also
release AGPL programs for more subtle strategic purposes --
for example, in order to create demand for some other, back-end
proprietary web application without having to pay too much
to develop a front end and without accidentally creating a
competitor with hostile proprietary control over the front end.

-t

[Luis Villa-3]

On 9/12/07, La Monte Henry Piggy Yarroll <piggy@...> wrote:

> Michael R. Bernstein wrote:
> > Darn, I forgot the link:
> >
> > [1] http://gplv3.fsf.org/comment/agplv3-draft-2.html
> >
> > On Wed, 2007-09-12 at 11:29 -0700, Michael R. Bernstein wrote:
> >
> >> The list has been rather quite for a while, so I thought I'd kick off a
> >> discussion.
> >>
> >> How do you think the new GNU AGPL[1] will affect the landscape of Free
> >> Software Businesses?
> >>
> >> My opinion is that the existence of a GPL-compatible & FSF-endorsed
> >> software license that closes the 'web-app loophole' will expand the
> >> territory of the now-familiar dual-licensing business model to hosted
> >> user-facing web-applications, particularly where instances of such
> >> applications participate in a larger ecology that has it's own network
> >> effects (by sharing and federating data, for example).
> >>
>
> Would you be so kind as to articulate the nature of the 'web-app loophole'?

Since the web decouples use and distribution, you can now allow nearly
global use without actually being required to distribute your changes.

I don't think Matt Asay is too far off when he said that 'GPL is the
new BSD': http://news.com.com/8301-10784_3-9763068-7.html

Luis

[Michael R. Bernstein]

On Wed, 2007-09-12 at 12:34 -0700, Thomas Lord wrote:
>
> Dual licensing is one proprietary software strategy to exploit that
> problem with AGPL.   There are other strategies.   For example,
> a blog service might strip down its software a bit, offer an AGPL
> version, and then collect improvements without any obligation
> to distribute their own improvements.

The only way that works is if copyright on the improvements is assigned
back to the company.

If a company acts in a way that parasitizes or abuses the trust of the
community, a fork is always a possible remedy.

> Companies could also release AGPL programs for more subtle strategic purposes --
> for example, in order to create demand for some other, back-end
> proprietary web application without having to pay too much
> to develop a front end and without accidentally creating a
> competitor with hostile proprietary control over the front end.

Certainly. And if that proprietary back-end tech is protected by
patents, then forking the front-end to target an alternate Free Software
back-end may not even be possible. This is really a patent problem. This
strategy isn't limited to web applications of course, but it is still
uncommon to the point that I can't think of a successful example
offhand. In any case, a front-end app that *requires* a proprietary
back-end isn't compatible with the GPL or the AGPL.

A more interesting twist is if the front-end is AGPL, and the back-end
is GPL... The AGPL front-end would require the distribution of the
version of the GPL-licensed back-end actually deployed behind the
front-end, but there can be *other* GPL forks of the back-end in use
that are not subject to that same requirement, and can have their own
dual-licensing arrangements.

Anyway, absent the 'proprietary back-end' wrinkle, releasing Free
Software equivalents to a competitors' proprietary offerings is of
course a reasonable and known strategy.

Do any other strategies occur to you?

- Michael R. Bernstein
  michaelbernstein.com

[João Miguel Neves]

Qua, 2007-09-12 às 12:34 -0700, Thomas Lord escreveu:

> Michael R. Bernstein wrote:
> > My opinion is that the existence of a GPL-compatible & FSF-endorsed
> > software license that closes the 'web-app loophole' will expand the
> > territory of the now-familiar dual-licensing business model to hosted
> > user-facing web-applications, particularly where instances of such
> > applications participate in a larger ecology that has it's own network
> > effects (by sharing and federating data, for example).
> >
> > What say you?
>
> That's a good bet and its a damn same.   It's bad for user's freedom
> and the FSF should not have done this.
>

Wrong, you still have the freedom not to share: don't use that code,

neither these licenses.

Dual-licensing is not a perfect model, but I like it. I call it the
"free software tax model": if you don't want to share, you pay. That
payment is then used to develop software that is available as Free
Software.

Best regards,
                                                João Miguel Neves

[Thomas Lord]

Michael R. Bernstein wrote:
> The only way that works is if copyright on the improvements is assigned
> back to the company.
>
>  

Not quite so.   Briefly:

First, The release of an enterprise-scale but "stripped down"
AGPL release is a spoiler for highly-funded challengers-from-below.

Second, if you're clever, you divide your system up into separate
components so that hackers-upon-the-AGPL-version obtain the
most benefit by hacking on components you don't care about, and
the least benefit on components where your innovation is concentrated.
If you're very clever, where it's useful, you make sure you can later
choose to run the AGPL version of components you don't care about.

Things close to this already happen and AGPL will just make
them more robust.

> Anyway, absent the 'proprietary back-end' wrinkle, releasing Free
> Software equivalents to a competitors' proprietary offerings is of
> course a reasonable and known strategy.
>
> Do any other strategies occur to you?
>  

I'm sure I could construct some but I'm thinking about the problem
(the "web service loophole") from a different angle:

These days, I'm thinking about the social, economic, and
software structure of user-facing, hosted, web applications.
How do these three things interact?

   1. social aspects of software
   2. economic aspects of software
   3. architectural (technical) aspects of software

I'm looking for leverage, frankly:   how can I engineer
software that creates social and economic incentives for
web services that are free software, under end-user control,
usefully shared, studied, used, and improved?


So far, in my explorations, I've been surprise at how social
and economic considerations often lead to simpler and more
robust software architectures, at least freedom is the main
concern.   Designing software that decentralizes power
yet creates opportunities for trade is much harder, in my
experience, than the more common alternatives -- but the
results of the effort are, in retrospect, simpler, more robust,
and in many ways safer.

-t

[Michael R. Bernstein]

On Wed, 2007-09-12 at 14:29 -0700, Thomas Lord wrote:

> Michael R. Bernstein wrote:
> > The only way that works is if copyright on the improvements is assigned
> > back to the company.
> >
> >  
>
> Not quite so.   Briefly:
>
> First, The release of an enterprise-scale but "stripped down"
> AGPL release is a spoiler for highly-funded challengers-from-below.

Well, sure. For purposes of discussion, I think we can safely ignore
scenarios that are exactly equivalent to using the GPL as a competitive
tool for non-hosted software.

> Second, if you're clever, you divide your system up into separate
> components so that hackers-upon-the-AGPL-version obtain the
> most benefit by hacking on components you don't care about, and
> the least benefit on components where your innovation is concentrated.
> If you're very clever, where it's useful, you make sure you can later
> choose to run the AGPL version of components you don't care about.

This assumes a rather Machiavellian degree of cleverness, not to mention
unusual foresight on the part of the Initial Developer. I would assume
that most such attempts will fail miserably, and the useful bits of code
(if any) carted off to other projects.

> Things close to this already happen and AGPL will just make
> them more robust.

I'd be interested in any examples you can provide.

> [snip] I'm thinking about the problem
> (the "web service loophole") from a different angle:
>
> These days, I'm thinking about the social, economic, and
> software structure of user-facing, hosted, web applications.
> How do these three things interact?
>
>    1. social aspects of software
>    2. economic aspects of software
>    3. architectural (technical) aspects of software
>
> I'm looking for leverage, frankly:   how can I engineer
> software that creates social and economic incentives for
> web services that are free software, under end-user control,
> usefully shared, studied, used, and improved?

Well, it is exactly these considerations that are leading me to think
seriously about the GNU AGPL.

Specifically, in the scenario where you want to launch an under- (or
non-) funded open source project for a user-facing web application. You
can host the primary instance of the application at an eponymous domain,
but others can set up their own instances elsewhere.

Obviously, the developer ecosystem can grow without any particular
bottlenecks, and the hosting-the-AGPL-app business ecosystem can grow
with robust competition too, including specialized versions that publish
their code changes that others don't necessarily want to incorporate.

Although all that competition makes it much harder to get and keep the
attractive margins that Freemium Web 2.0 services currently enjoy, for a
sole developer, jump-starting that kind of large ecosystem with the hope
of presiding over it a-la-Linus can be a very attractive financial
proposition.

Also note that as with GPL, AGPL licensed systems do permit completely
private forks (say within a company's intranet).

- Michael R. Bernstein
  michaelbernstein.co

[Thomas Lord]

Michael R. Bernstein wrote:

> On Wed, 2007-09-12 at 14:29 -0700, Thomas Lord wrote:
>  
>> First, The release of an enterprise-scale but "stripped down"
>> AGPL release is a spoiler for highly-funded challengers-from-below.
>>    
>
> Well, sure. For purposes of discussion, I think we can safely ignore
> scenarios that are exactly equivalent to using the GPL as a competitive
> tool for non-hosted software.
>  

They aren't exactly equivalent because while 2nd place chances are somewhat
spoiled by GPL, there is still the chance of having closely held changes.
AGPL is a more effective spoiler since (owing to its restrictions
against software freedom) there can't be any closely held changes in
a public-facing installation.


>> Second, if you're clever, you divide your system up into separate
>> components so that hackers-upon-the-AGPL-version obtain the
>> most benefit by hacking on components you don't care about, and
>> the least benefit on components where your innovation is concentrated.
>> If you're very clever, where it's useful, you make sure you can later
>> choose to run the AGPL version of components you don't care about.
>>    
>
> This assumes a rather Machiavellian degree of cleverness,


No it does not.  It's a natural organizational dynamic in a large firm.
As soon as there is management that is conservative about the
family jewels but IT push to free up as much as can be freed,
the organization will just naturally hill-climb to these clever
divisions-into-components as internal compromises are negotiated.
This pattern is as old as the hills.




>  
>> Things close to this already happen and AGPL will just make
>> them more robust.
>>    
>
> I'd be interested in any examples you can provide.
>
>  

If you squint right there's even things like up2date but really
you should look to "Six Apart" and the state of movable type.



-t

[Stephen J. Turnbull]

João Miguel Neves writes:

 > Wrong, you still have the freedom not to share: don't use that code,
 > neither these licenses.

D'oh.  Tom knows that.  That's not the freedom he's talking about, and
twisting words that way is anti-freedom.  If you want to argue that
point (which is arguable), please say "you still have *enough* freedom
not to share".

But I disagree.  For example, suppose you've gone past alpha test with
your derivative of AGPL code, and now you want to beta test.  *You
must distribute your changes.*  You allowed for that in your business
plan, which turns on first-mover advantages, not on secrecy.  But it
turns out that the AGPL code sucks, and you need something different.
Tough luck, bubba; you've revealed a lot of what you intend to do, and
now your competitors are almost even with you in terms of code,
including the information that the free code isn't up to the task.

The GPL restrictions on freedom (even RMS calls them that when he's in
an honest mood) are a very fine balance, IMO nearly optimal.  What I
mean by that is that as you go beyond the very precise reciprocality
of the GPL (which does create a closed and lossless ecology of free
software), you very rapidly lose effectiveness in achieving the stated
purpose of the new terms (fighting DRM and patents, closing the webapp
loophole) for a given amount of restriction, not to mention the
additional complexity required to define the terms.

[Michael R. Bernstein]

On Thu, 2007-09-13 at 12:51 +0900, Stephen J. Turnbull wrote:
> For example, suppose you've gone past alpha test with
> your derivative of AGPL code, and now you want to beta test.  *You
> must distribute your changes.*

No. Under the AGPL, you must allow users to download the code for the
version they are using.

> You allowed for that in your business
> plan, which turns on first-mover advantages, not on secrecy.  But it
> turns out that the AGPL code sucks, and you need something different.
> Tough luck, bubba; you've revealed a lot of what you intend to do, and
> now your competitors are almost even with you in terms of code,
> including the information that the free code isn't up to the task.

Unless your competitors are part of your beta group *and* downloaded the
code while it was available, I don't think your code is 'in the wild' if
you revert.

- Michael R. Bernstein

[Thomas Lord]

Michael R. Bernstein wrote:

>> You allowed for that in your business
>> plan, which turns on first-mover advantages, not on secrecy.  But it
>> turns out that the AGPL code sucks, and you need something different.
>> Tough luck, bubba; you've revealed a lot of what you intend to do, and
>> now your competitors are almost even with you in terms of code,
>> including the information that the free code isn't up to the task.
>>    
>
> Unless your competitors are part of your beta group *and* downloaded the
> code while it was available, I don't think your code is 'in the wild' if
> you revert.
>
> - Michael R. Bernstein
>  

I think you misunderstand what Stephen means by "beta"  -- it has
to do with the standard model for a web 2.0 start-up:

The launch formula for such start-ups, these days, is that you build
a demo but don't make it public.   Initially you have a small
alpha group of users who are closely trusted, possibly even under NDA.

When you get to the first real $ investment, either self or angel,
you spend that to "go beta" -- you rent some at-scale servers, put up
a front page that says something vague about your new product and
that invites people to sign up as beta testers, and you try to build
buzz.   During this stage, your goal is to accumulate enough beta
users that when the site goes live it already has some user-generated
content and already has a "culture".   So, during a beta stage you
are getting 100s - 10000s (or more of you're Google) of early
adopters, most of whom are strangers.   If your system is AGPL,
it is very much "in the wild" at that point.

-t

[Stephen J. Turnbull]

Michael R. Bernstein writes:

 > On Thu, 2007-09-13 at 12:51 +0900, Stephen J. Turnbull wrote:
 > > For example, suppose you've gone past alpha test with
 > > your derivative of AGPL code, and now you want to beta test.  *You
 > > must distribute your changes.*
 >
 > No. Under the AGPL, you must allow users to download the code for the
 > version they are using.

Those are the "changes" and "distribution" I meant.  That meaning
should be easily recoverable from context.

 > > Tough luck, bubba; you've revealed a lot of what you intend to do, and
 > > now your competitors are almost even with you in terms of code,
 > > including the information that the free code isn't up to the task.
 >
 > Unless your competitors are part of your beta group *and* downloaded the
 > code while it was available, I don't think your code is 'in the wild' if
 > you revert.

You don't succeed in business for very long unless you have a
monopoly, or you anticipate that your competitors are at least that
smart and capable and act to forestall them.  We're already foregoing
the monopoly; does that mean we have to be stupid, too?

[Don Marti]

begin Stephen J. Turnbull quotation of Thu, Sep 13, 2007 at 12:51:07PM +0900:

> The GPL restrictions on freedom (even RMS calls them that when he's in
> an honest mood) are a very fine balance, IMO nearly optimal.  What I
> mean by that is that as you go beyond the very precise reciprocality
> of the GPL (which does create a closed and lossless ecology of free
> software), you very rapidly lose effectiveness in achieving the stated
> purpose of the new terms (fighting DRM and patents, closing the webapp
> loophole) for a given amount of restriction, not to mention the
> additional complexity required to define the terms.

The original Affero GPL has been available since
2002, but who's using it?

Sure, Matt Asay said, "GPL is the new BSD" but even
Alfresco went with the conventional GPL.

Tim O'Reilly said (
http://radar.oreilly.com/archives/2007/07/the_gpl_and_sof_1.html
) "I know about the AGPL, but how widely used is
it? Not very. It would need to be the dominant license
for free software used in web construction for it to
have an effect." -- but couldn't one big application
be "dominant" in its own developer community, the way
Movable Type is?   So where are all the AGPL projects?

--
Don Marti                    
http://zgp.org/~dmarti/
dmarti@...

[davelab6]

On 14/09/2007, Don Marti <dmarti@...> wrote:
>
> So where are all the AGPL projects?

Most hackers are not aware of the AGPL.

Many hackers who are aware of it, do not think proprietisation of
software through networks is a problem.

--
Regards,
Dave

[Stephen J. Turnbull]

Dave Crossland writes:

 > On 14/09/2007, Don Marti <dmarti@...> wrote:
 > >
 > > So where are all the AGPL projects?
 >
 > Most hackers are not aware of the AGPL.

Given the importance of getting licenses right, maybe they're just
waiting for the official release. :-)

[Jamie Lokier]

Stephen J. Turnbull wrote:

> Dave Crossland writes:
>
>  > On 14/09/2007, Don Marti <dmarti@...> wrote:
>  > >
>  > > So where are all the AGPL projects?
>  >
>  > Most hackers are not aware of the AGPL.
>
> Given the importance of getting licenses right, maybe they're just
> waiting for the official release. :-)

I've been aware of the AGPL for some time, but haven't considered
using it for my own projects until I see what others experience is
like.  Ecosystem and all that.

Until I've seen good experiences by others using it, I'll stick with
the GPL.

-- Jamie