You could release only your contributions to the derivative work under a different license -- nothing grants you the authority to sublicense the original author's code under anything but the GPL.
Write that up as a patch to the original GPL'd source (a patchfile that doesn't include any original source -- tricky but do-able) and you could distribute that under whatever license you want. (IMHO, IANAL, etc, etc).
But a derivative work in the normal sense contains some of the original code, so may only be GPL'd (unless you get the original author's permission otherwise, of course).
In a verbal (oral) contract, I at least say that I agree to something -- I give an affirmative indication.
The GPL license requires no such agreement to merely use the code (unlike most EULAs). To the limited extent that the GPL is a contract at all (an open contract), its "contractness" only kicks in if you want to distribute the code (in either original or modified form), in which case you need to comply with the conditions to avoid suit for copyright infringement (not contract violation).
Even distribution doesn't imply that you've agreed to the conditions -- as witness those companies that have distributed GPL'd code without complying with the requirements. It's just that in that case you have no defense if the copyright holder sues your ass for infringement. (The copyright holder could try to sue you anyway even if you are distributing source, but you then can cry "promissary estoppel" because the GPL is in effect a promise not to sue you if you comply with its terms. In practise it's doubtful a GPL copyright holder would bother.)
The difference with most EULA's that "take effect" merely by using the product (eg shrinkwrap licenses) is that the latter don't really license (grant permission) to do anything that you don't already have the right to do under common law just by buying the product -- and so can in effect be ignored (so long as you're not copying and redistributing, etc).
If I tried to then sell my work, I would also have to release my source.
Didn't read the article, did you? That is one thing you would not have to do.
The only thing that copyright law could compel you to do would be to cease distribution of the work that incorporated GPL code. You might choose to scrap the product, or you might choose to write your own version of the offending code. Or, you might choose to release your code under the GPL. But you cannot be compelled to the latter.
(You might also be liable for damages on what you'd already sold, but that's a separate issue.)
(Semi-seriously -- I met my wife at a conference that I wouldn't have been at but for some software I wrote. Okay, never mind that at the time the software was proprietary (but we did provide source to anyone who bought a copy) and was only GPL'd years later...)
I didn't realize that they need ide-scsi or a SCSI-like interface, and maybe they don't
They don't need ide-scsi. They (eg, USB storage devices, which might well be flash rom rather than actual disks) need some kind of interface so that they look like something you can put a filesystem on -- and the SCSI protocol (command level) is it. However, the non-IDE devices (USB, 1394, etc) that need it have their own interfaces to the SCSI module, not ide-scsi.
I got windows 98 to run for weeks at a time on my machine.
Less than five, I'll bet. Win98 had a clock bug that locked it up when the counter rolled over. For a while I was using Win98 with WinProxy as a gateway (stupid USB DSL modem) and yes, it would stay up for weeks at a time but I had to reboot it every month, too. (Nothing else running on the machine, of course.)
Of course barring timer bugs, almost any OS is "stable" if you don't actually ask it to do anything.
that they need to run IBM's mainframe operating systems on their desktop.
Hey, I do run an IBM mainframe operating system on my desktop. (Although admittedly, not very often. But it does run faster than any hardware that the OS was explicitly designed for.)
Although come to think of it, anyone running Linux is also running an IBM mainframe operating sytem.
I know two people running Windows XP Home Edition who have repeated problems with the thing just locking up solid. One of them refuses to use the machine for any critical work and gave to the kids for games (not that they're real impressed with that behaviour either).
I ran thorough hardware diagnostics on it and it had no problems running Linux indefinitely, so it's definitely a software problem. Might it be some stupid DLL or config thing? Sure -- but as far as the user is concerned, its WinXP that's the piece of trash.
Most games for the younger set (the "edutainment" stuff) should work fine under WINE.
I haven't done an exhaustive test of my kids' software, but considering it all runs fine on ancient P-133, 48M boxes under Win95 and much of it was originally designed to run on a 486 (under DOS, some of it), or on a Mac, (both binaries on the disc), it's not taking advantage of anything exotic in the hardware or the software.
Oh, there are a couple of exceptions -- one of the Microsoft "Magic Schoolbus" titles was uncooperative with the CD drive in my son's computer (no idea why, the other Schoolbus titles didn't care).
It's been 30 years since anybody went to the Moon. We're about due.
Consider the early history of Antarctic exploration -- there was the "South Pole Race" in the 1909-1912 era (Shackleton, who didn't quite make it, then the real race between Amundsen and Scott), then essentially nothing (except for the Byrd aerial expeditions in the 30s) for about 35 years until the US Navy's Operation Highjump after WWII and then full-time permanent bases since IGY in 1957.
I for one welcome our new Selenite overl^W^W^W^W a return to the Moon.
Well, yeah, the Makefile.in files get created before the user runs 'configure', but configure has to translate those to Makefiles. The bigger they are, the longer that takes. And the longer the make itself takes to run (with all the elaborate dependency checking).
Shrug. I may try again on my next project. I just tried the default on my current project and didn't like the results, so I went back to handmade Makefile.ins.
(BTW, I see you're one of the GNU libstdc++ maintainers -- any particular reason why one can't key a hash_map with a string (vs char*) without grafting on one's own hash definition? Seems like it'd be more common to use string than char*.)
Also, let's not forget that most developers do not have 15 boxes with different architectures/OSes to play around with at home.
Maybe most don't. Some of us do.
In my office alone I've got 11 boxes with 3 architectures (x86, PPC, 68K) and 6 OSs (Linux, Solaris, FreeBSD, MacOS, Windows - oh, okay, 5), including a small Beowulf cluster (only 5 nodes of P-166s, but hey..). Then there's the four machines in the basement, one of which has yet another architecture (Sparc). And if I get really wild and crazy, may main machine has a Hercules emulator I can run OS360 on, which I suppose I could load with Linux/S390...
But perhaps I'm a fanatic.
(OTOH, you can pick up eg. P-166 64M machines dirt cheap (some places might even pay you to haul them away) and at least install the *BSDs, a couple of different Linux distros, and maybe Solaris. I wouldn't use those for primary development, but it'd be fine for testing whether the thing at least configures, makes and more-or-less runs. And there's the OSDL for significnt projects.)
I'll agree that automake is more trouble than it's worth -- it really needs a complete rewrite. OTOH, I've never met a make-make program (to automatically generate a makefile from the source tree) that did an adequate job. They either miss too much or include almost everything in the system as a dependency (which may be technically correct, but is usually unnecessary).
Autoconf, though, is pretty handy for dealing with things that are fairly commonly on different places (or even named differntly) on different 'nixes. Examples: lex/flex, yacc/bison/byacc, where the X11 includes and libs hide, etc. -- all handled trivially by autoconf with a minimal configure.in and the Makefile.in can be trivially made from your existing Makefile.
Portable makefiles and small portability test programs is the right way to do it.
You just described autoconf, configure.in and Makefile.in.
a big slowdown is the part at the very end, when files like Makefile and config.h are being created.
'sed' aside, I wonder how much of that has to do with the ridiculous Makefiles (ok, Makefile.ins) that get generated if you use automake. I recently tried automake on a project, and the Makefiles were fscking huge! 600 and 800 line makefiles! I blew them away and make Makefile.ins out of the original development Makefiles I had. Sheesh.
* some required feature is not supported on your platform,
In which case, the configure script should print a message telling you about it (and ideally, what configure option (eg --without-foo) to try to get around it, or what other package to install.
Preferably in noticeable enough text to stand out from all the normal messages configure spits out. And maybe prefixed by "Don't Panic!" in large friendly letters....
(I'm in the midst of tweaking my configure scripts for a rather complex package. I've got several flavors of Linux box, a BSD machine, and one running Solaris. Did you know that 'ar' is in an unusual (outside the usual PATH) place on Solaris? And that autoconf doesn't support @AR@? Aaarrrggghhh!)
It's widely reported in print that he said 'crud', yes -- and that's the way Sturgeons Law is usually printed. I've heard, though, that the actual word he used was somewhat stronger. Shrug, I wasn't there, I don't know.
(I've also heard that, originally and privately, what publishers/editors call the 'slush pile' actually uses a much stronger term beginning with 's'. Again, the milder form is used in print. I sometimes wonder if the the latter is so widely repeated and used that it ('slush') has replaced the original stronger term.)
Oh, go on, quantify it. Sturgeon did -- he said, at a science fiction convention no less, that "90% of science fiction is crap". Collective gasps from the audience. But then he went on to finish what became known as Sturgeon's Law: "but then, 90% of everything is crap".
In the Golden Age of Science Fiction (which is when the reader is 14), one has a much higher tolerance for reading crap, so it's all good (well, except Perry Rhodan -- even at 14 I couldn't stomach that.) We get more selective as we get older, partly because our tastes are more refined, partly is that we just don't have the time to waste reading the crap vs the good stuff.
Makes sense. If they can't calibrate the polygraph in your case, they can't tell whether you're just being very truthful, if you're so psychopathic that you don't care when you're lying (hence no physiological reaction), or if you've developed sufficient control over normally involuntary physical responses (eg through biofeedback training) that you're conciously suppressing a response to a lie.
Either way, it tells them that they can't tell when you're lying. Which, conversely, means they can't tell when you're telling the truth either. Which means they can't trust you enough to hire you -- no matter how trustworthy you really may be.
What are you babbling on about? Twenty years ago people had IBM PCs on their desks and the Macintosh was a month or so away from being introduced with it's "Big Brother" SuperBowl ad.
Even thirty years ago plenty of people had terminals on their desks (dumb ASCII terminals, sometimes hardcopy (2741s), or IBM 3270s).
Try forty years ago.
And what that has to do with employees being allowed to muck up a corporate asset by installing unauthorized software without knowing what they're doing is beyond me. (If they know what they're doing, then whether the necessarily libs are preinstalled or not is a non-issue, yes?)
Of course molecular assemblers are possible. Your body contains billions of them -- ribosomes.
A ribosome (a combination of several large protein molecules) constructs arbitrary protein molecules from individual amino acids according to the instructions on a strand of RNA (copied from DNA). Sounds like a molecular assembler to me.
Now, as to whether they can be made smaller and more flexible than that (nanotech's "universal assembler") is another question -- ribosomes may turn out to be the minimum possible assembler. Or not.
Between Caldera and old-SCO, there were nearly a dozen programmers than contributed to the Linux kernel, and are acknowledged in various CREDITS files in the source. As is a senior level manager who not only knew about Chris's work, but encouraged it.
Further, given that Caldera's marketing department was touting some of the features (SMP, JFS, etc) in their literature (for their Linux distro), SCOX (nee Caldera) has no way at all to convincingly argue that this was not authorized or not known about.
Slashdot Mirror
You could release only your contributions to the derivative work under a different license -- nothing grants you the authority to sublicense the original author's code under anything but the GPL.
Write that up as a patch to the original GPL'd source (a patchfile that doesn't include any original source -- tricky but do-able) and you could distribute that under whatever license you want. (IMHO, IANAL, etc, etc).
But a derivative work in the normal sense contains some of the original code, so may only be GPL'd (unless you get the original author's permission otherwise, of course).
In a verbal (oral) contract, I at least say that I agree to something -- I give an affirmative indication.
The GPL license requires no such agreement to merely use the code (unlike most EULAs). To the limited extent that the GPL is a contract at all (an open contract), its "contractness" only kicks in if you want to distribute the code (in either original or modified form), in which case you need to comply with the conditions to avoid suit for copyright infringement (not contract violation).
Even distribution doesn't imply that you've agreed to the conditions -- as witness those companies that have distributed GPL'd code without complying with the requirements. It's just that in that case you have no defense if the copyright holder sues your ass for infringement. (The copyright holder could try to sue you anyway even if you are distributing source, but you then can cry "promissary estoppel" because the GPL is in effect a promise not to sue you if you comply with its terms. In practise it's doubtful a GPL copyright holder would bother.)
The difference with most EULA's that "take effect" merely by using the product (eg shrinkwrap licenses) is that the latter don't really license (grant permission) to do anything that you don't already have the right to do under common law just by buying the product -- and so can in effect be ignored (so long as you're not copying and redistributing, etc).
If I tried to then sell my work, I would also have to release my source.
Didn't read the article, did you? That is one thing you would not have to do.
The only thing that copyright law could compel you to do would be to cease distribution of the work that incorporated GPL code. You might choose to scrap the product, or you might choose to write your own version of the offending code. Or, you might choose to release your code under the GPL. But you cannot be compelled to the latter.
(You might also be liable for damages on what you'd already sold, but that's a separate issue.)
Hey it worked for me.
(Semi-seriously -- I met my wife at a conference that I wouldn't have been at but for some software I wrote. Okay, never mind that at the time the software was proprietary (but we did provide source to anyone who bought a copy) and was only GPL'd years later...)
Ah, clearly this is some new meaning of the word "supported" with which I was previously unfamiliar.
It recognized the USB ports as existing, it didn't (reliably) do anything particularly useful with them.
I didn't realize that they need ide-scsi or a SCSI-like interface, and maybe they don't
They don't need ide-scsi. They (eg, USB storage devices, which might well be flash rom rather than actual disks) need some kind of interface so that they look like something you can put a filesystem on -- and the SCSI protocol (command level) is it. However, the non-IDE devices (USB, 1394, etc) that need it have their own interfaces to the SCSI module, not ide-scsi.
Win98 experienced the same symptoms, for whatever reason. Win95 didn't support USB.
I got windows 98 to run for weeks at a time on my machine.
Less than five, I'll bet. Win98 had a clock bug that locked it up when the counter rolled over. For a while I was using Win98 with WinProxy as a gateway (stupid USB DSL modem) and yes, it would stay up for weeks at a time but I had to reboot it every month, too. (Nothing else running on the machine, of course.)
Of course barring timer bugs, almost any OS is "stable" if you don't actually ask it to do anything.
that they need to run IBM's mainframe operating systems on their desktop.
Hey, I do run an IBM mainframe operating system on my desktop. (Although admittedly, not very often. But it does run faster than any hardware that the OS was explicitly designed for.)
Although come to think of it, anyone running Linux is also running an IBM mainframe operating sytem.
I know two people running Windows XP Home Edition who have repeated problems with the thing just locking up solid. One of them refuses to use the machine for any critical work and gave to the kids for games (not that they're real impressed with that behaviour either).
I ran thorough hardware diagnostics on it and it had no problems running Linux indefinitely, so it's definitely a software problem. Might it be some stupid DLL or config thing? Sure -- but as far as the user is concerned, its WinXP that's the piece of trash.
Most games for the younger set (the "edutainment" stuff) should work fine under WINE.
I haven't done an exhaustive test of my kids' software, but considering it all runs fine on ancient P-133, 48M boxes under Win95 and much of it was originally designed to run on a 486 (under DOS, some of it), or on a Mac, (both binaries on the disc), it's not taking advantage of anything exotic in the hardware or the software.
Oh, there are a couple of exceptions -- one of the Microsoft "Magic Schoolbus" titles was uncooperative with the CD drive in my son's computer (no idea why, the other Schoolbus titles didn't care).
Okay, thanks.
Amazingly, that all made sense. I must be having flashbacks...
It's been 30 years since anybody went to the Moon. We're about due.
Consider the early history of Antarctic exploration -- there was the "South Pole Race" in the 1909-1912 era (Shackleton, who didn't quite make it, then the real race between Amundsen and Scott), then essentially nothing (except for the Byrd aerial expeditions in the 30s) for about 35 years until the US Navy's Operation Highjump after WWII and then full-time permanent bases since IGY in 1957.
I for one welcome our new Selenite overl^W^W^W^W a return to the Moon.
Well, yeah, the Makefile.in files get created before the user runs 'configure', but configure has to translate those to Makefiles. The bigger they are, the longer that takes. And the longer the make itself takes to run (with all the elaborate dependency checking).
Shrug. I may try again on my next project. I just tried the default on my current project and didn't like the results, so I went back to handmade Makefile.ins.
(BTW, I see you're one of the GNU libstdc++ maintainers -- any particular reason why one can't key a hash_map with a string (vs char*) without grafting on one's own hash definition? Seems like it'd be more common to use string than char*.)
Also, let's not forget that most developers do not have 15 boxes with different architectures/OSes to play around with at home.
...
Maybe most don't. Some of us do.
In my office alone I've got 11 boxes with 3 architectures (x86, PPC, 68K) and 6 OSs (Linux, Solaris, FreeBSD, MacOS, Windows - oh, okay, 5), including a small Beowulf cluster (only 5 nodes of P-166s, but hey..). Then there's the four machines in the basement, one of which has yet another architecture (Sparc). And if I get really wild and crazy, may main machine has a Hercules emulator I can run OS360 on, which I suppose I could load with Linux/S390
But perhaps I'm a fanatic.
(OTOH, you can pick up eg. P-166 64M machines dirt cheap (some places might even pay you to haul them away) and at least install the *BSDs, a couple of different Linux distros, and maybe Solaris. I wouldn't use those for primary development, but it'd be fine for testing whether the thing at least configures, makes and more-or-less runs. And there's the OSDL for significnt projects.)
I'll agree that automake is more trouble than it's worth -- it really needs a complete rewrite. OTOH, I've never met a make-make program (to automatically generate a makefile from the source tree) that did an adequate job. They either miss too much or include almost everything in the system as a dependency (which may be technically correct, but is usually unnecessary).
Autoconf, though, is pretty handy for dealing with things that are fairly commonly on different places (or even named differntly) on different 'nixes. Examples: lex/flex, yacc/bison/byacc, where the X11 includes and libs hide, etc. -- all handled trivially by autoconf with a minimal configure.in and the Makefile.in can be trivially made from your existing Makefile.
Portable makefiles and small portability test programs is the right way to do it.
You just described autoconf, configure.in and Makefile.in.
a big slowdown is the part at the very end, when files like Makefile and config.h are being created.
'sed' aside, I wonder how much of that has to do with the ridiculous Makefiles (ok, Makefile.ins) that get generated if you use automake. I recently tried automake on a project, and the Makefiles were fscking huge! 600 and 800 line makefiles! I blew them away and make Makefile.ins out of the original development Makefiles I had. Sheesh.
Most tests fail because
* some required feature is not supported on your platform,
In which case, the configure script should print a message telling you about it (and ideally, what configure option (eg --without-foo) to try to get around it, or what other package to install.
Preferably in noticeable enough text to stand out from all the normal messages configure spits out. And maybe prefixed by "Don't Panic!" in large friendly letters....
(I'm in the midst of tweaking my configure scripts for a rather complex package. I've got several flavors of Linux box, a BSD machine, and one running Solaris. Did you know that 'ar' is in an unusual (outside the usual PATH) place on Solaris? And that autoconf doesn't support @AR@? Aaarrrggghhh!)
It's widely reported in print that he said 'crud', yes -- and that's the way Sturgeons Law is usually printed. I've heard, though, that the actual word he used was somewhat stronger. Shrug, I wasn't there, I don't know.
(I've also heard that, originally and privately, what publishers/editors call the 'slush pile' actually uses a much stronger term beginning with 's'. Again, the milder form is used in print. I sometimes wonder if the the latter is so widely repeated and used that it ('slush') has replaced the original stronger term.)
Because so very much of sci-fi is excrable
Oh, go on, quantify it. Sturgeon did -- he said, at a science fiction convention no less, that "90% of science fiction is crap". Collective gasps from the audience. But then he went on to finish what became known as Sturgeon's Law: "but then, 90% of everything is crap".
In the Golden Age of Science Fiction (which is when the reader is 14), one has a much higher tolerance for reading crap, so it's all good (well, except Perry Rhodan -- even at 14 I couldn't stomach that.) We get more selective as we get older, partly because our tastes are more refined, partly is that we just don't have the time to waste reading the crap vs the good stuff.
Makes sense. If they can't calibrate the polygraph in your case, they can't tell whether you're just being very truthful, if you're so psychopathic that you don't care when you're lying (hence no physiological reaction), or if you've developed sufficient control over normally involuntary physical responses (eg through biofeedback training) that you're conciously suppressing a response to a lie.
Either way, it tells them that they can't tell when you're lying. Which, conversely, means they can't tell when you're telling the truth either. Which means they can't trust you enough to hire you -- no matter how trustworthy you really may be.
What are you babbling on about? Twenty years ago people had IBM PCs on their desks and the Macintosh was a month or so away from being introduced with it's "Big Brother" SuperBowl ad.
Even thirty years ago plenty of people had terminals on their desks (dumb ASCII terminals, sometimes hardcopy (2741s), or IBM 3270s).
Try forty years ago.
And what that has to do with employees being allowed to muck up a corporate asset by installing unauthorized software without knowing what they're doing is beyond me. (If they know what they're doing, then whether the necessarily libs are preinstalled or not is a non-issue, yes?)
The risk, of course, is ending up with something almost but not completely unlike tea.
Especially if your replicator is another fine product of Sirius Cybernetics.
Of course molecular assemblers are possible. Your body contains billions of them -- ribosomes.
A ribosome (a combination of several large protein molecules) constructs arbitrary protein molecules from individual amino acids according to the instructions on a strand of RNA (copied from DNA). Sounds like a molecular assembler to me.
Now, as to whether they can be made smaller and more flexible than that (nanotech's "universal assembler") is another question -- ribosomes may turn out to be the minimum possible assembler. Or not.
Between Caldera and old-SCO, there were nearly a dozen programmers than contributed to the Linux kernel, and are acknowledged in various CREDITS files in the source. As is a senior level manager who not only knew about Chris's work, but encouraged it.
Further, given that Caldera's marketing department was touting some of the features (SMP, JFS, etc) in their literature (for their Linux distro), SCOX (nee Caldera) has no way at all to convincingly argue that this was not authorized or not known about.
SCO's toast.