1 line of logging per 200 lines of code is way too much. 2 in 5 lines is absolutely insane. I've seen way too many systems where the logging made it totally unusable. People just don't realize the costs of logging everything.
There's absolutely no way to document anything this verbose. Without documentation, the logging is useless.
If they ship the actual source code with each product they ship you are correct, although customers are allowed to redistribute the code under the terms of the GPL. this can be tedious to have 100% compliance with, however, since you have to do it even for patches you send out. ANY time you ship a binary, you also have to ship the source.
If they are accompanying the software with a written offer, it must be valid for ANY THIRD PARTY to obtain the source code.
What has often been claimed is that you can ship a binary and then only give out source to that when your customers ask for it. That's not what the GPL says. Either ship the code and binaries together and have no further obligation to the customer or anybody else. *OR* ship the binary with the offer to provide the code to any third party that asks for it.
While the answer varies from state to state, I'll quote what my lawyer told me when I took him one of these employment agreements. "Warner, never hesitate to sign a vague, badly drafted employment agreement." Basically, for my situation, the upshot was that the agreement was so vague as to what it covered that read literally one would have to tell the company everything I ever thought. New idea for a flavoring for brownies, tell the company. New sexual position to try with the wife, tell the company. Plot for a sitcom staring 13th century spanish cardinals talking about the philosophical conundrum the Islamic occupation of the Iberian peninsula presented, tell the company. Clearly, no court in its right mind would enforce such an over-reaching and broad contract.
In addition, certain states, such as California, have laws that say, as a matter of public policy, that if you do something on your own time with your own resources, you own it.
Also, since you didn't post the entire agreement, there's no way to know if there's anything else in it that might be bad, or worse than what's presented here.
However, without having both a license to practice law, or the entire text of the document in question, the above is prelude to the following non-legal advice: See a lawyer. It cost me about $300 when I needed to get a couple of different documents reviewed.
I've use perforce to keep a private FreeBSD branch for about 6 years now. It just works. I've done enough commits that come from that branch (and about 6 others) to FreeBSD to stay in the top 5 kernel developers for most of that time. Perforce absolutely rocks in helping to keep me sane.
While it is centralized, one cannot deny that its branch merging tools are about the most powerful out there.
Warner Losh FreeBSD kernel hacker
P.S. This is an abbreviated version of a much longer post to the blog listed in this article.
Does the key itself really have protections under US law? That's what the AACS is claiming, but with recent supreme court rulings that software is not a device, and the copyright law using similar language to describe what is prohibited, maybe similar logic applies: the DMCA doesn't apply to software or discussions about software.
My personal take is that it doesn't even apply to discussions of algorithms, including possible keys. The key, in isolation, is just a bunch of numbers. There's nothing magic about the numbers, unless they are placed into a device that can 'circumvent' the protections.
Aren't there lists of IP addresses by geographical regions (countries?)...
It would be (i would think) simple to null route any packets coming from a country other than the approved one and thus be subject only to local traffic.
While such lists exist, if you had bothered to read the letter he wrote, you'd know that even with a good cisco, importing the lists and filtering on them would require more CPU than the cisco router has. It describes in great detail this, and many other, issues.
Poul-Henning isn't an idoit people. If there was an easy, trivial soltution to the problem, he'd have done it by now. He tried doing the right thing, only to get shot down by bozos at DLINK.
I'd think they could just firewall off just their ntp servers, and only allow certain networks in - their networks. Of course, it wouldn't be open anymore, but with PHBs trolling around like daleks, opening things up the general internet public is getting more and more difficult.
Actually if you had read Poul-Henning's open letter, you'd find the answer to this. This is a service for denmark, and filtering non-danish users is hard.
Anyway, my point is that the guy concentrated more on exposing his problems and demanding payment for his expenses than detailing the problem itself, which would be healthier to his servers, as this would prompt at least some more people to update their routers.
Actually, you haven't read the letter, have you? In it he outlines the problem fairly well. He lists the actual expenses that he's incurred because this bone-headed dlink stunt has cost him a ton of money. He'd be very happy if dlink just said 'ok, we were wrong, here's the fixed firmware, sorry for the hassle'. He does present the 'ntp.dlink.com' solution there.
When corprate customer misbehave and abuse system resources, it costs people actual money. In this case, a lot of money, as well as jeorpodizing a service to the users in denmark that Poul-Henning has been providing to them out of the kindness of his heart. Now to have some evil company come in and abuse that is bad enough. But to paint him as a money grubbing scum is over the top.
I do 5.5miles (about 10km) using standard, off the shelf 2' dishes on top of 10' poles on my and my buddy's roof. I've been doing this for the past 4 or 5 years.
Maybe the idea isn't covered or coverable by a patent. Patents disclose information about an invention in exchange for protection. Maybe the company doesn't want to disclose it at all. Maybe the idea isn't worth the expense of a patent, but would none-the-less help the competition shave some cost from their product.
The mindset isn't about Patents, Copyrights or the like. The mindset is that you disclose at little as possible to others on the theory that secret knowledge is a competitive advantage. A cost analysis doesn't enter into this mindset: it is dogmatic and religious in the strength of this view. It is done because that's how it is done. It isn't right, might not make financial sense, but is one of the reasons why specs aren't released.
Another reason is that if they released the full specs, maybe someone else with a patent would see the techniques used and sue them. If you don't release the specs, that litigant's job is much harder. Maybe the is infringement, maybe not. Maybe the specs imply infringement that isn't there. Who knows. If you don't disclose the documentation to the card, then you don't run these risks. Again, it might not be correct analysis or thinking, or make economic sense.
Again, typically it isn't about rational, analytical behavior. It is about a mindset that says you just don't do this. I don't defend the mindset. I'm just telling you how the world works. Maybe it should work differently:-)
You're telling me that they don't have internal documentation anyway? How do they develop their own drivers, etc?
You've clearly never had to write a driver for hardware that's produced down the hall:-). Usually the hardware designer produces a interface document that tells you what he thinks you should know. Once you have this document, there's usually dozens upon dozens of questions that the software writer has about the device. For smaller operations, these questions usually are verbal or email and never make it back into the original spec. There are times that the specification is wrong, incomplete, missing information, etc. To assume that there's public consumable documentation for every piece of hardware doesn't match my many years of industry experience.
In addition to the cost of producing it, there's other issues. Did the company license some IP for their internal use? If so, can that IP be documented and sent out to third parties? Someone has to check to make sure the relevant legal contracts are followed. Next, did we develop some new and novel way of doing something that's covered by a patent? Is it ours our someone else's. Fear of lawsuits from third parties often drives a company to disclose as little as possible. On the 'simpler' devices, much of the information necessary to write a driver may be novel ways of, for example, encoding something in software that might otherwise be done in hardware. Sometimes these tricks may save lots of money for the hardware company who can sell modems $5 cheaper than their competitors. Why make it easy for them to understand your cleverness?
Finally there's good, old fashioned secrecy. Does Macy's tell Gimble's, as the old (now somewhat dated) adage goes. The idea here is that your competitors should have as difficult a time as inventing something as you did, and any hints or short-cuts that you can give them may eat into your profits. Maybe they make a hardware board that's compatible with your driver, this cutting the cost of their development time since they don't have to do the software. Who knows how this information will come back to bite you.
All of these effects on the bottom line are seen as swamping any increase in hardware/software sales to the open source crowd. Not that they are right about this (or wrong for that matter), just how they think.
The problem, as has been noted, is if you have users that you have secrets you want to keep from. If you do, and you use OpenSSL or any other crypto library that has asymetric cache properties of the 0 bits vs 1 bits, then you should disable HTT.
OpenSSL is reported to be working on a patch that fixes the issues that are raised by this work. It is unknown what other classes of code might be affected.
There's much discussion about other, similar things that one can do with shared cache and speculation about how other cache effects can leak information, so the full impact of this class of attach won't be known for some time.
Acutally it is more subtle than that. Diamanou has the absolute right to sign over his rights to the code he wrote. This is standard ownership agreement. He, of course, does not posess the right to sign over rights belonging to others, nor does the company have the right to assert ownership of those parts that are owned by third parties. Ownership of his rights aren't bound by the GPL, only distribution is. The current owner of the rights, whomever it might be, however is bound by the GPL (or a license that's similar enough to it to be compatable, eg they could distribute it under the GPL but also provide a warantee as an extra cost option) if they distribute the code.
So Diamanou broke no laws here. He didn't say he signed over other people's rights.
Please don't get license and rights confused. The GPL is a license, but does not fundamentally affect copyright of those parts added to it. That copyright, under international treaty, belongs to the person who wrote it. Since this a work with other people's intellectual property in it, that IP must be licensed, and presently is licensed under the GPL (unless the company has gone back to the original authors and gotten a copy under a different license).
In the embedded software space, where real-time interaction between various interrupts means that system design and hard core debugging skills are king, outsourcing, and especially overseas, will never be a factor.
In the real word of hardware/software integration, it usually takes a bit of time between the people that write the drivers for hardware and the hardware designers to get things right. Usually with both H/W and S/W sitting in a room together with some kind of test equiptment to make sure that the hardware is doing the right thing and to find which side of the fence the bugs lie. That's hard to do with a 12-hour phase shift.
It doesn't solve the H1B visa issue, but there are many senior people who make 10x what people in India make for a reason. They are worth their weight in gold because of the time that is saved by others. An excellent debugging person can save boatloads of other people's time that a crappy debugging person would waste. That's what makes the more expensive person cheaper.
I think all this doom and gloom stuff is left over from the heady days of the boom times and the subsequent crash. There may be certain types of jobs that go overseas, but there are many that will stay right here for the forseeable future.
10 years ago people though I was nuts for doing this Unix thing when all the jobs would be in Windows. Yet, I still get calls for more work than I can do from people that need a unix programmer. So the pundants are worth exactly what you pay them for their opinions: nothing:-)
While they were obviously fairly ignorant, it is nice that they thought to ask your permission. I'm a GPL-nut myself (everything I write, essentially, gets released under the GPL) but I have noticed that lots of BSD folks get upset when their code is relicensed by other free software projects.
They have every right to be upset. The BSD license, like most software licenses, does not allow for relicensing. You must ask the legal owner of the copyright(s) on the software if you can change the terms under which it is distributed.
When someone takes BSD code proprietary, they're taking it out of the pool.
They aren't taking it out of the pool. The original, unmodified code is still in the pool for anybody to use as they see fit. Rather than taking something out of the pool, these people are merely failing to put more water into the pool.
Contrast this to a GPLification, where the GPL'd version might (for one reason or another) get more mindshare than the BSD version and eclipse the original, with valuable bugfixes and improvements in plain sight of the original dev and yet completely out of reach for legal reasons.
That is certainly the right of anybody making changes to a BSD license code base. They have every right to ADD the GPL restrictions to their works (but the original BSD license must remain). It is somewhat rude, and ill mannered, however, to make such a change. The folks that wrote the BSD license code wanted to offer maximum flexibility to the licensee. This even includes the flexibiltiy to contaminate with GPL'd code. These contamination can cause a lot of problems because it can sometimes be hard to know that patches posted somewhere to BSD licensed code contain these GPL contaminations. This is a bad thing about both licenses, btw.
Again to reiterate: only the copyright holder can change the license on his/her copyrighted works. In general, derived works can only have additional licenses added (all of which must be obeyed).
the Unix copyrights were never actually transfered from Novell to SCO.
It looks like they weren't transferred. It is an open question if Novell would be required to make such a transfer (although most people think it unlikely).
I wonder if they've thought about integrating their Unix copyrights into their Linux distribution.
Novell could do that. They own they copyright. However, they would have to release the code under the GPL or whatever license is compatible with the GPL and on the files they release. This is fundamentally different than what SCO is doing. Novell would effectively be a first party inserting code into linux, so it is above board.
What SCO is alledging is that their code was taken, without their permission, by IBM (and others) and inserted into Linux. Their claims are about aledged theft of their property since they weren't the ones doing the insertion (they claim, others dispute this, but let's assumet they are right for the sake of argument). That's what makes it fundamentlaly different than Novell doing something: SCO is aldeging it was harmed by third parties doing something bad. If Novell inserted code, as suggested, as suggested, it would be in a much more difficult position given the license that they'd be required to submit it under for inclusion in the kernel (check #1) as well as being in the untenable position of saying "Yes, we gave it away, but others have no rights to use it." Sure, SCO is in that position too (due to their distribution of Linux), and you see how much that's helped them.
One would hope, as a matter of fact, the SCOexpert would be required to show where he found matches.
As a matter of fact SCO did show the evidence. This was enumerated in Sandeep Gupta's deposition. The pointed to pdf file has a table of all the files aledged to be copied from Unix sources, and this deposition specifically states he looked at those also (since his automatic detection program failed to find it) and the evidence of copying failed to apply the normal legal standards (also outlined in the deposition). This is very interesting reading indeed.
Slashdot Mirror
1 line of logging per 200 lines of code is way too much. 2 in 5 lines is absolutely insane. I've seen way too many systems where the logging made it totally unusable. People just don't realize the costs of logging everything.
There's absolutely no way to document anything this verbose. Without documentation, the logging is useless.
Close.
If they ship the actual source code with each product they ship you are correct, although customers are allowed to redistribute the code under the terms of the GPL. this can be tedious to have 100% compliance with, however, since you have to do it even for patches you send out. ANY time you ship a binary, you also have to ship the source.
If they are accompanying the software with a written offer, it must be valid for ANY THIRD PARTY to obtain the source code.
What has often been claimed is that you can ship a binary and then only give out source to that when your customers ask for it. That's not what the GPL says. Either ship the code and binaries together and have no further obligation to the customer or anybody else. *OR* ship the binary with the offer to provide the code to any third party that asks for it.
I wonder if this is related to the following post on the FreeBSD jobs list.
http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+4570+/usr/local/www/db/text/2007/freebsd-jobs/20071209.freebsd-jobs
While the answer varies from state to state, I'll quote what my lawyer told me when I took him one of these employment agreements. "Warner, never hesitate to sign a vague, badly drafted employment agreement." Basically, for my situation, the upshot was that the agreement was so vague as to what it covered that read literally one would have to tell the company everything I ever thought. New idea for a flavoring for brownies, tell the company. New sexual position to try with the wife, tell the company. Plot for a sitcom staring 13th century spanish cardinals talking about the philosophical conundrum the Islamic occupation of the Iberian peninsula presented, tell the company. Clearly, no court in its right mind would enforce such an over-reaching and broad contract.
In addition, certain states, such as California, have laws that say, as a matter of public policy, that if you do something on your own time with your own resources, you own it.
Also, since you didn't post the entire agreement, there's no way to know if there's anything else in it that might be bad, or worse than what's presented here.
However, without having both a license to practice law, or the entire text of the document in question, the above is prelude to the following non-legal advice: See a lawyer. It cost me about $300 when I needed to get a couple of different documents reviewed.
Clearly, there needs to be a warning label:
"DO NOT LOOK INTO LASER WITH REMAINING EYE"
On this device and instructions.
I've use perforce to keep a private FreeBSD branch for about 6 years now. It just works. I've done enough commits that come from that branch (and about 6 others) to FreeBSD to stay in the top 5 kernel developers for most of that time. Perforce absolutely rocks in helping to keep me sane.
While it is centralized, one cannot deny that its branch merging tools are about the most powerful out there.
Warner Losh
FreeBSD kernel hacker
P.S. This is an abbreviated version of a much longer post to the blog listed in this article.
Does the key itself really have protections under US law? That's what the AACS is claiming, but with recent supreme court rulings that software is not a device, and the copyright law using similar language to describe what is prohibited, maybe similar logic applies: the DMCA doesn't apply to software or discussions about software.
My personal take is that it doesn't even apply to discussions of algorithms, including possible keys. The key, in isolation, is just a bunch of numbers. There's nothing magic about the numbers, unless they are placed into a device that can 'circumvent' the protections.
dbx (sic) from 4.2 BSD existed with all this functionality on the VAX 11/750 we had running at New Mexico Tech in the late 1980s.
Clearly, this is a bogus patent.
While such lists exist, if you had bothered to read the letter he wrote, you'd know that even with a good cisco, importing the lists and filtering on them would require more CPU than the cisco router has. It describes in great detail this, and many other, issues.
Poul-Henning isn't an idoit people. If there was an easy, trivial soltution to the problem, he'd have done it by now. He tried doing the right thing, only to get shot down by bozos at DLINK.
Warner
That's impossible. the MAC address is local to the network, so after the first router hop, the MAC address of the originating box is gone.
Actually if you had read Poul-Henning's open letter, you'd find the answer to this. This is a service for denmark, and filtering non-danish users is hard.
sadly this plan would screw other, legitimate users of this service.
Actually, you haven't read the letter, have you? In it he outlines the problem fairly well. He lists the actual expenses that he's incurred because this bone-headed dlink stunt has cost him a ton of money. He'd be very happy if dlink just said 'ok, we were wrong, here's the fixed firmware, sorry for the hassle'. He does present the 'ntp.dlink.com' solution there.
When corprate customer misbehave and abuse system resources, it costs people actual money. In this case, a lot of money, as well as jeorpodizing a service to the users in denmark that Poul-Henning has been providing to them out of the kindness of his heart. Now to have some evil company come in and abuse that is bad enough. But to paint him as a money grubbing scum is over the top.
Warner
I do 5.5miles (about 10km) using standard, off the shelf 2' dishes on top of 10' poles on my and my buddy's roof. I've been doing this for the past 4 or 5 years.
5km, bah.
Maybe the idea isn't covered or coverable by a patent. Patents disclose information about an invention in exchange for protection. Maybe the company doesn't want to disclose it at all. Maybe the idea isn't worth the expense of a patent, but would none-the-less help the competition shave some cost from their product. The mindset isn't about Patents, Copyrights or the like. The mindset is that you disclose at little as possible to others on the theory that secret knowledge is a competitive advantage. A cost analysis doesn't enter into this mindset: it is dogmatic and religious in the strength of this view. It is done because that's how it is done. It isn't right, might not make financial sense, but is one of the reasons why specs aren't released. Another reason is that if they released the full specs, maybe someone else with a patent would see the techniques used and sue them. If you don't release the specs, that litigant's job is much harder. Maybe the is infringement, maybe not. Maybe the specs imply infringement that isn't there. Who knows. If you don't disclose the documentation to the card, then you don't run these risks. Again, it might not be correct analysis or thinking, or make economic sense. Again, typically it isn't about rational, analytical behavior. It is about a mindset that says you just don't do this. I don't defend the mindset. I'm just telling you how the world works. Maybe it should work differently :-)
You've clearly never had to write a driver for hardware that's produced down the hall
In addition to the cost of producing it, there's other issues. Did the company license some IP for their internal use? If so, can that IP be documented and sent out to third parties? Someone has to check to make sure the relevant legal contracts are followed. Next, did we develop some new and novel way of doing something that's covered by a patent? Is it ours our someone else's. Fear of lawsuits from third parties often drives a company to disclose as little as possible. On the 'simpler' devices, much of the information necessary to write a driver may be novel ways of, for example, encoding something in software that might otherwise be done in hardware. Sometimes these tricks may save lots of money for the hardware company who can sell modems $5 cheaper than their competitors. Why make it easy for them to understand your cleverness?
Finally there's good, old fashioned secrecy. Does Macy's tell Gimble's, as the old (now somewhat dated) adage goes. The idea here is that your competitors should have as difficult a time as inventing something as you did, and any hints or short-cuts that you can give them may eat into your profits. Maybe they make a hardware board that's compatible with your driver, this cutting the cost of their development time since they don't have to do the software. Who knows how this information will come back to bite you.
All of these effects on the bottom line are seen as swamping any increase in hardware/software sales to the open source crowd. Not that they are right about this (or wrong for that matter), just how they think.
Warner
The problem, as has been noted, is if you have users that you have secrets you want to keep from. If you do, and you use OpenSSL or any other crypto library that has asymetric cache properties of the 0 bits vs 1 bits, then you should disable HTT.
OpenSSL is reported to be working on a patch that fixes the issues that are raised by this work. It is unknown what other classes of code might be affected.
There's much discussion about other, similar things that one can do with shared cache and speculation about how other cache effects can leak information, so the full impact of this class of attach won't be known for some time.
Soekris boxes have had power over ethernet for some time now. http://www.soekris.com/.
Intel already has the pdf for the article. You can find it on their web site at http://www.intel.com/research/silicon/mooreslaw.ht m
Not as cool as the poster that scanned the original into tiff form, but still a lot easier to deal with than going to the library to see the original.
Acutally it is more subtle than that. Diamanou has the absolute right to sign over his rights to the code he wrote. This is standard ownership agreement. He, of course, does not posess the right to sign over rights belonging to others, nor does the company have the right to assert ownership of those parts that are owned by third parties. Ownership of his rights aren't bound by the GPL, only distribution is. The current owner of the rights, whomever it might be, however is bound by the GPL (or a license that's similar enough to it to be compatable, eg they could distribute it under the GPL but also provide a warantee as an extra cost option) if they distribute the code.
So Diamanou broke no laws here. He didn't say he signed over other people's rights.
Please don't get license and rights confused. The GPL is a license, but does not fundamentally affect copyright of those parts added to it. That copyright, under international treaty, belongs to the person who wrote it. Since this a work with other people's intellectual property in it, that IP must be licensed, and presently is licensed under the GPL (unless the company has gone back to the original authors and gotten a copy under a different license).
In the real word of hardware/software integration, it usually takes a bit of time between the people that write the drivers for hardware and the hardware designers to get things right. Usually with both H/W and S/W sitting in a room together with some kind of test equiptment to make sure that the hardware is doing the right thing and to find which side of the fence the bugs lie. That's hard to do with a 12-hour phase shift.
It doesn't solve the H1B visa issue, but there are many senior people who make 10x what people in India make for a reason. They are worth their weight in gold because of the time that is saved by others. An excellent debugging person can save boatloads of other people's time that a crappy debugging person would waste. That's what makes the more expensive person cheaper.
I think all this doom and gloom stuff is left over from the heady days of the boom times and the subsequent crash. There may be certain types of jobs that go overseas, but there are many that will stay right here for the forseeable future.
10 years ago people though I was nuts for doing this Unix thing when all the jobs would be in Windows. Yet, I still get calls for more work than I can do from people that need a unix programmer. So the pundants are worth exactly what you pay them for their opinions: nothing
They have every right to be upset. The BSD license, like most software licenses, does not allow for relicensing. You must ask the legal owner of the copyright(s) on the software if you can change the terms under which it is distributed.
They aren't taking it out of the pool. The original, unmodified code is still in the pool for anybody to use as they see fit. Rather than taking something out of the pool, these people are merely failing to put more water into the pool.
That is certainly the right of anybody making changes to a BSD license code base. They have every right to ADD the GPL restrictions to their works (but the original BSD license must remain). It is somewhat rude, and ill mannered, however, to make such a change. The folks that wrote the BSD license code wanted to offer maximum flexibility to the licensee. This even includes the flexibiltiy to contaminate with GPL'd code. These contamination can cause a lot of problems because it can sometimes be hard to know that patches posted somewhere to BSD licensed code contain these GPL contaminations. This is a bad thing about both licenses, btw.
Again to reiterate: only the copyright holder can change the license on his/her copyrighted works. In general, derived works can only have additional licenses added (all of which must be obeyed).
It looks like they weren't transferred. It is an open question if Novell would be required to make such a transfer (although most people think it unlikely).
Novell could do that. They own they copyright. However, they would have to release the code under the GPL or whatever license is compatible with the GPL and on the files they release. This is fundamentally different than what SCO is doing. Novell would effectively be a first party inserting code into linux, so it is above board.
What SCO is alledging is that their code was taken, without their permission, by IBM (and others) and inserted into Linux. Their claims are about aledged theft of their property since they weren't the ones doing the insertion (they claim, others dispute this, but let's assumet they are right for the sake of argument). That's what makes it fundamentlaly different than Novell doing something: SCO is aldeging it was harmed by third parties doing something bad. If Novell inserted code, as suggested, as suggested, it would be in a much more difficult position given the license that they'd be required to submit it under for inclusion in the kernel (check #1) as well as being in the untenable position of saying "Yes, we gave it away, but others have no rights to use it." Sure, SCO is in that position too (due to their distribution of Linux), and you see how much that's helped them.
As a matter of fact SCO did show the evidence. This was enumerated in Sandeep Gupta's deposition. The pointed to pdf file has a table of all the files aledged to be copied from Unix sources, and this deposition specifically states he looked at those also (since his automatic detection program failed to find it) and the evidence of copying failed to apply the normal legal standards (also outlined in the deposition). This is very interesting reading indeed.
Can someone post the clause in question, preferably translated into English?