<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Risk Factors You Ought To See for Proprietary Software</title>
	<atom:link href="http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/</link>
	<description>Openlogic's Community Blog</description>
	<lastBuildDate>Fri, 13 Nov 2009 01:05:10 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Epic Thinking â€“ innovation and quality in e-learning &#187; Blog Archive &#187; Articulate customers learn SaaS risks the hard way</title>
		<link>http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/comment-page-1/#comment-89364</link>
		<dc:creator>Epic Thinking â€“ innovation and quality in e-learning &#187; Blog Archive &#187; Articulate customers learn SaaS risks the hard way</dc:creator>
		<pubDate>Thu, 17 Jan 2008 10:54:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/#comment-89364</guid>
		<description>[...] On a related note, a great post appeared on the OpenLogic website earlier in the week about the risk factors of using proprietary software, which was a tongue-in-cheek response to yet another FUD-spreading proprietary software company, this time McAfee, complaining about the risk factors of adopting open source software. This humorous list verges on the paranoid but contains a few home truths worth remembering if you are preparing for an LMS, authoring tool or some other elearning software procurement. I have copied these lock stock and barrel from the OpenLogic blog post: [...]</description>
		<content:encoded><![CDATA[<p>[...] On a related note, a great post appeared on the OpenLogic website earlier in the week about the risk factors of using proprietary software, which was a tongue-in-cheek response to yet another FUD-spreading proprietary software company, this time McAfee, complaining about the risk factors of adopting open source software. This humorous list verges on the paranoid but contains a few home truths worth remembering if you are preparing for an LMS, authoring tool or some other elearning software procurement. I have copied these lock stock and barrel from the OpenLogic blog post: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gumnos</title>
		<link>http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/comment-page-1/#comment-89244</link>
		<dc:creator>Gumnos</dc:creator>
		<pubDate>Mon, 14 Jan 2008 14:50:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/#comment-89244</guid>
		<description>@Phil:

&quot;This happens all the time - why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that Iâ€™m perfectly happy for them to use it!

The catch is this; by using my utility, which is under the GPL, company A has inadvertently accepted the GPL terms FOR ITS ENTIRE PRODUCT. Only it probably doesnâ€™t know this. So it continues to sell the application, of course. And protect the IP. Which breaks the terms of the GPL and can lead to them getting sued, just like Skypeâ€¦&quot;

So you&#039;re saying that if any non-open-source company offered you the ability to use its code for a limited purpose (say for a particular in-house use, or for inclusion in the software you sell at the cost of a per-sale royalty), it&#039;s alright for you to just ignore the terms of the agreement and distribute their code without consideration for those terms?

If you want to offer your code to companies and you want them to be able to include it without forcing their code to be public, don&#039;t use the GPL.  There are a multitude of other licenses available to do just that.  Do you want them to contribute changes back to your libraries, but don&#039;t need them to contribute the code that uses those libraries?  Use the LGPL.  Do you only care that they give you credit, but they can include your code any way they like without revealing any source code?  Use the BSD license or use the MIT license if you don&#039;t care that they use your name in their promotional material.

People who choose the GPL do so PRECISELY BECAUSE it keeps the code in the open.  If you don&#039;t agree to the terms, write the code yourself or purchase license to code that does what you want on more agreeable terms.</description>
		<content:encoded><![CDATA[<p>@Phil:</p>
<p>&#8220;This happens all the time &#8211; why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that Iâ€™m perfectly happy for them to use it!</p>
<p>The catch is this; by using my utility, which is under the GPL, company A has inadvertently accepted the GPL terms FOR ITS ENTIRE PRODUCT. Only it probably doesnâ€™t know this. So it continues to sell the application, of course. And protect the IP. Which breaks the terms of the GPL and can lead to them getting sued, just like Skypeâ€¦&#8221;</p>
<p>So you&#8217;re saying that if any non-open-source company offered you the ability to use its code for a limited purpose (say for a particular in-house use, or for inclusion in the software you sell at the cost of a per-sale royalty), it&#8217;s alright for you to just ignore the terms of the agreement and distribute their code without consideration for those terms?</p>
<p>If you want to offer your code to companies and you want them to be able to include it without forcing their code to be public, don&#8217;t use the GPL.  There are a multitude of other licenses available to do just that.  Do you want them to contribute changes back to your libraries, but don&#8217;t need them to contribute the code that uses those libraries?  Use the LGPL.  Do you only care that they give you credit, but they can include your code any way they like without revealing any source code?  Use the BSD license or use the MIT license if you don&#8217;t care that they use your name in their promotional material.</p>
<p>People who choose the GPL do so PRECISELY BECAUSE it keeps the code in the open.  If you don&#8217;t agree to the terms, write the code yourself or purchase license to code that does what you want on more agreeable terms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jvb</title>
		<link>http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/comment-page-1/#comment-89243</link>
		<dc:creator>jvb</dc:creator>
		<pubDate>Mon, 14 Jan 2008 13:41:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/#comment-89243</guid>
		<description>&quot;This happens all the time - why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that Iâ€™m perfectly happy for them to use it!&quot;

It&#039;s very possible to do that *without* violating any copyright.
Being the only(obviously you can&#039;t sell something that isn&#039;t yours) copyright holder you can fork(same code, two licenses) and sell it. 

This works the same with all copyrighted material. Just taking something is theft, GPL or proprietary alike .</description>
		<content:encoded><![CDATA[<p>&#8220;This happens all the time &#8211; why would developers at company A rewrite such a utility if my Open Source one already exists! We can even assume that Iâ€™m perfectly happy for them to use it!&#8221;</p>
<p>It&#8217;s very possible to do that *without* violating any copyright.<br />
Being the only(obviously you can&#8217;t sell something that isn&#8217;t yours) copyright holder you can fork(same code, two licenses) and sell it. </p>
<p>This works the same with all copyrighted material. Just taking something is theft, GPL or proprietary alike .</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kim Weins</title>
		<link>http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/comment-page-1/#comment-89229</link>
		<dc:creator>Kim Weins</dc:creator>
		<pubDate>Mon, 14 Jan 2008 03:34:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/#comment-89229</guid>
		<description>Phil,

Thanks for the feedbackand your comments.  I completely understand what you are saying about the copyleft provision of GPL.  If a company wants to use GPL software and create a derivative work and distribute it, they need to comply with that provision.  If that doesn&#039;t work for them, then they need to select a different piece of open source that&#039;s under a different license.  Yes, that may mean they can&#039;t use every piece of open source, but it&#039;s highly likely there is an open source solution that has a license that will fit their needs.

My point about McAfee is that if they don&#039;t pay attention to the open source license provisions, then, yes, there is risk.  However, there is risk if they don&#039;t follow license provisions for proprietary software as well.  Different risks, but still risks.  Some might say that the copyleft provision is a bigger risk, but I think that if you add up all of the risks around proprietary software, they are not insignificant. 

I am not saying &quot;all proprietary software is bad, all open source software is good&quot;.  Our customers all operate in mixed source environments -- proprietary, open source and custom.  Although I used a tongue-in-cheek approach, the underlying point is the that BOTH TYPES of software have to be managed -- with evaluation of licenses, addressing of risks, etc.  

Kim</description>
		<content:encoded><![CDATA[<p>Phil,</p>
<p>Thanks for the feedbackand your comments.  I completely understand what you are saying about the copyleft provision of GPL.  If a company wants to use GPL software and create a derivative work and distribute it, they need to comply with that provision.  If that doesn&#8217;t work for them, then they need to select a different piece of open source that&#8217;s under a different license.  Yes, that may mean they can&#8217;t use every piece of open source, but it&#8217;s highly likely there is an open source solution that has a license that will fit their needs.</p>
<p>My point about McAfee is that if they don&#8217;t pay attention to the open source license provisions, then, yes, there is risk.  However, there is risk if they don&#8217;t follow license provisions for proprietary software as well.  Different risks, but still risks.  Some might say that the copyleft provision is a bigger risk, but I think that if you add up all of the risks around proprietary software, they are not insignificant. </p>
<p>I am not saying &#8220;all proprietary software is bad, all open source software is good&#8221;.  Our customers all operate in mixed source environments &#8212; proprietary, open source and custom.  Although I used a tongue-in-cheek approach, the underlying point is the that BOTH TYPES of software have to be managed &#8212; with evaluation of licenses, addressing of risks, etc.  </p>
<p>Kim</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phil</title>
		<link>http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/comment-page-1/#comment-89220</link>
		<dc:creator>Phil</dc:creator>
		<pubDate>Sun, 13 Jan 2008 23:24:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.openlogic.com/blogs/2008/01/risk-factors-you-ought-to-see-for-proprietary-software/#comment-89220</guid>
		<description>Oh come on, this is such a nonsense post.

I&#039;m afraid that thoughtless blog posts like this one do the whole of the Open Source Community a disservice.  It&#039;s clear that you haven&#039;t read or understood the McAfee article you quote, and by descending into superlatives of &quot;$300 lawyers&quot; and the like you omit the main point.

McAfee is exactly correct; it does indeed face a huge threat from Open Source licenses.  Or rather, specifically, the GPL (GNU Public License).  It is ignorant to claim otherwise.  Just about every propietary software company in the world does.

The reason is that the GPL has an explicit &quot;copyleft&quot; clause, which stipulates that any code originally released under the GPL must always remain Open Source, even if incorporated into other code.

Here&#039;s what that means in plain English.  Imagine I develop a cool utility for, say, parsing an XML data stream.  Doing the honourable thing, I release my utility out into the open under the GPL.  Imagine then that proprietary software company A finds my utility and decides to use it in its next release.  It even gives me credit for that part of the functionality, and let&#039;s say they even visit my home page and make a generous donation too.

This happens all the time - why would developers at company A rewrite such a utility if my Open Source one already exists!  We can even assume that I&#039;m perfectly happy for them to use it!

The catch is this; by using my utility, which is under the GPL, company A has inadvertently accepted the GPL terms FOR ITS ENTIRE PRODUCT.  Only it probably doesn&#039;t know this.  So it continues to sell the application, of course.  And protect the IP.  Which breaks the terms of the GPL and can lead to them getting sued, just like Skype...

The real point is this; you have to be COMPLETELY Open Source.  It&#039;s no good trying to stay proprietary and picking up Open Source code snippets.  One or the other.  You want to use Open Source?  Then go Open Source entirely, or otherwise leave all that excellent code alone and write your own.

Phil</description>
		<content:encoded><![CDATA[<p>Oh come on, this is such a nonsense post.</p>
<p>I&#8217;m afraid that thoughtless blog posts like this one do the whole of the Open Source Community a disservice.  It&#8217;s clear that you haven&#8217;t read or understood the McAfee article you quote, and by descending into superlatives of &#8220;$300 lawyers&#8221; and the like you omit the main point.</p>
<p>McAfee is exactly correct; it does indeed face a huge threat from Open Source licenses.  Or rather, specifically, the GPL (GNU Public License).  It is ignorant to claim otherwise.  Just about every propietary software company in the world does.</p>
<p>The reason is that the GPL has an explicit &#8220;copyleft&#8221; clause, which stipulates that any code originally released under the GPL must always remain Open Source, even if incorporated into other code.</p>
<p>Here&#8217;s what that means in plain English.  Imagine I develop a cool utility for, say, parsing an XML data stream.  Doing the honourable thing, I release my utility out into the open under the GPL.  Imagine then that proprietary software company A finds my utility and decides to use it in its next release.  It even gives me credit for that part of the functionality, and let&#8217;s say they even visit my home page and make a generous donation too.</p>
<p>This happens all the time &#8211; why would developers at company A rewrite such a utility if my Open Source one already exists!  We can even assume that I&#8217;m perfectly happy for them to use it!</p>
<p>The catch is this; by using my utility, which is under the GPL, company A has inadvertently accepted the GPL terms FOR ITS ENTIRE PRODUCT.  Only it probably doesn&#8217;t know this.  So it continues to sell the application, of course.  And protect the IP.  Which breaks the terms of the GPL and can lead to them getting sued, just like Skype&#8230;</p>
<p>The real point is this; you have to be COMPLETELY Open Source.  It&#8217;s no good trying to stay proprietary and picking up Open Source code snippets.  One or the other.  You want to use Open Source?  Then go Open Source entirely, or otherwise leave all that excellent code alone and write your own.</p>
<p>Phil</p>
]]></content:encoded>
	</item>
</channel>
</rss>
