Discussion:
Selling the GPL inside your company
David Gerard
2010-08-09 21:53:48 UTC
Permalink
... or free software issues in particular. The question was triggered
by someone whose management is scared silly of the GPL, for whatever
spurious reasons. My answers assume that legal and technical facts
won't work without answering the subjective business-sense issues
attached.

What sort of things have you had to do to get reluctant management to
let you contribute patches back to free software?


- d.



---------- Forwarded message ----------
From: David Gerard <dgerard at gmail.com>
Date: 9 August 2010 22:50
Subject: Re: [ORG-discuss] GPL Advice
To: Open Rights Group open discussion list
<org-discuss at lists.openrightsgroup.org>
Whilst the spirit of GPL/copy[right|left|fight] issues is clear (ish),
the intricacies are not, and I would very much appreciate some help with
my basic understanding.
I replied from my experience, and (despite being somewhat off topic
for ORG) it may be of benefit to others here in a similar boat .

In my experience, you need to point out the business advantage: we got
a bunch of our build process working *far* better by contributing a
fix we needed to the build software, and one of our staff, who is
actually a medical doctor, has found himself a significant contributor
to a GPL project!

That is: focus on the carrot, to the point they consider it attractive
enough to see problems as things to work around. And GPL compliance is
ridiculously easy *once you have* management buyin.

The "competitive advantage" is "free vendor assistance, they like us
so will tend to help us." They might respond to that.

It can also be good marketing and public relations. Get the marketers
interested, that'll swing it ;-)

[I might forward this to FSFE for ideas too.]


- d.
Sam Liddicott
2010-08-10 07:34:08 UTC
Permalink
.... or free software issues in particular. The question was triggered
by someone whose management is scared silly of the GPL, for whatever
spurious reasons. My answers assume that legal and technical facts
won't work without answering the subjective business-sense issues
attached.
What sort of things have you had to do to get reluctant management to
let you contribute patches back to free software?
Whatever answers the underlying concerns and helps them say "yes":

Some I've used/will use:

Concern: we'll have to give the source away anyway
Answer: we'll have to give away our changes anyway - our competitors
can get them just through buying one of our products second hand, and
we'll have to give it to them - we may as well work closer with the
project developers and scratch each-others backs - if they accept our
changes then it will likely reduce the maintenance burden for us. And if
we don't contribute our changes, our competitor might contribute our
changes - or worse, incompatible changes that make life harder for us
and easier for everyone else. If the code does what our customers want
through our competitors changes, why would they buy from us? Better to
buy from the authors of the feature who are developing and supporting it.

Concern: loss of business value
Answer: We get the benefit of thousands of man-hours of expertise
and testing for free. A few patches back is a bargain and more than paid
for with the community good will in return. Business value is not in
secrecy but ability to execute rapidly. Co-operation and goodwill
brought through co-operation will reduce time to market, can we work out
how much that is worth to the business?
(You may want to estimate the size and variety of the testing base, and
how much it would cost the company to organize it. Be careful to get a
realistic estimate, and not all testers may use your features - which
doesn't make it worthless if they are testing that your changes didn't
break other features).


However, some open source projects are enormously hard to contribute to.
One major project has been such a drain on the time of my previous
employer that it was not worth the time it took to get patches accepted
(these were just enabling patches to allow the main feature to
function); so be careful what promises you give to your employer.

Perhaps open source projects should have a published policy accepting
3rd party contributions. I know that Mysql and Samba do. Both require
that the copyright of the patches be given up by the employer which is
another hurdle - so good luck getting that one past your employer!
(http://samba.org/samba/devel/copyright-policy.html,
http://forge.mysql.com/wiki/Sun_Contributor_Agreement)


Sam
- d.
---------- Forwarded message ----------
From: David Gerard<dgerard at gmail.com>
Date: 9 August 2010 22:50
Subject: Re: [ORG-discuss] GPL Advice
To: Open Rights Group open discussion list
<org-discuss at lists.openrightsgroup.org>
Whilst the spirit of GPL/copy[right|left|fight] issues is clear (ish),
the intricacies are not, and I would very much appreciate some help with
my basic understanding.
I replied from my experience, and (despite being somewhat off topic
for ORG) it may be of benefit to others here in a similar boat .
In my experience, you need to point out the business advantage: we got
a bunch of our build process working *far* better by contributing a
fix we needed to the build software, and one of our staff, who is
actually a medical doctor, has found himself a significant contributor
to a GPL project!
That is: focus on the carrot, to the point they consider it attractive
enough to see problems as things to work around. And GPL compliance is
ridiculously easy *once you have* management buyin.
The "competitive advantage" is "free vendor assistance, they like us
so will tend to help us." They might respond to that.
It can also be good marketing and public relations. Get the marketers
interested, that'll swing it ;-)
[I might forward this to FSFE for ideas too.]
- d.
_______________________________________________
Discussion mailing list
Discussion at fsfeurope.org
https://mail.fsfeurope.org/mailman/listinfo/discussion
--
[FSF Associate Member #2325]
<http://www.fsf.org/register_form?referrer=2325>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.fsfeurope.org/pipermail/discussion/attachments/20100810/308811eb/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrtOa+MS+fAAAAAielRYdFNvZnR3YXJlAAB42isvL9fLzMsuTk4sSNXLL0oHADbYBlgQU8pcAAAAAElFTkSuQmCC
Type: image/png
Size: 2820 bytes
Desc: not available
Url : Loading Image...
Loading...