It doesn't solve the problem because the poster has two stated goals:
License (under and Open Source License) the Framework which he/she developed. This is a separate, stand-alone, piece of software.
Provide development for a company which uses his Framework, while at the same time performing additional development on the Framework.
The problem is that part of his assigned duties to the company will be to provide further development on the Framework. So how do you decide that an enhancement, which could be re-used by others using the Framework, is put into the Framework code rather than being retained by the company as a proprietary part of their application? It's not a clear delineation.
I think we're missing the point. The question is not how to license the same code in two ways, it's how to differentiate between framework code and application code.
How does one define the difference between a framework (i.e. Jakarta Struts), and an application written with that framework? If there are enhancements made to the framework to satisfy issues related to or which directly impact the employer's application, where does that code lie?
I'm neither an idiot, nor a troll. I pointed my brower to the RS/6000 F80 Tech Specs, and made the amazing discovery that they use PowerPC processors. A quick search of the site for "POWER" produced references to PowerPC, power cords, power supplies, power cables, etc., but no POWER processors.
Hmm. Did you just get out of your DEC-Alpha-heated Y2K shelter? Well, let me catch you up on a couple of things. First, Y2K was the biggest non-event since the 1996 Presidential election. Second, RISC processors are capable of higher performance with less power consumption and therefore less heat generated than their CISC step-cousins.
Need an example. Ok, check out Transmeta. The seemed to find a way to use a fraction of the power of an X86 chip, run the same apps, and perform better with a lower clock speed. PowerPC (used by IBM and Apple, duh!) chips do the same thing, only without the X86 compatibility.
If the folks in Indianapolis had banned the use of violent/adult games, this would clearly be a case of "abridgement" of free speech. However, because this is merely a restriction on its use, similar to MPAA movie ratings, or pornographic materials, this really doesn't present a problem as far as the Constitution is concerned.
Take a peek at the Bill of Rights, and tell me if there is any guarantee against a local government placing "reasonable" restrictions on certain types of speech. I don't think there is any such prohibition.
I think we all need to be a tad more careful when asserting our "Constitutional Rights" to know what exactly the limits of those rights are. We cannot yell "Fire!" in a crowded theater, and in Indianapolis it looks like a 10 year old can't play a violent game. Big deal.
With access to the switch, it is still possible to easily sniff a network (configuring a port to receive all traffic).
A single port on a switch can receive all the traffic sent through that switch? Good luck! Fully populate a Cisco 6509 or an Alcatel Omni9 with 100Mb ports and mirror all the traffic to a single (even Gig-E!) port, and see what happens.
Best bet here would be to monitor the links from the border routers into the colo-center's network. Even then you're talking about a lot of unstructured data to correlate. Bayesian statistics/logic anyone?
Hmm... The switch hardware I've dealt with (Alcatel, Bay, Cisco) doesn't work quite the way it's being described here. Because a switch operates by setting up point to point virtual circuits between ports based on its VLAN rules, simply hanging a sniffer off of one will not allow you to "see" all the traffic going through it. You have to specifically configure it to mirror all the traffic on a particular port to the port with the sniffer. On a busy switch (>50% utilization) and a fast link (100Mbps or faster) this can kill the performance of an entire switch.
The preferred method of course, is to plug a dumb hub into the switch, and then plug the device to be "sniffed" and the sniffer into the hub. This is how some of the IDSs (Intrusion Detection Systems - IBM's HAXOR, ISS's RealSecure, etc.) work. Basically, you need to have the sniffer or IDS on the same physical ethernet segment as the traffic to be monitored.
Slashdot Mirror
Here's the details on the MQ-8: http://www.designation-systems.net/dusrm/app2/q-8. html
It doesn't solve the problem because the poster has two stated goals:
License (under and Open Source License) the Framework which he/she developed. This is a separate, stand-alone, piece of software.
Provide development for a company which uses his Framework, while at the same time performing additional development on the Framework.
The problem is that part of his assigned duties to the company will be to provide further development on the Framework. So how do you decide that an enhancement, which could be re-used by others using the Framework, is put into the Framework code rather than being retained by the company as a proprietary part of their application? It's not a clear delineation.
dual licensin
I think we're missing the point. The question is not how to license the same code in two ways, it's how to differentiate between framework code and application code.
How does one define the difference between a framework (i.e. Jakarta Struts), and an application written with that framework? If there are enhancements made to the framework to satisfy issues related to or which directly impact the employer's application, where does that code lie?
http://www.nokia.com/securitysolutions/management/ ssh.html
Netperf works well for this sort of thing.
How does a troll foot taste, anyhow? :-)
Need an example. Ok, check out Transmeta. The seemed to find a way to use a fraction of the power of an X86 chip, run the same apps, and perform better with a lower clock speed. PowerPC (used by IBM and Apple, duh!) chips do the same thing, only without the X86 compatibility.
Everyone, repeat after me: CISC is DEAD!
Take a peek at the Bill of Rights, and tell me if there is any guarantee against a local government placing "reasonable" restrictions on certain types of speech. I don't think there is any such prohibition.
I think we all need to be a tad more careful when asserting our "Constitutional Rights" to know what exactly the limits of those rights are. We cannot yell "Fire!" in a crowded theater, and in Indianapolis it looks like a 10 year old can't play a violent game. Big deal.
A single port on a switch can receive all the traffic sent through that switch? Good luck! Fully populate a Cisco 6509 or an Alcatel Omni9 with 100Mb ports and mirror all the traffic to a single (even Gig-E!) port, and see what happens.
Best bet here would be to monitor the links from the border routers into the colo-center's network. Even then you're talking about a lot of unstructured data to correlate. Bayesian statistics/logic anyone?
Hmm... The switch hardware I've dealt with (Alcatel, Bay, Cisco) doesn't work quite the way it's being described here. Because a switch operates by setting up point to point virtual circuits between ports based on its VLAN rules, simply hanging a sniffer off of one will not allow you to "see" all the traffic going through it. You have to specifically configure it to mirror all the traffic on a particular port to the port with the sniffer. On a busy switch (>50% utilization) and a fast link (100Mbps or faster) this can kill the performance of an entire switch.
The preferred method of course, is to plug a dumb hub into the switch, and then plug the device to be "sniffed" and the sniffer into the hub. This is how some of the IDSs (Intrusion Detection Systems - IBM's HAXOR, ISS's RealSecure, etc.) work. Basically, you need to have the sniffer or IDS on the same physical ethernet segment as the traffic to be monitored.