git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Jakub Narebski <jnareb@gmail.com>,
	Benoit SIGOURE <tsuna@lrde.epita.fr>,
	git@vger.kernel.org
Subject: Re: Git User's Survey 2007 unfinished summary (long)
Date: Fri, 05 Oct 2007 09:57:30 +0200	[thread overview]
Message-ID: <4705EE6A.6020006@op5.se> (raw)
In-Reply-To: <20071005014229.GS2137@spearce.org>

Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> On 10/4/07, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
>>> On Oct 4, 2007, at 11:12 AM, Jakub Narebski wrote:
>>>> Note that Git is GPLv2, and it will probably stay that forever, so you
>>>> are _free_ to start a commercial support scheme for Git, but others
>>>> are free not to choose it. This question is to get to know if there is
>>>> sufficient demand for commercial Git support for it to be viable.
>>> Once again (AFAIR this was already raised during one of the previous
>>> summary) what's the link between GPLv2 and commercial support?  You
>>> seem to imply that because Git won't move to GPLv3, it's a good thing
>>> for potential paid support, or something.  I don't quite see how
>>> GPLvX comes into play with commercial support.  I'm not a license
>>> expert though.
>> The only link between GPL and commercial support is that GPL does not
>> prohibit commercial support (like noncommercial-free licenses for example),
>> and that having commercial support doesn't mean that license would change
>> to proprietary (it cannot).
> 
> Right.  There has been some discussion in the past about forming
> "The Git Company".
> 
> When this survey question was first posed there was some concern that
> Git might move to a commerical license of some sort and perhaps not
> be GPLvX anymore.  That concern is a non-issue; the copyrights for
> Git are held by over 300 people, many of whom are kernel hackers and
> strong believers in the value of GPLv2.  I'm not a kernel hacker,
> but I also believe strongly in the value of the GPLv2 license.
> You won't see me agreeing to move code I wrote to a non-GPL license
> anytime soon.  Most (if not all!) of Git's authors feel the same way.
> 
> There's several reasons why forming "The Git Company" might help
> the overall Git cause, and this question was a feeler to see if
> the community was interested in acquiring support through it.  Many
> other open source projects seem to get some benefit from having a
> company loosely affiliated with them, not the least of which are
> things like:
> 
>   - some of the developers can focus more time on the project and
>     still keep food on the table;
> 
>   - there are people focused on advertising/marketing the project
>     and its benfits to potential end-users;
> 
>   - companies that feel warm-and-fuzzy by having a phone number they
>     can call for help are more likely to want to use the project
>     for critical services;
> 
>   - companies that want training or short-term consulting services
>     know who they can contact for expertise.
> 
> and the list goes on.  The problem with said company is it costs
> money to keep the lights on and employees fed; money which obviously
> cannot be extorted from users through arcane licensing agreements.

Actually it can. I work for precisely such a company (although using
Nagios, cacti and syslog-ng as the base of our products rather than
git). The GPL doesn't state how one is allowed to charge money for
the products, but since larger networks with more users generate more
support calls, we also use a license payment model, where larger
customers pay more and smaller pay less.

The difference between proprietary software is that we have to trust
ur customers to *want* to pay the licenses, as it would be ridiculously
easy for them to replace our versions of the programs with the pristine
oss kind, or even with our patches, as we aren't allowed to keep them
private. However, doing so voids the support-agreement, as we don't take
support for code we haven't audited and tested. In other words, we *must*
provide first-class support and coding aid to our customers, or they
won't want to pay anymore. In practice, it all works out rather well, and
everyone gets something they want.

* I get paid to work with something I like.
* Customers get support, well-tested upgrades and nifty extensions.
* Project maintainers get patches, money, hardware and appreciation.

That last bit is important though. It's not terribly expensive for us to
buy a couple of books or a laptop and send it as a christmas gift to some
project maintainer, but doing so shows appreciation and also buys us the
attention of the developers for when we want our feature-patches accepted ;-)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2007-10-05  7:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-04  9:12 Git User's Survey 2007 unfinished summary (long) Jakub Narebski
2007-10-04 12:04 ` Benoit SIGOURE
2007-10-04 14:59   ` Jakub Narebski
2007-10-05  1:42     ` Shawn O. Pearce
2007-10-05  7:57       ` Andreas Ericsson [this message]
2007-10-04 16:16 ` Johannes Schindelin
2007-10-05  1:27   ` Shawn O. Pearce
2007-10-05  1:48     ` David Tweed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4705EE6A.6020006@op5.se \
    --to=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=spearce@spearce.org \
    --cc=tsuna@lrde.epita.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).