> do you have the right to include *any* gpl'd code in a company project?
Depends on exactly how it is included, and what the company does with it. Included a piece of GPL'ed code in company software, then releasing that software to the world as a binary-only product is a no-no. It is ok in the following cases:
if it is purely for in-house use.
If source is relased.
If the GPL'ed program is included in its entirety as a separate unit, without any modifications. For instance, if you supply a Java Application Server running on Unix, you are free to include bash in its distribution to faciliate running the install scripts. However, you cannot rip out pieces of bash, and incorporate them into the application server executable itself. Likewise, you may link your app against LGPL'ed libraries.
Everything is ok if it is your own code (even a binary-only distribution), in that case you just grant your company a different license (as the author, you have the right to distribute your code under any license you see fit, even conflicting ones). Conceivably, you could release the same code under GPL, BSD and a proprietary license. You are the author, you can release your code under whichever terms you want. However, somebody who is not the author may have trouble combining two pieces together if one is GPL (mandatory source disclosure) and the other is proprietary (NDA forbids source disclosure).
> you have exclusive rights to make derivative works.
"Exclusive" means you are the only one having this right. Which is not the case if you released the work under the GPL: any Joe can download your code and make derivative works of it... as long that work complies to the GPL. So, even if the company forces you to sign over all copyrights, they cannot "unfree" existing versions of the software. The only thing they can do is prevent you from releasing new versions under the GPL, but any other author can take your last free version, and fork the code! Conceivably, you yourself could even pick up at your last free version after you left the company.
What if you use your own GPL'ed code? You certainly have the right to reuse that in a commercial product. The company benefits in multiple ways:
You don't have to redevelop it on company time, which directly saves cost
If any bug is found in the GPL'ed version, you can fix that in the company's version too, before it can cause problems there
But what would the legal implication of such reuse be? Would it still stay "your" code (i.e. do you still have the right to freely distribute it/use it at your next employer)?
Is there any such thing as "shared ownership" for these kinds of situations, i.e. both the company and you would have an unrestrictive, non-exclusive license to the code:
The company may use the product in any way it sees fit, even resell it as part of a closed-source, proprietary product
You can still release it as GPL (only your part obviously, not the product it was integrated in), reuse it at your next employer's, etc.
While this works fine for ethernet, it is somewhat hard to design this in a reliable way for these simple transmitter. Indeed, you'd have to guard not only against undercounting, but also overcounting. What happens if a product misdetects a collision, and responds a second time? What happens if a collision takes place, which is seen by the scanner, but by none of each products? etc. With ethernet, "false alarms" about collisions are no problem, because the extra packet (carrying the same contents as the previous one) will simply be discarded. With product counting, this can't be done, as not only the contents of the packets is important, but also their number. Hence the need to have unique ids by item rather than by kind of item.
> If you read the article, you'd notice that, unlike bar codes, the plan with this thing is to assign a unique ID to every single transmitter;
If you read the post that I was replying to, you'd notice that, unlike what was proposed in the article, intmainvoid was proposing a change where one would only have one ID per product kind, rather than one per single item. Pot, kettle, black!
Then how would it count how many were bought? Sure, ot could measure signal strength, but I presume that this would be affected by position too. Hard to distinguish two cartons far away from the sensor from a single one closeby.
Moreover, there's the issue of not billing you again at your next visit to the store for items that are already payed for (clothes you wear, that half empty pack of tissues in your pocket,...).
These issues do not occur with UPC codes, because those are scanned individually, rather than putting the whole shopping cart through the scanner.
> Face it, if they decided that copyright lasted a billion million years or whatever, it's still "limited."
Actually, the current situation is far worse than one billion million years. Congress has a tendency of extending the duration by 20 years every twenty years, just before a certain set of 1923's Disney copyright are about to expire. So, in a billion million years , duration will be a billion million years + 20, and in two billion million years it will be two billion million + 20 again. See, this pattern of increasing copyright duration effectively makes copyrights last longer than any possible constant duration, i.e. infinite.
Congress should of course be free to revise duration, but not in this way. Add an article that congress cannot extend copyright duration faster than the a certain passage of time. That is, forbid them from extending it by more than x/2 years if the last revision was less than x years ago. This would guarantee that any copyright will expire eventually (in at most twice the current duration), and will remove incentive of high pressure lobbying congress to extend the duration once again.
Presumably, a good spam-mimic would forge address of sender or domain name too, in order to make it look more like real spam...
(Well not in the implementation listed in this story, but this implementation sucks anyways: who says the site is not run by the NSA? And it doesn't even use https for its encode/decode pages, making it actually easyer to snoop cleartext of any message shrouded this way!)
> The censor must actually go to the original site to see what the content looks like.
If the site uses https, then all the sniffer sees is that somebody accessed that site. But not the exact path of the contents, because the request is encrypted as well! all we need to do is to have some neutral cover page, and stick the interesting contents deep down in the site, after a long path. Thus, even "going to the site" won't help, because the censor wouldn't known where exactly to go...
The only solution to this (for the censor) seems indeed to maintain the filter rules by hand, or to use search engines to find exact URLs of potentially questionnable content.
If it's automatic, the mirrors will soon be blocked as well... Moreover, if it's really automatic there will be a new kind of denial-of-service attack: somehow make it appear as if the site is sending content which matches the signature that the sniffer is looking for, and vlammm! site instantly inaccessible...
Although usually it's barber's poles rather than park benches. Has a Fb (false but...) in the AFU FAQ. Other sightings include Caltech,
Harvard,
and MIT. (many of the pages are quite long, search for "barber").
> now that I'm a contractor I'm additionally substantially more aware of how my time is expended (and on this day I *could* have worked an additional hour for a client rather than sitting in the waiting room).
What? You mean you didn't bring your laptop with you?
> Thing is, what's to stop someone trying random numbers until they manage to get money off someone at random?
Make the numbers so large that the probability of hitting a valid one by chance is infinitisemally small. After all, that's how cryptography works: somebody also could try random keys, in the hopes that one of them cracks the message... And moreover, as the numbers would only be good for one transaction, for a preset amount, the damage would be rather limited, even if somebody did somehow manage to guess a valid number. All they could do is steal the money set aside for one transaction, and not empty your whole account.
> The port is bound after starting threads because it can't be bound until after the config file is read, since the config file specifies the ports to listen on. The config file is read after threads are started for several reasons, not the least of which is that it's also read with threads active in the reload case.
Then, what would happen (in the non-Linux case) if the config was indeed reloaded, but a different low port was specified now? At that point, bind would already have dropped the privilege to bind to that port, and couldn't satisfy the reload request anyways. (Ironically enough, it would work on Linux, because you'd still have the capability to bind low ports...). Conclusion: changing port numbers on the fly wouldn't work anyways, so why not do a first parse of the config file before forking threads, and use this pass to gather those pieces of information which aren't changeable after reload anyways?
All depends on exactly how the trade secret was leaked. There are proper and improper ways. Improper ways include:
Somebody who did sign an NDA leaked the secret.
Physically stealing the documents, hacking the servers, or committing some other illegal act for obtaining the secret. N.B. "Illegal act" here obviously refers to the ways that the secret was appropriated, not the appropriation itself, or else we'd have a circular definition...
Reverse engineering a product (depends on jurisdiction...)
...
Proper ways include:
Independant discovery (basically, you came up with the same idea, on your own). N.B. This isn't a defense for patent infringment: you're banned from using patented technology, even if you developped it entirely yourself, if somebody else was quicker to develop the same thing and patent it.
Reverse engineering (ok in other jurisdictions, such as EEC)
Taking advantage of gross negligence (if for instance the firm accidentally posts it to its public website...)
...
Other ways (such as rummaging through a firm's trash, or receiving an improperly acquired trade secret without being informed that it was improperly acquired) are debatable, and may depend on jurisdiction, what the judge had for breakfast, the phase of the moon, etc.
The DeCSS question revolved around the question whether in this particular instance, reverse engineering was indeed a proper way or not. The reverse engineering happened on European soil, where normally it would have been legal, but concerned a US product, where reverse engineering normally isn't legal. But the MPAA realized they were on very shaky legal grounds here, and pretty quickly abandoned this avenue and preferred to use the DMCA (illegal to distribute tools for circumventing an "access control device").
Quoted from the bind9 FAQ:
Q: Why doesn't -u work on Linux 2.2.x?
A: Linux threads do not fully implement the Posix threads (pthreads) standard.
In particular, setuid() operates only on the current thread, not the full
process. Because of this limitation, BIND 9 cannot use setuid() on Linux as it
can on all other supported platforms. setuid() cannot be called before
creating threads, since the server does not start listening on reserved ports
until after threads have started.
My take on this:
Then why the hell do they do the setuid() call so late in the process? Just do it right after binding the port, but before forking any threads. Why the hell does that port have to be bound after starting threads? It's shared by all threads anyways, so why not bind it early?
> But some people have suggested that it is possible for a process to get out of chroot. Can somebody please elaborate?
If a process still has uid 0, there are several ways to break out of chroot:
make a subdirectory foo
chroot into it (without chdir'ing into it...): Current directory is now above root... Indeed, the chroot syscall only changes your process' root, but does not automatically change its current directory.
repeatedly chdir("..");. This works because chdir only checks whether your current directory is equal to your root, it does not check for the case where it is above the root.
once arrived at the physical root, chroot("."); and presto, you just broke out of the chroot jail
Even if this hole was patched (AFAIK, it exists in all Unix variants...), it would still be possible to break out of chroot by fiddling with raw devices such as disks and/dev/kmem. Conclusion: chroot() can only be used in conjunction with setuid() to a non-privileged user. Chroot makes it difficult for a non-priv user to gain root, but it doesn't protect anything if ever the user succeds to gain root anyways...
> I never quite understood the complaints people had about the USPS; you put something in the mail, in a few days it's delivered. What more do you want?
No need to want anything more than that, but the problem many people have, often you don't get that much: mail that takes ages to get delivered, is lost, or arrives in damaged condition (even if packaged properly...).
Oh, wait, the BSD's are so much better than Linux that nobody in their right mind would ever consider switching from BSD to Linux, taking away that important "release valve", and leaving no other choice to BSD than to fork... It all falls into place now! Oh, btw, what "advanced" developments are taking place in FreeBSD now that Linux does not yet have? What technology are we importing from BSD right now? No, the "more performant network code" doesn't count. That was years ago. Just curious.
> The use of OFFTOPIC moderation has gotten way out of hand. I meta-mod those unfair and mod them back up when moderator
Wouldn't it be easyer if you actually read the posts you're replying to? That way, no sensible moderatorwould you moderate as offtopic.
Grit was complaining about Earthlink's mail server refusing e-mail which was indeed addressed to anEarthlink customer, a thing which ORBS explicitely allows. ORBS is only concerned about e-mail which neither comes from the provider nor goes to the provider (i.e. mail server solely used as a relay)
Or just waste their time:
-Sorry, there's somebody at the door, I'll be back in a minute.
Then, half an hour later, come back and check whether he is still on line...
Slashdot Mirror
Depends on exactly how it is included, and what the company does with it. Included a piece of GPL'ed code in company software, then releasing that software to the world as a binary-only product is a no-no. It is ok in the following cases:
- if it is purely for in-house use.
- If source is relased.
- If the GPL'ed program is included in its entirety as a separate unit, without any modifications. For instance, if you supply a Java Application Server running on Unix, you are free to include bash in its distribution to faciliate running the install scripts. However, you cannot rip out pieces of bash, and incorporate them into the application server executable itself. Likewise, you may link your app against LGPL'ed libraries.
Everything is ok if it is your own code (even a binary-only distribution), in that case you just grant your company a different license (as the author, you have the right to distribute your code under any license you see fit, even conflicting ones). Conceivably, you could release the same code under GPL, BSD and a proprietary license. You are the author, you can release your code under whichever terms you want. However, somebody who is not the author may have trouble combining two pieces together if one is GPL (mandatory source disclosure) and the other is proprietary (NDA forbids source disclosure)."Exclusive" means you are the only one having this right. Which is not the case if you released the work under the GPL: any Joe can download your code and make derivative works of it... as long that work complies to the GPL. So, even if the company forces you to sign over all copyrights, they cannot "unfree" existing versions of the software. The only thing they can do is prevent you from releasing new versions under the GPL, but any other author can take your last free version, and fork the code! Conceivably, you yourself could even pick up at your last free version after you left the company.
- You don't have to redevelop it on company time, which directly saves cost
- If any bug is found in the GPL'ed version, you can fix that in the company's version too, before it can cause problems there
But what would the legal implication of such reuse be? Would it still stay "your" code (i.e. do you still have the right to freely distribute it/use it at your next employer)? Is there any such thing as "shared ownership" for these kinds of situations, i.e. both the company and you would have an unrestrictive, non-exclusive license to the code:While this works fine for ethernet, it is somewhat hard to design this in a reliable way for these simple transmitter. Indeed, you'd have to guard not only against undercounting, but also overcounting. What happens if a product misdetects a collision, and responds a second time? What happens if a collision takes place, which is seen by the scanner, but by none of each products? etc. With ethernet, "false alarms" about collisions are no problem, because the extra packet (carrying the same contents as the previous one) will simply be discarded. With product counting, this can't be done, as not only the contents of the packets is important, but also their number. Hence the need to have unique ids by item rather than by kind of item.
If you read the post that I was replying to, you'd notice that, unlike what was proposed in the article, intmainvoid was proposing a change where one would only have one ID per product kind, rather than one per single item. Pot, kettle, black!
Moreover, there's the issue of not billing you again at your next visit to the store for items that are already payed for (clothes you wear, that half empty pack of tissues in your pocket, ...).
These issues do not occur with UPC codes, because those are scanned individually, rather than putting the whole shopping cart through the scanner.
Actually, the current situation is far worse than one billion million years. Congress has a tendency of extending the duration by 20 years every twenty years, just before a certain set of 1923's Disney copyright are about to expire. So, in a billion million years , duration will be a billion million years + 20, and in two billion million years it will be two billion million + 20 again. See, this pattern of increasing copyright duration effectively makes copyrights last longer than any possible constant duration, i.e. infinite.
Congress should of course be free to revise duration, but not in this way. Add an article that congress cannot extend copyright duration faster than the a certain passage of time. That is, forbid them from extending it by more than x/2 years if the last revision was less than x years ago. This would guarantee that any copyright will expire eventually (in at most twice the current duration), and will remove incentive of high pressure lobbying congress to extend the duration once again.
And, did you use up-to-date maps?
(Well not in the implementation listed in this story, but this implementation sucks anyways: who says the site is not run by the NSA? And it doesn't even use https for its encode/decode pages, making it actually easyer to snoop cleartext of any message shrouded this way!)
Funny, you'd mention AOL in a context of "major ISP who doesn't send spam"...
If the site uses https, then all the sniffer sees is that somebody accessed that site. But not the exact path of the contents, because the request is encrypted as well! all we need to do is to have some neutral cover page, and stick the interesting contents deep down in the site, after a long path. Thus, even "going to the site" won't help, because the censor wouldn't known where exactly to go...
The only solution to this (for the censor) seems indeed to maintain the filter rules by hand, or to use search engines to find exact URLs of potentially questionnable content.
Very smart! The same method could actually actually also be used to access the original site... End of story.
Quick! Somebody please moderate the parent as funny! Frogger a violent game? Oh my God!
If it's automatic, the mirrors will soon be blocked as well... Moreover, if it's really automatic there will be a new kind of denial-of-service attack: somehow make it appear as if the site is sending content which matches the signature that the sniffer is looking for, and vlammm! site instantly inaccessible...
Although usually it's barber's poles rather than park benches. Has a Fb (false but...) in the AFU FAQ. Other sightings include Caltech, Harvard, and MIT. (many of the pages are quite long, search for "barber").
What? You mean you didn't bring your laptop with you?
Make the numbers so large that the probability of hitting a valid one by chance is infinitisemally small. After all, that's how cryptography works: somebody also could try random keys, in the hopes that one of them cracks the message... And moreover, as the numbers would only be good for one transaction, for a preset amount, the damage would be rather limited, even if somebody did somehow manage to guess a valid number. All they could do is steal the money set aside for one transaction, and not empty your whole account.
Then, what would happen (in the non-Linux case) if the config was indeed reloaded, but a different low port was specified now? At that point, bind would already have dropped the privilege to bind to that port, and couldn't satisfy the reload request anyways. (Ironically enough, it would work on Linux, because you'd still have the capability to bind low ports...). Conclusion: changing port numbers on the fly wouldn't work anyways, so why not do a first parse of the config file before forking threads, and use this pass to gather those pieces of information which aren't changeable after reload anyways?
- Somebody who did sign an NDA leaked the secret.
- Physically stealing the documents, hacking the servers, or committing some other illegal act for obtaining the secret. N.B. "Illegal act" here obviously refers to the ways that the secret was appropriated, not the appropriation itself, or else we'd have a circular definition...
- Reverse engineering a product (depends on jurisdiction...)
- ...
Proper ways include:- Independant discovery (basically, you came up with the same idea, on your own). N.B. This isn't a defense for patent infringment: you're banned from using patented technology, even if you developped it entirely yourself, if somebody else was quicker to develop the same thing and patent it.
- Reverse engineering (ok in other jurisdictions, such as EEC)
- Taking advantage of gross negligence (if for instance the firm accidentally posts it to its public website...)
- ...
Other ways (such as rummaging through a firm's trash, or receiving an improperly acquired trade secret without being informed that it was improperly acquired) are debatable, and may depend on jurisdiction, what the judge had for breakfast, the phase of the moon, etc.The DeCSS question revolved around the question whether in this particular instance, reverse engineering was indeed a proper way or not. The reverse engineering happened on European soil, where normally it would have been legal, but concerned a US product, where reverse engineering normally isn't legal. But the MPAA realized they were on very shaky legal grounds here, and pretty quickly abandoned this avenue and preferred to use the DMCA (illegal to distribute tools for circumventing an "access control device").
Quoted from the bind9 FAQ:
Q: Why doesn't -u work on Linux 2.2.x?
A: Linux threads do not fully implement the Posix threads (pthreads) standard. In particular, setuid() operates only on the current thread, not the full process. Because of this limitation, BIND 9 cannot use setuid() on Linux as it can on all other supported platforms. setuid() cannot be called before creating threads, since the server does not start listening on reserved ports until after threads have started.
My take on this:
Then why the hell do they do the setuid() call so late in the process? Just do it right after binding the port, but before forking any threads. Why the hell does that port have to be bound after starting threads? It's shared by all threads anyways, so why not bind it early?
> But some people have suggested that it is possible for a process to get out of chroot. Can somebody please elaborate?
If a process still has uid 0, there are several ways to break out of chroot:
- make a subdirectory foo
- chroot into it (without chdir'ing into it...): Current directory is now above root... Indeed, the chroot syscall only changes your process' root, but does not automatically change its current directory.
- repeatedly chdir("..");. This works because chdir only checks whether your current directory is equal to your root, it does not check for the case where it is above the root.
- once arrived at the physical root, chroot("."); and presto, you just broke out of the chroot jail
Even if this hole was patched (AFAIK, it exists in all Unix variants...), it would still be possible to break out of chroot by fiddling with raw devices such as disks andNo need to want anything more than that, but the problem many people have, often you don't get that much: mail that takes ages to get delivered, is lost, or arrives in damaged condition (even if packaged properly...).
Oh, wait, the BSD's are so much better than Linux that nobody in their right mind would ever consider switching from BSD to Linux, taking away that important "release valve", and leaving no other choice to BSD than to fork... It all falls into place now! Oh, btw, what "advanced" developments are taking place in FreeBSD now that Linux does not yet have? What technology are we importing from BSD right now? No, the "more performant network code" doesn't count. That was years ago. Just curious.
Wouldn't it be easyer if you actually read the posts you're replying to? That way, no sensible moderatorwould you moderate as offtopic.
Grit was complaining about Earthlink's mail server refusing e-mail which was indeed addressed to anEarthlink customer, a thing which ORBS explicitely allows. ORBS is only concerned about e-mail which neither comes from the provider nor goes to the provider (i.e. mail server solely used as a relay)
Not as crummy as you made it. Although it did mistranslate "militaries ties" as "military neckties".
Or just waste their time:
-Sorry, there's somebody at the door, I'll be back in a minute.
Then, half an hour later, come back and check whether he is still on line...