And I said before just having the versions of the libraries you depend on doesn't cut it, as the QA lab is simply *not* going to have the tools or the time to produce just that configuration in the lab. They *will* have all the major released versions of all the major distributions already set up and waiting for use.
I'm a "home user" in the sense that I have linux at home, at work, and everywhere else, and I want the distribution to choose for me 99.9% of the time--on servers, at home, and everywhere.
A long time ago I used to try and choose everything for myself, very carefully. I got bored of that, and now I have better things to do with my time. I want the distro to make 99.9% of the choices for me: i want it to choose the window manager and theme, i want it to choose a wordprocessor, an SMTP server, an NFS server, http server, etc., etc., and i really don't care how or what it chooses so long as it works.
There ARE three or four packages that I do care about enough that I want to choose for myself. In those cases I will hand-install into/usr/local by downloading the source and compiling and configuring it myself. I will be actively involved in the mailing lists, and familiar with all the current issues, because it's my job, or because I'm just very interested. But I only have energy and time to do that for three or four software packages.
For everything else, I want the distro to choose for me, and I want it to make a reasonably good choice. So, I prefer redhat over debian, because redhat makes choices, whereas debian tries to give me options. I don't want options: options represent the work of figuring out which one is best. I want the smart guys who made the distro to decide what IMAP server works best with everything else they've stuck on.
Updating before filing a bug does NOT help, unless they investigate the bug the very same day I submit it. What if they don't get around to looking at my bug for three months? How can they possibly figure out exactly what version I had at the time I submitted the bug?
Sorry, it just doesn't work. Nice as the apt-get system is, it is not a substitute for a proper release cycle. Period.
Yeah, I am not running oracle at home, but the scenario is real: I have a lot of other software, though, that is not installed via a.deb, and when it doesn't work I would like to know how to file the bug. In particular, various JDK's, bitkeeper, mplayer, WebLogic, nvidia drivers, etc., are all things I've manually installed into my systems and sometimes wanted to report bugs against.
In practice what I did when I was running debian was see if I could replicate the bug myself on a different distribution, like RedHat, and then file based on that. Note that it's worth nothing to the developer to list the libs you depend on: they're NOT going to install just that combination just to check out your bug. For a corp. shop the odds are they DO have common systems already set up in the lab, like "fedora core 2" and "suse whatever" but I can guarantee you they won't have the exact version of "debian unstable" you found your bug on.
Eventually I decided that was retarded to have to replicate it on another system--it made any support I got worth absolutely nothing on debian--and just overwrite Debian with RedHat.
There's no question that apt-get is a better package manager than rpm, but that doesn't help much when the distro itself is run by people who can't figure out how to get a release out more than a few times a decade.
stable often just doesn't cut it because it is too old; the only reason to suggest it really is that it is a known platform. solution: use redhat/fedora, where you get something that is as stable as "unstable", but also has a known version.
i've faced bugs in the field that took weeks to diagnose, so saying i didn't analyze it is just kind of side-stepping the issue, crossing you fingers, and hoping it doesn't happen to you. when it does happen to you, you'll appreciate it if the developers at the other company can run the exact same version of the exact same distro you have, so as to eliminate as many possible variables in debugging.
am i helping with debian? no. i am not using debian. i am not going to use debian if i can help it, so why would i help? i help by using distributions that get this right, thereby giving them larger market share.
as for filing bugs: maybe you are some kind of purist who thinks i should only be running software that i installed with apt-get, but last i checked things like WebLogic and Oracle did not come as free software.deb's, and yes i do sometimes need to file bugs against these behemoths.
if i were at one of these corps. and i got a bug that says "doesn't work on debian unstable" i would toss it in the trash. i'm also not really interested in doing a lot of work finding every library they link in and sending that list to them, nor would that really help.
saying "it doesn't work on fedora core 2" means there is a high probability that they have in their QA lab a "fedora core 2" machine which they can try and replicate my bug on.
here is how i am helping debian, by providing some worthwhile advice: debian developers reading this, get a clue--give me a stable release version number system that i can use to report bugs.
given all my whining here you may simply say "debian may not be for you", and that was my exact conclusion as well.
sometimes also my typing sucks more, and paradoxically it never sucks less. sorry about that bizarre first paragraph there, i do hope you know what i meant.
some distros suck more; the paradoxical think is that none of them suck less.
i am probably going to use fedora because it has a stable release schedule. that doesn't mean it sucks any less; but other distros suck more. what it really means that means if someone asks me what i am running i can say "fedora core 2" and that means something. that means if i have issues with some software the guy who got my email reporting whatever bug knows what i've got and can see if my problem can be replicated.
try that on debian. debian has no coherent release schedule, and at this point it's not even clear they are EVER going to have another release: the current "release" has been delayed *years* already, and debian users are quite pleased with that. debian users just incrementally apt-get upgrade "unstable" and claim that is OK.
but try figuring out how to file a bug based on that--what exactly is debian unstable? it's a huge moving target, it really doesn't mean anything, and by the time the guy gets around to looking at my bug it's likely radically different. debian needs to get its shit together and get back to 3-4 month releases. apt-get upgrade is really not the answer. i also like rhat's "best of breed" philosophy versus debians "here have everything" philosophy: i don't want to choose most of the time; and when i DO want to choose i probably know what i'm doing well enough to manually install. so most of the time, i want the distro to choose for me.
so where does that leave me? i've got a rh9 that is end of life and i reall don't want to switch to the debian chaos. i'm hoping to go fedora, but you guys say it sucks. enterprise is no good for my home box, it's not worth paying an "enterprise" license for home.
so, here is a plea: make fedora core not suck more than other distros. i don't need support from redhat for my home system; i do need stable planned releases. and guess what? whatever i use at home is likely going to determine what we pay for at work, so it's not like there isn't a business interest here in making me happy. if i do get forced onto debian at home, it's only a matter of time before i advocate for it at work as well.
Compliance tests are incompatible with the way in which opensource software is developed; it is really NOT the same "just with tests".
Mandatory compliance tests are utterly incompatible with the way opensource developers work. OSS development is not done behind closed doors: Broken versions of the software are routinely distributed to anyone and everyone. First, the software repository is probably on a public CVS server, with patches routinely posted on mailing ists; integration builds and nightly builds are likely posted on websites along with release candidates that are the OSS alternative of an expensive QA department. None of this is compatible with compliance testing as the interim releases are practically guaranteed not to pass the tests and so this is all illegal.
Could opensource developers make an exception for Java and work behind closed doors in this case? No. What would be the point--the benefit of an opensource project is that it brings together people from different continents and companies with different motives and interests and enables them to collaborate on a shared resource. These people generally do not, cannot, and will not work together behind a closed door--what door would that be? Worse, that's just development, the "QA team" for an opensource project tend to be just anyone who is willing to download and try out the interim release.
If these severe legal problems could somehow be solved then perhaps it's viable. Maybe we could contemplate "time limited" release licenses for the interim versions--users can use and access them for a few months before they "expire", whereas a compliant version could be used indefinately.
There are still further problems--to be acceptable, the compliance test ought to be freely available as well, so that anybody can download and run it against their version of the JVM. The content of the compliance test also ought to be under the control of a public standards body so that the community can feed back its development into the standard: what's the use of creating a popular extension of the langauge if it can never be a part of the language?
I fully understand and respect Sun's desire to prevent a fork of Java technology. Were it opensourced tommorow before long there would be incompatible versions of Java from Sun, Microsoft, IBM, and who knows how many countless others. It's an understandable, important objective to prevent the platform itself from forking incompatibly.
However, this is a problem that does need a solution and saying that it is really the same thing "just with compliance tests" is an inadequate response: compliance tests, as they stand, are fundamentally incompatible with opensource software.
I hadn't previously realized that one of Canada's major banks, Royal, was a SCO backer. I urge everyone in Canada who has business with Royal to cancel their cards, accounts, move their mortgages, etc., and when you do it, write a letter to RBC telling them why.
It probably won't make a difference, but you don't have to have YOUR money in SCO, which is where it is if it's in a Royal Bank account.
Re this: "The letter asserts that BayStar is entitled to the redemption of its shares under Article VII.A(vii) of the Certificate of Designation, Preferences and Rights of the Series A-1 Convertible Preferred Stock because SCO has allegedly breached Sections 2(b)(v), 2(b)(viii), 2(b)(viii) and 3(g) of the Exchange Agreement dated February 5 2004 among SCO, BayStar and Royal Bank of Canada, which also holds shares SCO's Series A-1 Convertible Preferred Stock."
There is a proposed ITJOBS futures market on Ideosphere based on these statistics. The claim will trade like a stock symbol between 1 and 100 and payout a value based on the number of IT jobs in the US earning more than $50k/year in 2012. Too bad it's just a game with fake money, otherwise we could all hedge our bets. But at least once it's trading the market ought to give us some insight into where things are going.
Go is an awesome game. My own experience is that playing Go gave me deeper insight into problem solving in general. In Go you and your opponent make the same number of moves, but by the end of the game one of you has surrounded more territory. That makes it a game of economy: Whoever makes the most efficient moves wins. It becomes a game of subtle tradeoffs, swaps, and double-meanings. You learn that if you try and have everything you will wind up with nothing; and how to follow a plan with stubborn determination yet constantly redefine your goals. You learn that sometimes the simplest, quietest moves are absolutely decisive and often difficult to understand.
Chess has proved the value of a brute force approach--even without a lot of AI routines, simply searching the game tree and adding up the value of the men left on the board is a workable algorithm. Good chess programs improve on that significantly with rules to prune the tree search, and further rules to score a board position. That doesn't work so well in Go: There are 361 points on a Go board, with a typical game lasting some 200 moves--an unimaginably large number of game combinations. Worse, there's no easy way to assign a value to a board position once you've brute forced your way through the combinations. The combination of these two factors is one reason why there are no really good Go playing programs, as there are in Chess.
Go is a great game to play on the Internet. You can order all the books you need to get you started, and then you can play on the 'net. There's not bad Go implementations at Yahoo Games, etc., but eventually you will move up to the real go servers like
Kiseido or Panda, both located in Japan.
I bet the machine had some email software on it (Outlook?) that checked for new mail once an internet connection was available. The mail server logs would show the IP address.
OK smarty, did you actually follow your own link? Yes there are a bunch of SRPMS there, but where is the kernel?
I don't see it.
It either has been removed or it was distributed elsewhere. What I am actually asking for is someone who actually has a copy of the kernel which they downloaded from SCO to send me a copy, as contrary to reports here it does NOT appear to be on the website or the FTP site.
I missed downloading the linux kernel from SCO's website, which they were distributing via the GPL. Can someone who downloaded a copy of the kernel from SCO under the GPL please forward me a copy?
Mail me at "req at semiotek.com" with details if you would be so kind.
It is my belief that since SCO at one point distributed the kernel under the GPL that anyone who downloaded it is legally entitled to use it under the GPL, and therefore legally entitled to send me (or anyone else) a copy.
Someone needs to draw the media's attention to this point: SCO itself has protected the Linux kernel againt any claim of infringement by SCO. Those 1500 companies SCO mailed letters to can rest assured that they have nothing to fear--SCO itself has released the kernel under the GPL and therefore SCO has given everyone in the world a license to use it.
They may have a case against IBM, but SCO itself has given a license to everyone else.
This needs to get more play in the press, and I think it's the most important point in the article.
The interesting thing at the bottom of that RMS article is that if SCO _ever_ distributed the code that they claim infringes a Unix copyright then by their own action they have legally released it under the GPL. So while this may be a nasty contract fight between SCO and IBM, SCO itself has protected the Linux community itself from harm by distributing its own material under the irrevocable GPL.
The only code that might be at risk is anything that SCO never actually distributed--which would mean only some pretty recent contributions. In other words: not a big deal because the recent stuff could be rolled back and rewritten without much pain.
The first doesn't violate the GPL because the software is not under the GPL until the sunset clause flips it over. After that it's only under the GPL--so there's no conflict.
The second would not violate the GPL if you own all the relevant copyrights. Each recipient either gets a copy from you that is only covered by the GPL, or a copy that is only covered by the closed source license. You would be unable to do this if you used anyone else's GPL'd software as you would not be able to release their software under any other license.
The GPL cannot co-exist with a more restrictive license it's true--so they key in both cases above is that it does NOT co-exist. In both cases a particular copy of the software at a particular time is either GPL or it is not.
This is a BAD IDEA. It seems good on the surface, but it has many problems.
First, what happens if the company never makes the expected volume of sales? People using the software with the belief that it would someday become opensource would then be screwed when commercial support dries up and it is never released OSS.
Second, what exactly is placed in escrow? And how can you know? Perhaps the company will hold back on critical components of the software and you won't discover that until after it's "released".
Third, opensource matters in the early days of a project more than at any other time--it is at this point in time when the project is shaped into what is needed by the community, and when the most critical bugs are found and fixed.
Fourth, there is no need for an "escrow" to do this--a company can release the software under a "community source license" which is not open source and simply state in the license the conditions under which it reverts to the GPL. There is no need for any additional agency.
Fifth, I think it has little strategic value for the copyright owner. If the project is going to be such a great success under a commercial license then why cripple your future sales revenue? Most developers open software in order to gain access to resources they would otherwise lack, or as a means of grabbing market share without having to spend a lot of money on marketing. If a company has such a winning product and the money to market it, I simply don't see the value for them in opening it up!
There are MANY better ways to sit on the fence between the opensource and commercial world:
1. You can release your code under a non-open "community" license but with a sunset clause. The sunset clause states the date on which the code flips over to the GPL. New releases would keep advancing this date, but a two year old release might be available under the GPL for all.
2. You can dual license your software under the GPL and under a commercial license. GPL users must keep all their own code GPL'd, but you sell a closed-source license for $$$ which allows closed source distribution of the product.
3. You can take the BK approach: Provide your software under a "mostly" open license which contains some crippling restriction. Note that the BK license includes a clause that if BitKeeper goes out of business the software reverts to the GPL--not after a certain number of sales, but instead if their open logging servers cease operating for a period of 180 days. (This is not great either, but at least it's tied to the failure of the company--and loss of support for the product--rather than its success!!)
It is really NO GOOD to tie the opening of a software product to its success, especially its financial success. This is simply a bad idea.
I think the lesson here is basically that the compiler is your friend. Turn on all the error checking you possibly can in your development environment and pay attention to every last warning.
If there is something trivial causing a warning in your code--fix it so it doesn't warn, even though it wasn't a "bug". If your compiler output is always pristine, with no warnings, then when a warning shows up if it's a bug you'll notice.
Kind of common sense if you ask me--but maybe that's just a lesson I learned the hard way.
Slashdot Mirror
Arch is not the only one, monotone is another, cleaner tool.
The monotone project needs developers to create a free software tool solving the same problem. We really do need good tools that are free.
And I said before just having the versions of the libraries you depend on doesn't cut it, as the QA lab is simply *not* going to have the tools or the time to produce just that configuration in the lab. They *will* have all the major released versions of all the major distributions already set up and waiting for use.
I'm a "home user" in the sense that I have linux at home, at work, and everywhere else, and I want the distribution to choose for me 99.9% of the time--on servers, at home, and everywhere.
/usr/local by downloading the source and compiling and configuring it myself. I will be actively involved in the mailing lists, and familiar with all the current issues, because it's my job, or because I'm just very interested. But I only have energy and time to do that for three or four software packages.
A long time ago I used to try and choose everything for myself, very carefully. I got bored of that, and now I have better things to do with my time. I want the distro to make 99.9% of the choices for me: i want it to choose the window manager and theme, i want it to choose a wordprocessor, an SMTP server, an NFS server, http server, etc., etc., and i really don't care how or what it chooses so long as it works.
There ARE three or four packages that I do care about enough that I want to choose for myself. In those cases I will hand-install into
For everything else, I want the distro to choose for me, and I want it to make a reasonably good choice. So, I prefer redhat over debian, because redhat makes choices, whereas debian tries to give me options. I don't want options: options represent the work of figuring out which one is best. I want the smart guys who made the distro to decide what IMAP server works best with everything else they've stuck on.
Updating before filing a bug does NOT help, unless they investigate the bug the very same day I submit it. What if they don't get around to looking at my bug for three months? How can they possibly figure out exactly what version I had at the time I submitted the bug?
Sorry, it just doesn't work. Nice as the apt-get system is, it is not a substitute for a proper release cycle. Period.
Yeah, I am not running oracle at home, but the scenario is real: I have a lot of other software, though, that is not installed via a
In practice what I did when I was running debian was see if I could replicate the bug myself on a different distribution, like RedHat, and then file based on that. Note that it's worth nothing to the developer to list the libs you depend on: they're NOT going to install just that combination just to check out your bug. For a corp. shop the odds are they DO have common systems already set up in the lab, like "fedora core 2" and "suse whatever" but I can guarantee you they won't have the exact version of "debian unstable" you found your bug on.
Eventually I decided that was retarded to have to replicate it on another system--it made any support I got worth absolutely nothing on debian--and just overwrite Debian with RedHat.
There's no question that apt-get is a better package manager than rpm, but that doesn't help much when the distro itself is run by people who can't figure out how to get a release out more than a few times a decade.
stable often just doesn't cut it because it is too old; the only reason to suggest it really is that it is a known platform. solution: use redhat/fedora, where you get something that is as stable as "unstable", but also has a known version.
i've faced bugs in the field that took weeks to diagnose, so saying i didn't analyze it is just kind of side-stepping the issue, crossing you fingers, and hoping it doesn't happen to you. when it does happen to you, you'll appreciate it if the developers at the other company can run the exact same version of the exact same distro you have, so as to eliminate as many possible variables in debugging.
see above why your arrogant "use reportbug" does not solve my problem.
am i helping with debian? no. i am not using debian. i am not going to use debian if i can help it, so why would i help? i help by using distributions that get this right, thereby giving them larger market share.
.deb's, and yes i do sometimes need to file bugs against these behemoths.
as for filing bugs: maybe you are some kind of purist who thinks i should only be running software that i installed with apt-get, but last i checked things like WebLogic and Oracle did not come as free software
if i were at one of these corps. and i got a bug that says "doesn't work on debian unstable" i would toss it in the trash. i'm also not really interested in doing a lot of work finding every library they link in and sending that list to them, nor would that really help.
saying "it doesn't work on fedora core 2" means there is a high probability that they have in their QA lab a "fedora core 2" machine which they can try and replicate my bug on.
here is how i am helping debian, by providing some worthwhile advice: debian developers reading this, get a clue--give me a stable release version number system that i can use to report bugs.
given all my whining here you may simply say "debian may not be for you", and that was my exact conclusion as well.
sometimes also my typing sucks more, and paradoxically it never sucks less. sorry about that bizarre first paragraph there, i do hope you know what i meant.
some distros suck more; the paradoxical think is that none of them suck less.
i am probably going to use fedora because it has a stable release schedule. that doesn't mean it sucks any less; but other distros suck more. what it really means that means if someone asks me what i am running i can say "fedora core 2" and that means something. that means if i have issues with some software the guy who got my email reporting whatever bug knows what i've got and can see if my problem can be replicated.
try that on debian. debian has no coherent release schedule, and at this point it's not even clear they are EVER going to have another release: the current "release" has been delayed *years* already, and debian users are quite pleased with that. debian users just incrementally apt-get upgrade "unstable" and claim that is OK.
but try figuring out how to file a bug based on that--what exactly is debian unstable? it's a huge moving target, it really doesn't mean anything, and by the time the guy gets around to looking at my bug it's likely radically different. debian needs to get its shit together and get back to 3-4 month releases. apt-get upgrade is really not the answer. i also like rhat's "best of breed" philosophy versus debians "here have everything" philosophy: i don't want to choose most of the time; and when i DO want to choose i probably know what i'm doing well enough to manually install. so most of the time, i want the distro to choose for me.
so where does that leave me? i've got a rh9 that is end of life and i reall don't want to switch to the debian chaos. i'm hoping to go fedora, but you guys say it sucks. enterprise is no good for my home box, it's not worth paying an "enterprise" license for home.
so, here is a plea: make fedora core not suck more than other distros. i don't need support from redhat for my home system; i do need stable planned releases. and guess what? whatever i use at home is likely going to determine what we pay for at work, so it's not like there isn't a business interest here in making me happy. if i do get forced onto debian at home, it's only a matter of time before i advocate for it at work as well.
Compliance tests are incompatible with the way in which opensource software is developed; it is really NOT the same "just with tests".
Mandatory compliance tests are utterly incompatible with the way opensource developers work. OSS development is not done behind closed doors: Broken versions of the software are routinely distributed to anyone and everyone. First, the software repository is probably on a public CVS server, with patches routinely posted on mailing ists; integration builds and nightly builds are likely posted on websites along with release candidates that are the OSS alternative of an expensive QA department. None of this is compatible with compliance testing as the interim releases are practically guaranteed not to pass the tests and so this is all illegal.
Could opensource developers make an exception for Java and work behind closed doors in this case? No. What would be the point--the benefit of an opensource project is that it brings together people from different continents and companies with different motives and interests and enables them to collaborate on a shared resource. These people generally do not, cannot, and will not work together behind a closed door--what door would that be? Worse, that's just development, the "QA team" for an opensource project tend to be just anyone who is willing to download and try out the interim release.
If these severe legal problems could somehow be solved then perhaps it's viable. Maybe we could contemplate "time limited" release licenses for the interim versions--users can use and access them for a few months before they "expire", whereas a compliant version could be used indefinately.
There are still further problems--to be acceptable, the compliance test ought to be freely available as well, so that anybody can download and run it against their version of the JVM. The content of the compliance test also ought to be under the control of a public standards body so that the community can feed back its development into the standard: what's the use of creating a popular extension of the langauge if it can never be a part of the language?
I fully understand and respect Sun's desire to prevent a fork of Java technology. Were it opensourced tommorow before long there would be incompatible versions of Java from Sun, Microsoft, IBM, and who knows how many countless others. It's an understandable, important objective to prevent the platform itself from forking incompatibly.
However, this is a problem that does need a solution and saying that it is really the same thing "just with compliance tests" is an inadequate response: compliance tests, as they stand, are fundamentally incompatible with opensource software.
I hadn't previously realized that one of Canada's major banks, Royal, was a SCO backer. I urge everyone in Canada who has business with Royal to cancel their cards, accounts, move their mortgages, etc., and when you do it, write a letter to RBC telling them why.
It probably won't make a difference, but you don't have to have YOUR money in SCO, which is where it is if it's in a Royal Bank account.
Re this: "The letter asserts that BayStar is entitled to the redemption of its shares under Article VII.A(vii) of the Certificate of Designation, Preferences and Rights of the Series A-1 Convertible Preferred Stock because SCO has allegedly breached Sections 2(b)(v), 2(b)(viii), 2(b)(viii) and 3(g) of the Exchange Agreement dated February 5 2004 among SCO, BayStar and Royal Bank of Canada, which also holds shares SCO's Series A-1 Convertible Preferred Stock."
There is a proposed ITJOBS futures market on Ideosphere based on these statistics. The claim will trade like a stock symbol between 1 and 100 and payout a value based on the number of IT jobs in the US earning more than $50k/year in 2012. Too bad it's just a game with fake money, otherwise we could all hedge our bets. But at least once it's trading the market ought to give us some insight into where things are going.
Chess has proved the value of a brute force approach--even without a lot of AI routines, simply searching the game tree and adding up the value of the men left on the board is a workable algorithm. Good chess programs improve on that significantly with rules to prune the tree search, and further rules to score a board position. That doesn't work so well in Go: There are 361 points on a Go board, with a typical game lasting some 200 moves--an unimaginably large number of game combinations. Worse, there's no easy way to assign a value to a board position once you've brute forced your way through the combinations. The combination of these two factors is one reason why there are no really good Go playing programs, as there are in Chess.
Go is a great game to play on the Internet. You can order all the books you need to get you started, and then you can play on the 'net. There's not bad Go implementations at Yahoo Games, etc., but eventually you will move up to the real go servers like Kiseido or Panda, both located in Japan.
http://www.fct-cf.gc.ca/bulletins/whatsnew/T-292-0 4.pdf
I bet the machine had some email software on it (Outlook?) that checked for new mail once an internet connection was available. The mail server logs would show the IP address.
OK smarty, did you actually follow your own link? Yes there are a bunch of SRPMS there, but where is the kernel?
I don't see it.
It either has been removed or it was distributed elsewhere. What I am actually asking for is someone who actually has a copy of the kernel which they downloaded from SCO to send me a copy, as contrary to reports here it does NOT appear to be on the website or the FTP site.
Hey. I switched to the at to avoid getting spam, guess you didn't realize that otherwise you wouldn't have been so rude.
I missed downloading the linux kernel from SCO's website, which they were distributing via the GPL. Can someone who downloaded a copy of the kernel from SCO under the GPL please forward me a copy?
Mail me at "req at semiotek.com" with details if you would be so kind.
It is my belief that since SCO at one point distributed the kernel under the GPL that anyone who downloaded it is legally entitled to use it under the GPL, and therefore legally entitled to send me (or anyone else) a copy.
Someone needs to draw the media's attention to this point: SCO itself has protected the Linux kernel againt any claim of infringement by SCO. Those 1500 companies SCO mailed letters to can rest assured that they have nothing to fear--SCO itself has released the kernel under the GPL and therefore SCO has given everyone in the world a license to use it.
They may have a case against IBM, but SCO itself has given a license to everyone else.
This needs to get more play in the press, and I think it's the most important point in the article.
The interesting thing at the bottom of that RMS article is that if SCO _ever_ distributed the code that they claim infringes a Unix copyright then by their own action they have legally released it under the GPL. So while this may be a nasty contract fight between SCO and IBM, SCO itself has protected the Linux community itself from harm by distributing its own material under the irrevocable GPL.
The only code that might be at risk is anything that SCO never actually distributed--which would mean only some pretty recent contributions. In other words: not a big deal because the recent stuff could be rolled back and rewritten without much pain.
No, they don't violate the GPL.
The first doesn't violate the GPL because the software is not under the GPL until the sunset clause flips it over. After that it's only under the GPL--so there's no conflict.
The second would not violate the GPL if you own all the relevant copyrights. Each recipient either gets a copy from you that is only covered by the GPL, or a copy that is only covered by the closed source license. You would be unable to do this if you used anyone else's GPL'd software as you would not be able to release their software under any other license.
The GPL cannot co-exist with a more restrictive license it's true--so they key in both cases above is that it does NOT co-exist. In both cases a particular copy of the software at a particular time is either GPL or it is not.
This is a BAD IDEA. It seems good on the surface, but it has many problems.
First, what happens if the company never makes the expected volume of sales? People using the software with the belief that it would someday become opensource would then be screwed when commercial support dries up and it is never released OSS.
Second, what exactly is placed in escrow? And how can you know? Perhaps the company will hold back on critical components of the software and you won't discover that until after it's "released".
Third, opensource matters in the early days of a project more than at any other time--it is at this point in time when the project is shaped into what is needed by the community, and when the most critical bugs are found and fixed.
Fourth, there is no need for an "escrow" to do this--a company can release the software under a "community source license" which is not open source and simply state in the license the conditions under which it reverts to the GPL. There is no need for any additional agency.
Fifth, I think it has little strategic value for the copyright owner. If the project is going to be such a great success under a commercial license then why cripple your future sales revenue? Most developers open software in order to gain access to resources they would otherwise lack, or as a means of grabbing market share without having to spend a lot of money on marketing. If a company has such a winning product and the money to market it, I simply don't see the value for them in opening it up!
There are MANY better ways to sit on the fence between the opensource and commercial world:
1. You can release your code under a non-open "community" license but with a sunset clause. The sunset clause states the date on which the code flips over to the GPL. New releases would keep advancing this date, but a two year old release might be available under the GPL for all.
2. You can dual license your software under the GPL and under a commercial license. GPL users must keep all their own code GPL'd, but you sell a closed-source license for $$$ which allows closed source distribution of the product.
3. You can take the BK approach: Provide your software under a "mostly" open license which contains some crippling restriction. Note that the BK license includes a clause that if BitKeeper goes out of business the software reverts to the GPL--not after a certain number of sales, but instead if their open logging servers cease operating for a period of 180 days. (This is not great either, but at least it's tied to the failure of the company--and loss of support for the product--rather than its success!!)
It is really NO GOOD to tie the opening of a software product to its success, especially its financial success. This is simply a bad idea.
I think the lesson here is basically that the compiler is your friend. Turn on all the error checking you possibly can in your development environment and pay attention to every last warning.
If there is something trivial causing a warning in your code--fix it so it doesn't warn, even though it wasn't a "bug". If your compiler output is always pristine, with no warnings, then when a warning shows up if it's a bug you'll notice.
Kind of common sense if you ask me--but maybe that's just a lesson I learned the hard way.