Actually we've found that we DON'T have to accept RMS' views lock, stock, and barrel. He didn't flame us for keeping software proprietary. Instead, he praised our respect for that code released under the GPL, and encouraged us to release some of our one code under the GPL.
As for copulating with goats, personally I wouldn't care if he did. The goats, OTOH might have a different opinion.
ObDisclaimer: These opinions are exclusively mine and certaintly aren't those of Teradyne, unless they happen to agree with me.
That was the idea. Sorry that people didn't like the first person account (after all, RMS said all the same things that he usually says). My point, which I suppose I didn't get across all that well, is that, IMHO, RMS isn't the zealot that he's made out to be.
It remains to be seen how quickly Teradyne moves. I think (and this is my opinion) that our biggest problem won't be GPL compliance (except in some perverse temporary situations where we might lose millions if we don't deliver binaries NOW, but haven't yet packaged a source distributon, but I digress) but actually getting someone to decide that a particular piece of original code isn't "Strategic" and can be released under the GPL. Or that some enhancement to GPL code (I've made some interesting ones to Anaconda), can get released before we ship product (and have to release).
Actually, we brought RMS in for two reasons: (1) to educate some of our possibly less clueful developers about the GPL since we wanted to avoid inadvertent GPL-violation accidents (that the/. crowd is all to quick to jump on); and (2) to show that we're serious about GPL compliance.
I've got a couple problems with the license myself with regard to some common practices which delay release of source after binary, but, with respect the those who have authored code that we extend, and have chosen to use that license, we have to live with them.
I remember figuring out the prime-time wizard password by comparing a virgin installed binary with the binary you (or was it RP?) made available.
Oh well, I better get back to the flamage over my first person account. I wanted to avoid the usual "RMS came here and said what he always says article", but I guess it didn't come off well.
Heh, that looks similar to part of a full-length female nude line-printer image that was floating around when I was in college (circa 1982). We got some dot-matrix graphic printers, and I wrote a program to estimate the grew level of the character image and produce a dithered higher-resolution image for the dot-matrix printer. It worked better than expected.
I actually got to submit that program as part of an assignment (with different images).
I once got severely repremanded for some comments in code I had written... they weren't intended for anyone but me, but management thought it would be a good idea to snarf a pre-release copy of code from my PC. Somehow the resulting bru-ha-ha was my fault.
I have been known to include
var sbv: boolean; { note: spurrious boolean variable, not sexy blonde virgin } in old PASCAL code.
This is an issue I've been strugling with at work: is the combination of a program and a dynamically linked GPL library a derivative work of the library (and thus required to be redistributed under the terms of the GPL)? RMS has told me that it "depends on the nature of the interface" between the program and library, and that ultimately a court of law would have to decide if the combination is a derivative work. I've asked a lawyer, and the opinion that I got was that the GPL is not specific enough to decide. I was advised that any form of static link would require redistribution under the GPL because the compiled forms of the progam and library could not be disentangled, making the argument for aggregation weak. But, all bets are off for dynamicly linked code. Let's consider the case of a GPL library L, wrapper W statically linked to it, and the combination dynamically loaded by a program P. Dynamic loading (at least under [GNU/]Linux) permits references between P and W or L to be resolved, as well as references between W and P. (Clearly, references between L and P or L and W would have to be to normal O/S, or compiler library components). Clearly W has to be redistributed under the GPL (because it is statically linked to L). In my mind, if W is tightly coupled to P (by virtue of its references into P, and objects passed by P), P is a derived work of W, and thus has to be distributed under the GPL, if distributed with L. On the other hand, if callbacks into P from W are related to W's functionality, so that the combination of W and L are useful in dynamically linked contexts with programs other than P, then I'd argue that P is NOT a derived work of W, and so can be relased under a license other than the GPL, even if distributed with W and L. The problem here stems from the fact that the GPL permits aggregates of free and non-free code to be distributed, but an aggregate can, at run-time, appear to be a derived work. I my case, I've taken the precaution of making the combination of W and L of a program in it's own right, and running it as a spawned program, instead of a DLL loaded by P. However, I see this as a cosmetic difference (and one where performance pressures might favour the use of a DLL) and a 'hack' to get around the GPL. Sadly, the W I've produced (actually a W0 and several W1..Wn that W0 dynamically loads as required (and which rely on internal data structures maintained by W0, and are thus derived works of W0)) are useful free software. If we can not simply distribute W0..Wn and L under the GPL, and P as proprietary code, we will be forced to implement our own Lp and release the lot as proprietary code. Unfortunately, the only reason we'd even release W0..Wn under the GPL is because our use of L requires it (not my idea).
I've managed projects with a hierarchy of directories, and therefore, makefiles spawning make over other makefiles.
While it works, it can get messy, particularly when you have to automatically keep track of build environment variables that should be different in different directories (i.e. turn on this level of debugging here, here, and THERE).You really want to keep such settings (with defaults on a global, per directory, and per-directory sub--hierarchy, as appropriate) outside of makefiles. That way, you can carry around custom-debug-enabling files separate from the rest of the build tree (ever say, "Heck, I'll start from scratch, but I wanna keep all the local overrides?).
These "support" files then need to be included (often recursively up the directory tree) in the makefile as well as automatically generated, when there are no default overrides. Furthermore, as they change, things need to be rebuilt. Ergo: makefiles that have build dependencies on the very files they include. Ugh.
You can do all this in GNU make. But, it gets really messy really fast.
I've managed projects with a hierarchy of directories, and therefore, makefiles spawning make over other makefiles. While it works, it can get messy, particularly when you have to automatically keep track of build environment variables that should be different in different directories (i.e. turn on this level of debugging here, here, and THERE).You really want to keep such settings (with defaults on a global, per directory, and per-directory sub--hierarchy, as appropriate) outside of makefiles. That way, you can carry around custom-debug-enabling files separate from the rest of the build tree (ever say, "Heck, I'll start from scratch, but I wanna keep all the local overrides?). These "support" files then need to be included (often recursively up the directory tree) in the makefile as well as automatically generated, when there are no default overrides. Furthermore, as they change, things need to be rebuilt. Ergo: makefiles that have build dependencies on the very files they include. Ugh. You can do all this in GNU make. But, it gets really messy really fast. Regards, Rene S. Hollan
Slashdot Mirror
It would be a neat trick for them to work through our firewall...
Actually we've found that we DON'T have to accept RMS' views lock, stock, and barrel. He didn't flame us for keeping software proprietary. Instead, he praised our respect for that code released under the GPL, and encouraged us to release some of our one code under the GPL.
As for copulating with goats, personally I wouldn't care if he did. The goats, OTOH might have a different opinion.
ObDisclaimer: These opinions are exclusively mine and certaintly aren't those of Teradyne, unless they happen to agree with me.
That was the idea. Sorry that people didn't like the first person account (after all, RMS said all the same things that he usually says). My point, which I suppose I didn't get across all that well, is that, IMHO, RMS isn't the zealot that he's made out to be.
It remains to be seen how quickly Teradyne moves. I think (and this is my opinion) that our biggest problem won't be GPL compliance (except in some perverse temporary situations where we might lose millions if we don't deliver binaries NOW, but haven't yet packaged a source distributon, but I digress) but actually getting someone to decide that a particular piece of original code isn't "Strategic" and can be released under the GPL. Or that some enhancement to GPL code (I've made some interesting ones to Anaconda), can get released before we ship product (and have to release).
Actually, we brought RMS in for two reasons: (1) to educate some of our possibly less clueful developers about the GPL since we wanted to avoid inadvertent GPL-violation accidents (that the /. crowd is all to quick to jump on); and (2) to show that we're serious about GPL compliance.
I've got a couple problems with the license myself with regard to some common practices which delay release of source after binary, but, with respect the those who have authored code that we extend, and have chosen to use that license, we have to live with them.
and yes, I haven't forgotten your password-grabbing trojan horse. What do you do these days?
Yup.
I remember figuring out the prime-time wizard password by comparing a virgin installed binary with the binary you (or was it RP?) made available.
Oh well, I better get back to the flamage over my first person account. I wanted to avoid the usual "RMS came here and said what he always says article", but I guess it didn't come off well.
- RSH
-RSH
The assembler is similar (and without all that wimpy type checking).
-RSH
I actually got to submit that program as part of an assignment (with different images).
-RSH
perform intercourse until tired.
The above line WAS in all caps (as it should be for COBOL), but it set off the lameness detector. Feh.
-RSH
I have been known to include
var sbv: boolean; { note: spurrious boolean variable, not sexy blonde virgin } in old PASCAL code.
-rsh
I've had similar ideas, but haven't taken them anywhere yet. Check out http://www.hollan.org/netconnect.html if you're interested
I sent them $100. I also bought an anti-DVD CCA t-shirt from Copyleft (wearing it now).
I'll probably send them more when some of my stock options vest, though the FSF is next on my list of "worthy causes".
- RSH
This is an issue I've been strugling with at work: is the combination of a program and a dynamically linked GPL library a derivative work of the library (and thus required to be redistributed under the terms of the GPL)? RMS has told me that it "depends on the nature of the interface" between the program and library, and that ultimately a court of law would have to decide if the combination is a derivative work. I've asked a lawyer, and the opinion that I got was that the GPL is not specific enough to decide. I was advised that any form of static link would require redistribution under the GPL because the compiled forms of the progam and library could not be disentangled, making the argument for aggregation weak. But, all bets are off for dynamicly linked code. Let's consider the case of a GPL library L, wrapper W statically linked to it, and the combination dynamically loaded by a program P. Dynamic loading (at least under [GNU/]Linux) permits references between P and W or L to be resolved, as well as references between W and P. (Clearly, references between L and P or L and W would have to be to normal O/S, or compiler library components). Clearly W has to be redistributed under the GPL (because it is statically linked to L). In my mind, if W is tightly coupled to P (by virtue of its references into P, and objects passed by P), P is a derived work of W, and thus has to be distributed under the GPL, if distributed with L. On the other hand, if callbacks into P from W are related to W's functionality, so that the combination of W and L are useful in dynamically linked contexts with programs other than P, then I'd argue that P is NOT a derived work of W, and so can be relased under a license other than the GPL, even if distributed with W and L. The problem here stems from the fact that the GPL permits aggregates of free and non-free code to be distributed, but an aggregate can, at run-time, appear to be a derived work. I my case, I've taken the precaution of making the combination of W and L of a program in it's own right, and running it as a spawned program, instead of a DLL loaded by P. However, I see this as a cosmetic difference (and one where performance pressures might favour the use of a DLL) and a 'hack' to get around the GPL. Sadly, the W I've produced (actually a W0 and several W1..Wn that W0 dynamically loads as required (and which rely on internal data structures maintained by W0, and are thus derived works of W0)) are useful free software. If we can not simply distribute W0..Wn and L under the GPL, and P as proprietary code, we will be forced to implement our own Lp and release the lot as proprietary code. Unfortunately, the only reason we'd even release W0..Wn under the GPL is because our use of L requires it (not my idea).
I've managed projects with a hierarchy of directories, and therefore, makefiles spawning make over other makefiles.
While it works, it can get messy, particularly when you have to automatically keep track of build environment variables that should be different in different directories (i.e. turn on this level of debugging here, here, and THERE).You really want to keep such settings (with defaults on a global, per directory, and per-directory sub--hierarchy, as appropriate) outside of makefiles. That way, you can carry around custom-debug-enabling files separate from the rest of the build tree (ever say, "Heck, I'll start from scratch, but I wanna keep all the local overrides?).
These "support" files then need to be included (often recursively up the directory tree) in the makefile as well as automatically generated, when there are no default overrides. Furthermore, as they change, things need to be rebuilt. Ergo: makefiles that have build dependencies on the very files they include. Ugh.
You can do all this in GNU make. But, it gets really messy really fast.
Regards,
Rene S. Hollan
I've managed projects with a hierarchy of directories, and therefore, makefiles spawning make over other makefiles. While it works, it can get messy, particularly when you have to automatically keep track of build environment variables that should be different in different directories (i.e. turn on this level of debugging here, here, and THERE).You really want to keep such settings (with defaults on a global, per directory, and per-directory sub--hierarchy, as appropriate) outside of makefiles. That way, you can carry around custom-debug-enabling files separate from the rest of the build tree (ever say, "Heck, I'll start from scratch, but I wanna keep all the local overrides?). These "support" files then need to be included (often recursively up the directory tree) in the makefile as well as automatically generated, when there are no default overrides. Furthermore, as they change, things need to be rebuilt. Ergo: makefiles that have build dependencies on the very files they include. Ugh. You can do all this in GNU make. But, it gets really messy really fast. Regards, Rene S. Hollan