I think considering this thread began with conspiracy theories about google's motives for not providing the AGPL license as an option they've been pretty professional about their responses.
>There are 19k projects in SourceForge WWW/HTTP category. Of these, 13k >are GPL, 1.3k are BSD, and 2k are LGPL. *Four are AGPL*
I think they made it clear that when you can show that the numbers of AGPL projects are coming even remotely close to those with other licenses google will be willing to spend time giving you a precise number...
Perhaps everyone should take a breath, and enjoy the weekend... come back refreshed on Monday....
On Fri, Apr 11, 2008 at 6:29 PM, Chris DiBona <cdib...@google.com> wrote: > You need me to disambiguate for you? I think you need to go find my > employment documents and find out where it says I work for you.
> Chris
> ----- Original Message ----- > From: google-code-hosting@googlegroups.com < > google-code-hosting@googlegroups.com> > To: Hosting at Google Code <google-code-hosting@googlegroups.com> > Sent: Fri Apr 11 10:19:28 2008 > Subject: Re: AGPL license
> On Apr 11, 9:06 am, "Chris DiBona" <cdib...@google.com> wrote: > > That sounds like a good idea , regardless of what we do with the info. > > I'll get a review of license use on code.google.com to get some good > > boundary data. If you want a firm number, then when AGPL passes BSD + > > Apache 2.0, I will unconditionally add the license to code.google.com
> > But that's an absurdly high number. Until then, it's gut feeling about > > popularity of the license.
> Thanks Chris, but I need you to disambiguate that a bit.
> Are you saying that when AGPL-in-the-wild passes BSD+Apache *on > code.google.com* you will unconditionally add the license? Or were you > using some other measure?
Let me try this again, and hopefully I'll be less rude this time. :-/
On Apr 11, 9:06 am, "Chris DiBona" <cdib...@google.com> wrote:
> That sounds like a good idea , regardless of what we do with the info.
> I'll get a review of license use on code.google.com to get some good
> boundary data. If you want a firm number, then when AGPL passes BSD +
> Apache 2.0, I will unconditionally add the license to code.google.com
> But that's an absurdly high number. Until then, it's gut feeling about
> popularity of the license.
Thanks Chris, but I'm not sure I understand.
Are you saying that when AGPL-in-the-wild passes BSD+Apache *on
code.google.com* you will unconditionally add the license? Or were you
using some other measure?
My -gut- (which I know is not as non-ambiguous as you'd like) says when the agpl = bsd in the world at large (all projects, everywhere, for both) then it'll be obvious that we should accept it into code.google.com and I'd imagine that by then we'd have already add it.
The lower bound is what you are looking for , and that lower bound is "popularity" as our instinct defines it.
Right now, AGPL is a very uncertain license, some cms' seem to like it , as do other commercially backed saas companies. This makes sense, as it provides enough control to enable significant commercial hybridization. If the larger community of developers adopt it, then we'll be interested in it for code.google.com, but right now , it is not hugely adopted.
On one side, the AGPL isn't viral -enough- to guarantee adoption. For instance, if the linux kernel was to use the AGPL, the performance claus isn't all inclusive enough to encompass all tools on the operating system that might use a (tcp/ip) pipe.
On the other side, the AGPL is too inclusive that might imply that if you have an AGPL licensed CMS, then not only would your plugins fall under its distribution cluas,e but maybe your content would as well. For what is a cms without it's themes, structure, content and underlying datastores?
So , that's why I think that the AGPL needs some annealing before it is popular enough that we'd bring it into code.google.com. The network performance clause is pretty tricky and I don't think it is fair to the AGPL or the community at large to expect the world to adopt it too quickly, and while it is a minority license, we see it as being too divisive and segregating of a license than not.
Meanwhile, in the GPL, the replacability clauses mean that it is more in line with those who were worried with tivo-isation (a term which I think is unfair to tivol, mind you, but whatever) and represents a major step forward into the viral space for licenses, and one through its auto-promotion for those who adopted the 'or any later version' clause, will be very popular, in fact so popular that we've already added it to code.google.com
So there you go :-)
Chris
On Fri, Apr 11, 2008 at 8:46 PM, Michael R. Bernstein
> Let me try this again, and hopefully I'll be less rude this time. :-/
> On Apr 11, 9:06 am, "Chris DiBona" <cdib...@google.com> wrote: > > That sounds like a good idea , regardless of what we do with the info. > > I'll get a review of license use on code.google.com to get some good > > boundary data. If you want a firm number, then when AGPL passes BSD + > > Apache 2.0, I will unconditionally add the license to code.google.com
> > But that's an absurdly high number. Until then, it's gut feeling about > > popularity of the license.
> Thanks Chris, but I'm not sure I understand.
> Are you saying that when AGPL-in-the-wild passes BSD+Apache *on > code.google.com* you will unconditionally add the license? Or were you > using some other measure?
> - Michael
-- Open Source Programs Manager, Google Inc. Google's Open Source and Developer programs can be found at http://code.google.com Personal Site and Weblog: http://dibona.com
> My -gut- (which I know is not as non-ambiguous as you'd like) says
> when the agpl = bsd in the world at large (all projects, everywhere,
> for both) then it'll be obvious that we should accept it into
> code.google.com and I'd imagine that by then we'd have already add it.
> The lower bound is what you are looking for , and that lower bound is
> "popularity" as our instinct defines it.
> Right now, AGPL is a very uncertain license, some cms' seem to like it
> , as do other commercially backed saas companies. This makes sense, as
> it provides enough control to enable significant commercial
> hybridization. If the larger community of developers adopt it, then
> we'll be interested in it for code.google.com, but right now , it is
> not hugely adopted.
Personally, I don't think that the AGPL will ever be as widely
adopted as the BSD as measured across all projects (but I think it
might end up more popular than LGPL). But I do think that within the
smaller sphere of user-facing web applications it will prove to be
*extremely* popular, perhaps as popular as GPL. That's just *my* gut,
though.
> On one side, the AGPL isn't viral -enough- to guarantee adoption. For
> instance, if the linux kernel was to use the AGPL, the performance
> claus isn't all inclusive enough to encompass all tools on the
> operating system that might use a (tcp/ip) pipe.
I don't think that's the intent of the license. Instead, the idea is
that user-facing web-applications that rely on GPL libraries and
infrastructure components can compete on a more equal footing with
proprietary offerings without the risk of proprietary forks (including
proprietary forks of underlying GPL components). The fact that as a
side effect this enables dual-licensing and similar business models is
just a bonus (for some folks).
Does this mean that if a saas vendor wants to fork those underlying
GPL components anyway, all they have to do is write their own front-
end code? Yep. That seems an appropriate balance to me. All I want is
user-facing projects to have the same opportunity for positive network
effects.
> On the other side, the AGPL is too inclusive that might imply that if
> you have an AGPL licensed CMS, then not only would your plugins fall
> under its distribution cluas,e but maybe your content would as well.
> For what is a cms without it's themes, structure, content and
> underlying datastores?
I would expect this to be solved (for projects that are structured to
use that kind of plugin and wish to allow it) with appropriate
exceptions, just as some GPL'd desktop apps do. But the license
infecting content shouldn't be a concern, any more than it is for
proprietary binaries compiled with gcc.
> So , that's why I think that the AGPL needs some annealing before it
> is popular enough that we'd bring it into code.google.com. The network
> performance clause is pretty tricky and I don't think it is fair to
> the AGPL or the community at large to expect the world to adopt it too
> quickly, and while it is a minority license, we see it as being too
> divisive and segregating of a license than not.
Fair enough. I'll follow through sometime in the next few weeks with a
public directory or list of AGPL projects I find, and I'll be
interested to see what you can turn up for statistics on license-use
inside code.google.com whenever you get around to it.
Will it be OK to continue using this group as a forum for this
discussion?
> > My -gut- (which I know is not as non-ambiguous as you'd like) says > > when the agpl = bsd in the world at large (all projects, everywhere, > > for both) then it'll be obvious that we should accept it into > > code.google.com and I'd imagine that by then we'd have already add it.
> > The lower bound is what you are looking for , and that lower bound is > > "popularity" as our instinct defines it.
> > Right now, AGPL is a very uncertain license, some cms' seem to like it > > , as do other commercially backed saas companies. This makes sense, as > > it provides enough control to enable significant commercial > > hybridization. If the larger community of developers adopt it, then > > we'll be interested in it for code.google.com, but right now , it is > > not hugely adopted.
> Personally, I don't think that the AGPL will ever be as widely > adopted as the BSD as measured across all projects (but I think it > might end up more popular than LGPL). But I do think that within the > smaller sphere of user-facing web applications it will prove to be > *extremely* popular, perhaps as popular as GPL. That's just *my* gut, > though.
> > On one side, the AGPL isn't viral -enough- to guarantee adoption. For > > instance, if the linux kernel was to use the AGPL, the performance > > claus isn't all inclusive enough to encompass all tools on the > > operating system that might use a (tcp/ip) pipe.
> I don't think that's the intent of the license. Instead, the idea is > that user-facing web-applications that rely on GPL libraries and > infrastructure components can compete on a more equal footing with > proprietary offerings without the risk of proprietary forks (including > proprietary forks of underlying GPL components). The fact that as a > side effect this enables dual-licensing and similar business models is > just a bonus (for some folks).
> Does this mean that if a saas vendor wants to fork those underlying > GPL components anyway, all they have to do is write their own front- > end code? Yep. That seems an appropriate balance to me. All I want is > user-facing projects to have the same opportunity for positive network > effects.
> > On the other side, the AGPL is too inclusive that might imply that if > > you have an AGPL licensed CMS, then not only would your plugins fall > > under its distribution cluas,e but maybe your content would as well. > > For what is a cms without it's themes, structure, content and > > underlying datastores?
> I would expect this to be solved (for projects that are structured to > use that kind of plugin and wish to allow it) with appropriate > exceptions, just as some GPL'd desktop apps do. But the license > infecting content shouldn't be a concern, any more than it is for > proprietary binaries compiled with gcc.
> > So , that's why I think that the AGPL needs some annealing before it > > is popular enough that we'd bring it into code.google.com. The network > > performance clause is pretty tricky and I don't think it is fair to > > the AGPL or the community at large to expect the world to adopt it too > > quickly, and while it is a minority license, we see it as being too > > divisive and segregating of a license than not.
> Fair enough. I'll follow through sometime in the next few weeks with a > public directory or list of AGPL projects I find, and I'll be > interested to see what you can turn up for statistics on license-use > inside code.google.com whenever you get around to it.
> Will it be OK to continue using this group as a forum for this > discussion?
> - Michael
-- Open Source Programs Manager, Google Inc. Google's Open Source and Developer programs can be found at http://code.google.com Personal Site and Weblog: http://dibona.com
Coming back to this thread... I don't think it closed up well enough.
On Apr 11, 8:37 am, "Michael R. Bernstein" <mich...@fandomhome.com>
wrote:
>...
> Meanwhile, on Google Code, I see 72 projects labeled GPL, 35 BSD, and
> 16 LGPL. This doesn't seem right, so I use general search instead, and
> get 351 GPL, 189 BSD, and 92 LGPL. Still seems low. How many hosted
> projects are there, anyway?
Right now, we're over 100,000 projects.
I ran numbers last summer for my OSCON presentation. The license
breakdown was:
Note that we're going to remove MPL as an option for new projects.
Current projects will be able to retain it, however. It just isn't
popular enough (in fact, the whole category of weakly reciprocal
licenses).
> Coming back to this thread... I don't think it closed up well enough.
> On Apr 11, 8:37 am, "Michael R. Bernstein" <mich...@fandomhome.com>
> wrote:
> >...
> > Meanwhile, on Google Code, I see 72 projects labeled GPL, 35 BSD, and
> > 16 LGPL. This doesn't seem right, so I use general search instead, and
> > get 351 GPL, 189 BSD, and 92 LGPL. Still seems low. How many hosted
> > projects are there, anyway?
> Right now, we're over 100,000 projects.
> I ran numbers last summer for my OSCON presentation. The license
> breakdown was:
