Slashdot Mirror

eldavojohn writes "Further reinforcing the theory of a wet Mars, NewScientist is reporting on what appear to be water puddles in newly taken images from the Mars rover. While these results are controversial, the assumption that these blue 'puddles' are water still has to be tested by engineers. They'll try to measure the uniform smoothness of the puddle surfaces. Analysis will also examine their apparent 'opaqueness', where in some areas observers claim to see pebbles underneath the surface of the blue areas. From the article: 'No signs of liquid water have been observed directly from cameras on the surface before. Reports last year pointed to the existence of gullies on crater walls where water appears to have flowed in the last few years, as shown in images taken from orbit, but those are short-lived flows, which are thought to have frozen over almost immediately.'"

Ed has written us a little diddy on the various Open Source Licenses with some commentary on each of them. This is important stuff to read, especially for those of us in the audience who aren't crystal clear on the differences between them. This writeup specificly talks about how a business will most likely consider each license for their usage. The following is an Editorial by Slashdot reader Ed

I was recently contacted (along, I'm sure, with many other readers of slashdot.org) by James Glave of Wired Online, who asked me the following:

"Why do you think it's a bad idea to sell free-source libraries to corporations? Doesn't the BSD license give companies total free reign with open source already -- and doesn't this scheme allow companies to at least funnel cash back into the open source community?"

My quick answers were "I don't" and "Yes -- and I don't understand the question."

The questions, I assumed, had come up in the context of the recent formation of the Public Software Institue (PSI for the rest of this screed), a non-profit organization that will attempt to fund open-source software development through the use of a "pay or publish" licence, which would allow companies to sell closed-source software derived from the open-source base, for a fee. It's a neat compromise between the GPL and traditional commercial software licensing(1).

However, I don't think it will encourage as much development as the more familiar open-source licenses.

Indulge in a bit of armchair theory with me:

Let's look at open-source package foo-psi, released under an PSI type of license, open-source package bar-gpl, released under a GPL-style license, and open-source package baz-bsd, released under a BSD or XFree86 type of license. Suppose that all of these packages do essentially the same thing, and that they each have a few core developers who are dedicated to improving the code and releasing source.

Suppose traditional software company A Inc is looking for code to use in a closed, commercial product. Package bar-gpl is not an option, and therefore will not benefit from the efforts of A Inc's remarkably talented development team. A Inc will either choose to use package baz-bsd (for free) or foo-psi (paying the license fee). Again, no source code will be contributed back to packages foo-psi or baz-bsd. If package foo-psi is used, money will go to the licensers of foo-psi, who may do with it as they please. However, company A is more likely to choose package baz-bsd, because there is no fee for doing so.

Now consider university graduate student or computer enthusiast B, who in working on an academic project or hobby wants to modify an existing software package. Any of our three available software packages would be fine, but the industrious programmer might resent the idea of his or her brilliant work being used to benefit the bank accounts of the licensers of foo-psi or to fill the coffers of companies such as A Inc which use package baz-bsd. There would be incentive, albeit somewhat negative, for B to use package bar-gpl. If, on the other hand, B thinks that he or she might in the future want to form his or her own company like A Inc in order to profit from the present project, then there will be incentive to choose package baz-BSD.

Now suppose that the ingenious programmers at company C are looking for some code to use as part of an internal project, which they do not intend to sell. This, incidentally, describes most of the programming done in the world today. If there is a benefit to company C in keeping modifications away from their competitors, then there will be no source code contributed to any of the open-source packages. If there is a greater advantage to be had by making sure that future versions of the open-source package are compatible with company C's project, then code will be released, and whichever open-source project is chosen for the work will benefit from the efforts of the tireless and noble programmers employed by company C. If company C is planning to keep their modifications private, then they may choose code from project bar-gnu (remember that they do not plan to distribute modified code), or from baz-BSD, but they are less likely to use code from project foo-psi if they are required to pay a licensing fee. Thus the license holders of project foo-psi are less likely to earn money from projects of this sort(2).

Eventually, it's likely that one of these packages will attract a few more contributors than the others, and thus more improvements will be made to that package to the others, thereby attracting more developers, resulting in a classic positive feedback cycle. (Well, okay, everyone I know who spends time programming seems to think so. I don't have any great explanation of why this should be the case). Based on the licensing alone, I don't think there is enough evidence to choose a "winner" of this sort, but I think I can see a loser. With all things being equal, there are more motivations for projects to contribute to bar-gpl or baz-bsd than there are for foo-psi. Contributions to foo-psi in the form of money are unlikely when baz-bsd is available, and there is the added difficulty of transmogrifying money received by the license holders of foo-spi into more working code in the foo-psi codebase :) .

This sort of armchair theorizing could get ridiculously extensive (e.g.: Which type of license is likely to generate more bug reports? More importantly, how does the existing body of open-source code influence selection?), but I think I'll take a rest at this point. For the record, I'm a little bit wary of using this sort of argument, because I've encountered so many "evolutionary explanations" for behavior that are in fact rationalizations based only on selected facts. I tend, therefore, not to trust myself with this sort of argument, and I welcome criticism. I apologize in particular if this might be construed as an attack against PSI, who I think are doing Good Things, or as a call for developers to avoid license terms such as those proposed by PSI. That would just be silly.

--Ed Slocomb

(1) Software distributed under such a license might not be able to use the trademark "open-source." (See opensource.org for details) "open-source" is a trademark of Software in the Public Interest.

