[olug] U.K. Urged to hold back on open source

Sam Tetherow tetherow at nicusa.com
Fri Jun 20 16:48:55 UTC 2003


William E. Kempf wrote:

>Sam Tetherow said:
>  
>
>>I think it would depend on the what the corporation does, if its not a
>>software firm I don't see what the issue would be and if it is a
>>software firm you would just need to evaluate the impact of using GPL
>>software there, for instance, when would it not be a good thing to use
>>gcc or perl in a business?
>>    
>>
>
>Too many factors here:
>
>* Is the software distributed to other companies or clients. (Even
>non-software companies do this).
>
And if it is?  It depends on what is being 'sold'.  A customer software 
solution where a client is buying the 'code' (not the product) it is the 
customer's call.

>
>* Does the source code have any intrinsic value the company doesn't want
>to relinquish rights to.
>
You don't have to relinquish the rights if you are not 
selling/redistribution the code.  For instance the GPL would have no 
impact on an internal CRM package.

>
>* Does the source code contain information the company wants to remain
>proprietary (not exactly the same thing as point 2).
>

Again only a factor if the code is being redistributed.

>
>And other's I'm not thinking of right now.  It may in fact be a non-issue
>that certain things be "infected" by the GPL inside of corporations.  But
>you're on a very slippery slope if some things can be GPLed and other's
>can't, and had better be spending the time and money to evaluate all legal
>risks in such a case.
>
Of course you need to evaluate the impact of your licensing on each 
project just like you evaluate all other aspects of the project.  I 
don't think it is a slipper slope if you understand the effects of the 
GPL and other licenses.  Excluding GPL'd software on all projects 
because the license might effect certain projects would be throwing the 
baby out with the bath water.

>
>And using GPLed software is a non-issue.  Even gcc (perl isn't GPLed,
>though there must be a perl interpreter that is) can be used to produce
>non-GPLed software.  It's the act of incorporating/linking GPLed code,
>even dynamically, that forces your work to be GPLed.
>
Perl isn't GPLed?  Why do they distribute the GPL license with the code 
then (cpan.org, core documentation 'Copying' file)
The only restriction this imposes on my code is when it comes to 
redistribution.  If the code never leaves my ownership it has zero effect.

>>As for government, I would strongly encourage government funded
>>programming to be done using GPL software as well as suggesting that the
>> code be released under the GPL where appropriate, it is my tax dollars
>>hard at work so I think I should get the maximum benifit out of it (ie
>>the source code).
>>    
>>
>
>Oh?  You want the source code that controls our defense systems to be GPLed?
>

No, and I don't want them redistributing that code so it shouldn't be a 
problem (see above).  Although many of the libraries that they created 
to support the code that controls our defense systems could be 
incredibly useful and since I paid for them it would be nice that I can 
get some additional use out of them.  In fact much of what the DOD does 
it GPLed due to their heavy use of GNU software.  That doesn't mean it 
is freely available though.




More information about the OLUG mailing list