projects that were created for in house use would never be released to the =
public.
Below are the top 5 reasons given by these organizations, most of these dec=
isions came from either corporate legal or some MBA way up the chain in mid=
dle management.
#1 Possible Liability. According to several firms I worked with, the legal=
team had determined that even IF the GPL disclaims any and all liability, =
that may not be enough to prevent a lawsuit.
Someone would likely try to file suit at some time, and lawsuits for a fort=
une 500 company can be prohibitively expensive, just having the legal team =
appear in court and say "umm your honor it says use at your own risk", will=
cost tens of thousands of dollars.
In fact I've seen some companies that exist expressly for the purpose of li=
tigating against larger companies in hopes in of a big payday, since a sett=
lement would cost less than the litigation.
Sadly those companies seem to be getting more and more popular as of late.
#2 We can't support it. If you make it, they will come, and they will come=
with questions, and we really don't have time to answer their questions, e=
specially if they aren't paying customers, and especially if they don't RTF=
M. Sadly hundreds of open source projects are killed for this reason alone=
everyday.
#3 We aren't an IT company. This kind of wraps #1 and #2 as well as a bit =
of company image. What they are saying here is that we specialize in "x" a=
nd only "x" and anything not directly related to "x" is outside of our core=
competency and we therefore don't have the resources.
#4 Competitive Advantage. We've invested "x" dollars in this product, beca=
use it will give us some sort of edge over our competition. If we release =
it to the general public our competition could use it to gain a leg up at n=
o cost, or if they couldn't use it then maybe they would at least have some=
visualization of our business processes, which could cost us untold amount=
s of money.
#5 We don't have to. It's actually the cleanest argument. If a company cr=
eates or has created something with GPL'd code strictly for in house use, t=
he GPL says they don't have to make those changes public, period, so why bo=
ther with even thinking about 1-4?
It sucks, but those are the top 5 reasons I've seen for companies not to re=
lease changes to the public. I'm glad that where I'm at now allows me the =
freedom to work on opensource projects and contribute anything relevant bac=
k.
Oh yeah that reminds me of #6
#6 It's not relevant, i.e. the change is too dependent on some change we'v=
e had to make internally to facilitate some business logic function. If we=
just released a patch no one could get it running without some serious tin=
kering.
Sincerely,
Steve
=20
>________________________________________
>From: Andreas Ericsson [[email protected]]
>Sent: Thursday, May 07, 2009 3:22 AM
>To: Nagios Developers List
>Subject: Re: [Nagios-devel] Future of Nagios (was Nagios is dead! Long liv=
e Icinga!)
>sean finney wrote:
>> On Thu, May 07, 2009 at 12:42:28AM +0200, Andreas Ericsson wrote:
>>>> doable. I know this can be successfully accomplished as I was hired as
>>>> a consultant for a large university client in Upstate New York, where
>>> Seeing such an eventbroker module would be nice, as it would solve a lot
>>> of requests. Since all such modules are derivatives works of GPL'd code,
>>> they should be GPL'd too. Is the code available somewhere?
>>
>> just to nitpick a little: the GPL doesn't say it has to be shared with
>> anyone other than the client who recieved it. that said i'm sure it'd
>> be nice to have
>>
>
>I know, but there aren't normally any reasons for holding GPL'd code
>back, unless putting it up for download (a 2minute job for most orgs)
>is considered unacceptable overhead.
>
>--
>Andreas Ericsson [email protected]
NOTICE: This email message is for the sole use of the intended recipient(s=
) and may contain confidential and priv
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]