(2) There is also the possibility that company C might want to turn an internal project into a closed-source product at some time in the future. If the license for foo-spi allowed modification for non-redistributed work without fee, the aforementioned possiblity would favor the use of baz-bsd rather than foo-psi.

Ed has written us a little diddy on the various Open Source Licenses with some commentary on each of them. This is important stuff to read, especially for those of us in the audience who aren't crystal clear on the differences between them. This writeup specificly talks about how a business will most likely consider each license for their usage. The following is an Editorial by Slashdot reader Ed

I was recently contacted (along, I'm sure, with many other readers of slashdot.org) by James Glave of Wired Online, who asked me the following:

"Why do you think it's a bad idea to sell free-source libraries to corporations? Doesn't the BSD license give companies total free reign with open source already -- and doesn't this scheme allow companies to at least funnel cash back into the open source community?"

My quick answers were "I don't" and "Yes -- and I don't understand the question."

The questions, I assumed, had come up in the context of the recent formation of the Public Software Institue (PSI for the rest of this screed), a non-profit organization that will attempt to fund open-source software development through the use of a "pay or publish" licence, which would allow companies to sell closed-source software derived from the open-source base, for a fee. It's a neat compromise between the GPL and traditional commercial software licensing(1).

However, I don't think it will encourage as much development as the more familiar open-source licenses.

Indulge in a bit of armchair theory with me:

Let's look at open-source package foo-psi, released under an PSI type of license, open-source package bar-gpl, released under a GPL-style license, and open-source package baz-bsd, released under a BSD or XFree86 type of license. Suppose that all of these packages do essentially the same thing, and that they each have a few core developers who are dedicated to improving the code and releasing source.

Suppose traditional software company A Inc is looking for code to use in a closed, commercial product. Package bar-gpl is not an option, and therefore will not benefit from the efforts of A Inc's remarkably talented development team. A Inc will either choose to use package baz-bsd (for free) or foo-psi (paying the license fee). Again, no source code will be contributed back to packages foo-psi or baz-bsd. If package foo-psi is used, money will go to the licensers of foo-psi, who may do with it as they please. However, company A is more likely to choose package baz-bsd, because there is no fee for doing so.

Now consider university graduate student or computer enthusiast B, who in working on an academic project or hobby wants to modify an existing software package. Any of our three available software packages would be fine, but the industrious programmer might resent the idea of his or her brilliant work being used to benefit the bank accounts of the licensers of foo-psi or to fill the coffers of companies such as A Inc which use package baz-bsd. There would be incentive, albeit somewhat negative, for B to use package bar-gpl. If, on the other hand, B thinks that he or she might in the future want to form his or her own company like A Inc in order to profit from the present project, then there will be incentive to choose package baz-BSD.

Now suppose that the ingenious programmers at company C are looking for some code to use as part of an internal project, which they do not intend to sell. This, incidentally, describes most of the programming done in the world today. If there is a benefit to company C in keeping modifications away from their competitors, then there will be no source code contributed to any of the open-source packages. If there is a greater advantage to be had by making sure that future versions of the open-source package are compatible with company C's project, then code will be released, and whichever open-source project is chosen for the work will benefit from the efforts of the tireless and noble programmers employed by company C. If company C is planning to keep their modifications private, then they may choose code from project bar-gnu (remember that they do not plan to distribute modified code), or from baz-BSD, but they are less likely to use code from project foo-psi if they are required to pay a licensing fee. Thus the license holders of project foo-psi are less likely to earn money from projects of this sort(2).

Eventually, it's likely that one of these packages will attract a few more contributors than the others, and thus more improvements will be made to that package to the others, thereby attracting more developers, resulting in a classic positive feedback cycle. (Well, okay, everyone I know who spends time programming seems to think so. I don't have any great explanation of why this should be the case). Based on the licensing alone, I don't think there is enough evidence to choose a "winner" of this sort, but I think I can see a loser. With all things being equal, there are more motivations for projects to contribute to bar-gpl or baz-bsd than there are for foo-psi. Contributions to foo-psi in the form of money are unlikely when baz-bsd is available, and there is the added difficulty of transmogrifying money received by the license holders of foo-spi into more working code in the foo-psi codebase :) .

This sort of armchair theorizing could get ridiculously extensive (e.g.: Which type of license is likely to generate more bug reports? More importantly, how does the existing body of open-source code influence selection?), but I think I'll take a rest at this point. For the record, I'm a little bit wary of using this sort of argument, because I've encountered so many "evolutionary explanations" for behavior that are in fact rationalizations based only on selected facts. I tend, therefore, not to trust myself with this sort of argument, and I welcome criticism. I apologize in particular if this might be construed as an attack against PSI, who I think are doing Good Things, or as a call for developers to avoid license terms such as those proposed by PSI. That would just be silly.

--Ed Slocomb

(1) Software distributed under such a license might not be able to use the trademark "open-source." (See opensource.org for details) "open-source" is a trademark of Software in the Public Interest.

(2) There is also the possibility that company C might want to turn an internal project into a closed-source product at some time in the future. If the license for foo-spi allowed modification for non-redistributed work without fee, the aforementioned possiblity would favor the use of baz-bsd rather than foo-psi.

Apparently Caldera has been doing a lot better with Open/DR-DOS than they expected. Check out This InfoWorld Story sent to us by Ed for info on why this is. My guess is it's just people who want to play WarCraft II but don't want to run it under real DOS.