Many FSF/Gnu projects require copyright assignment to the FSF. IE, it's not acceptable to merely release your work under the GPL license to have it included into the main package. The reasons are obvious, it houses all the copyright ownership in a single more defensible place.
But in actuality, I wonder if it'll make a difference. Specifically, I know the FSF requires some documentations from employers to double check the submissions were written with consent of a company that sponsored the work. However, there are problems with how things "really work" in the real world:
1) submission authors are never bugged again in the future to ensure that they aren't working for a new company.
2) many Gnu packages accept small patches without assignment ("if it's less than 6 lines of new code, we'll just apply it"), just not large ones.
The reason I bring this up is that I'm not convinced that the paperwork and bureaucracy overhead even amounts to the level of protection that is needed. It certainly hinders development in many cases as well by slowing down progress with paperwork.
Do you have any comments on the above that will enlighten me into the legal field of copyright assignment (of which I admit I know very little).
Re:Sounds like a modern Rex Stout / Nero Wolfe boo
on
Kiln People
·
· Score: 1
Actually, he seems to leave it in nearly every book I agree. The black mountain was by far the most amazing time he left. (though he tried to join the army in "not quite dead enough".
Sounds like a modern Rex Stout / Nero Wolfe book?
on
Kiln People
·
· Score: 3, Interesting
If you like this book, you might check out some really good 40s and 50s detective books about a detective named Nero Wolfe who never leaves his house. Excellent books.
Yeah, but if you only support moderate positions, you sit squarely in the middle of the Democratic or Republican parties. How do you think they got to where they are today?
Actually, I sit un-aligned. I vote on topics, where possible, and don't vote a single-party line.
It's not good, in my humble opinion of course, to give all your money to a single cause. Absolute power corrupts, and absolute power correpts absolutely.
people misread my statement a bit. I didn't mean to imply that no good comes from extremists. They fight the good cause, in many cases, and are even needed to convince people not to go to the other side. However, they are frequently less productive. I'm not even saying "always" like people think I seem to mean. I'm not declaring that it's imposible to be a perfect extremist. I'm simply saying I haven't seen one yet.
Crap. I totally forgot my other rule: always drink coffee before posting to slashdot. always drink coffee before posting to slashdot. always drink coffee before posting to slashdot.always drink coffee before posting to slashdot.
Extremists are almost always idealistic in some way. In this case, we have MS at one side of an extreme and RMS at the other. MS wants all your money, RMS wants no one to have any. I'm much in thinking to the RMS way, but even he has spent his energy (and thus part of the money which has been given to him) in ways that I think are insane.
Lets take an example: The legal paperwork required to submit code to any Emacs related project. In principal, it's a good idea, but I strongly doubt that the energy to maintain that ideal is worth the end gain. I suspect that if it came to a trial, you'd find that they couldn't prove they had assignment rights for everyone that has submitted code. (In fact, the guidelines for accepting a patch is something like "well, if it has less than 6 lines of code changed then we can accept it without paperwork", which alone will cause problems). So, in the end I suspect this whole policy has actually just slowed down the progress of their coding force rather than really helped "get things done".
Any idealist is likely to actually impeed progress in some way. Certainly M$ is doing an excellent job shooting other people's feet, and we can all agree on that. But, I suggest that RMS is actually doing similar things some of the time as well.
So my rule of thumb: Don't support the idealists. I don't give M$ any money, and I'm not sure I want RMS to spend all my money barking up a tree just because he thinks a dog might some day be up there.
Ok, it's 6:00 and I haven't had any coffee yet. For the moderators out there: this really wasn't intended to be flamebait. I wonder if it'll hold.
Breaking things is not fixing the problem.
on
As the Spam Turns
·
· Score: 3, Insightful
Spam blocking has been around for ages. Blocking broken mail servers has been around for ages. Apparently, it's not working as my mail box still contains a lot of spam.
We need a new solution folks, and blocking large portions of the net will not fix the problem. If you want to make *all* spam to go away, you need a different form of a solution because you can't block everyone who might want to legitimately talk to you. This decision will certainly block a whole slew of legitimate users from speaking with each other.
I'm thinking SMTP needs to be entirely rethought. Unfortunately, this isn't practical either as it'll have the same effect as deliberate breakage during the transition. (hence the reason we don't have ipv6 yet either).
Wouldn't something like this easily fall into it? It'd be interesting to do a study to see if people responded to stuff transmitted just on the fringe of their hearing range.
This kinda scares me a bit. I feel the sudden urge to rm -rf/; insert microsoft XP CD.
You wouldn't want to have an accident, would ya COLONEL? Accidents happen, COLONEL! You wouldn't want something to happen to all those tanks, would ya COLONEL?
Yeah, but it would be ugly to write (making sure no duplicates, trying to make sure that we hadn't already solved it in versions that are beyond their released version, yadadada)
Actually, if bugzilla just had the ability to send out mail for any bugs in the system for a given package, that would be very benificial. I want to track everything in "this" package kind of thing. (It has the ability to track individual bugs, but not every bug in a package).
I'm the lead developer of the net-snmp package and let me give you my 2 cents on the subject from a first hand view:
Distributions do a great job redistributing stuff, but don't do a great job working with the package authors themselves. The net-snmp package is an extremely hard one to maintain, for we support a really large number of operating systems for code which is very operating system sensitive (the architecture ifdefs in some portions of the code will drive you mad. Trust me.) net-snmp is redistrubuted through a number of distributions, and let me tell you that almost no bug reports get to us that are entered into distribution bug tracking databases. It's a nightmare, and because we can't continously search other bug databases for problems, we frequently are left out.
To make matters worse, the distributions often fix things. RedHat and other RPM packages simply roll their own patches into their redistribution and don't send it to us. FreeBSD has a ports tree that contains patches for projects that the projects themselves may have never seen.
I'll never forget the first time I opend the source rpm of the net-snmp package from redhat. There were 3 patches in it that I had never seen for bugs I didn't even know about. Why hadn't I heard of them? because the RedHat package maintainers didn't notify us that they had fixed something.
Finally, what's even worse is that all of the RedHat source RPMs are GPLed. Our package uses a BSD license and thus we can't pull the patches out of the RPMs and apply them to our source without getting explicit permission to re-license it.
The proper thing to do would be to probably search freshmeat for the project page and look at the documentation. Maybe submit it to both the package maintainer and to distribution maintainer if you really have the time (ha!).
My personal plea to the distribution maintainers: help the package authors out! Please!
You'll be glad to know that the Cerberus/PlutoPlus implementations done by NIST are going to be more widely available in the near future. Specifically, I've been working on extending them to support large-scale configuration management of it. I ported the cerberus (read: ipsec) support to the 2.4 kernel, and am wrapping up the final details at the moment. The good news about it is that it's not done in the hacky way that freeswan did stuff. I'll be creating a sourceforge project for it within the week (I have a deadline to do it by next week), so look for it shortly.
I actually tried to approach the FreeSWAN folk to considering instrumenting their code with our policy-role-based configuration management support infrastructure, but they said "no US no way" and I didn't really have a choice if I wanted my patches rolled back into the project. The Cerberus and PlutoPlus developers, on the other hand, have been much more polite and helpful.
yes, change is hard. they know it and don't want to do it. People that require unsecure protocols probably deserve what they get. But the solution is not necessarily to turn it off if they want it. It's to upgrade instead.
Well, the sad thing is that you'd think SANS would have gotten it right. At least checked it with people who knew something. They're just one of those organizations that I thought I could trust. Which means, most other people also think they can trust them.
Which, um, I guess means "trust no one, mannnnnn".
Here's a note I just sent to their web master (they had no other place to send "comments"):
Overall the top20 list is a good summary as always.
However, I can't believe the lack of knowledge about at least the SNMP portion of it. SNMP *used to use* clear-text community strings in the first and second versions of the protocols. The following statement, along with others in the section:
'SNMP uses an unencrypted "community string" as its only authentication mechanism. Lack of encryption is bad enough...'
Is spreading simply incomplete information. At a minimum, it should be suggested that all users upgrade their SNMP enabled software to version 3 compliant SNMP agents and to disable the version 1 and version 2 SNMP protocols. All of the major network vendors, as well as software vendors implement the v3 protocol so there is very little excuse for not using it (and, worst case you can deploy v3->v1 proxies near v1-devices to minimize the transmision distance of clear-text v1 community strings). *Please* change the wording to suggest that people upgrade their equipment to SNMPv3 compliant software, which will take care of at least the insecure problems with the protocol.
I'm sorry, but you'll simply have to downgrade your OS before donating it. I'm going to go donate a machine today and remove windows and put back on the original DOS I guess. The schools will like that better, according to Microsoft.
Or maybe I'll go donate a machine and put OS/2 back on it instead of windows.
Disclaimer: the author doesn't actually have a machine that ever had DOS or OS/2 installed.
The first time I looked into a redhat distribution, I was amazed to see 3 patches I'd never seen before. Since then I've tried to make it a point to check what the maintainers there have done every once in a while.
On a side note, the redhat bug database really needs a way for me to be able to say "send me mail for any problem from package X". Sure, you can subscribe to a particular bug, but I need to subscribe to an entire package. Last I checked, this isn't possible. It would certainly be an easier way to help keep package authors in sync with the distribution packagers.
I have no doubt that some maintainers are only interested in platform X. However, in my case at least, that's not true at all (since we advertise it as being supprted on FreeBSD, etc). Typically the only changes I ever reject are ones which break other architectures due to impropeer ifdeffing. That's a whole other problem, actually. Most people really aren't expereienced in writing portable code.
This hardly applies to just the kernel!
on
Missing Kernel Patches
·
· Score: 3, Insightful
As a maintainer of a package which is distributed via many linux and *BSD distributions, I'd like to complain on the behalf of software authors everywhere. The linux distributions are nutoriously bad about applying patches to their rpms (say) but never submitting them back to the authors of the package themselves. The BSD distributions are just as bad. The infamous FreeBSD port tree also frequently houses patches that never make their way back to developers.
I'm not sure how this could ever be considered a good thing, as the project authors must spend time searching through distribution source releases looking for patches, which takes time. The distributions must continually apply their patch to a changing source tree (and I'm sure it'll eventually break and need reworking), so they loose time as well. This is one case where communication really could be a very positive thing.
sigh... It's about time I went to search for patches again...
Probably. I'd actually bet they only tested one version and didn't test 4.2.2 (which would have told them it was safe). It's easier to just say "4.2.3 is safe" and not test the rest of the versions.
Actually, that's not true. Of a survey I recently took of SNMP users, 33% did use SNMPv3 and what's even better is that 15% of the total didn't use v1 at all.
People are beginning to use v3 as the product vendors are beginning to ship it in the majority of the products. Unfortunately, it's still not "all", as you well know.
(and as for dnssec, the reason it can't be used effectively now is that verisign won't let it be used because they refuse to sign the.com/.org/.net roots)
No standardized version of SNMPv2 contains security either. Only SNMPv3 has security.
Note: there were some defined versions of SNMPv2 that never made it very far through the standards process. These were snmpv2*, snmpv2c, snmp2p,... They have never been deployed and though they might have been secure they really shouldn't be called SNMPv2.
Slashdot Mirror
Many FSF/Gnu projects require copyright assignment to the FSF. IE, it's not acceptable to merely release your work under the GPL license to have it included into the main package. The reasons are obvious, it houses all the copyright ownership in a single more defensible place.
But in actuality, I wonder if it'll make a difference. Specifically, I know the FSF requires some documentations from employers to double check the submissions were written with consent of a company that sponsored the work. However, there are problems with how things "really work" in the real world:
1) submission authors are never bugged again in the future to ensure that they aren't working for a new company.
2) many Gnu packages accept small patches without assignment ("if it's less than 6 lines of new code, we'll just apply it"), just not large ones.
The reason I bring this up is that I'm not convinced that the paperwork and bureaucracy overhead even amounts to the level of protection that is needed. It certainly hinders development in many cases as well by slowing down progress with paperwork.
Do you have any comments on the above that will enlighten me into the legal field of copyright assignment (of which I admit I know very little).
Actually, he seems to leave it in nearly every book I agree. The black mountain was by far the most amazing time he left. (though he tried to join the army in "not quite dead enough".
If you like this book, you might check out some really good 40s and 50s detective books about a detective named Nero Wolfe who never leaves his house. Excellent books.
Actually, I sit un-aligned. I vote on topics, where possible, and don't vote a single-party line.
It's not good, in my humble opinion of course, to give all your money to a single cause. Absolute power corrupts, and absolute power correpts absolutely.
people misread my statement a bit. I didn't mean to imply that no good comes from extremists. They fight the good cause, in many cases, and are even needed to convince people not to go to the other side. However, they are frequently less productive. I'm not even saying "always" like people think I seem to mean. I'm not declaring that it's imposible to be a perfect extremist. I'm simply saying I haven't seen one yet.
Crap. I totally forgot my other rule: always drink coffee before posting to slashdot. always drink coffee before posting to slashdot. always drink coffee before posting to slashdot.always drink coffee before posting to slashdot.
Extremists are almost always idealistic in some way. In this case, we have MS at one side of an extreme and RMS at the other. MS wants all your money, RMS wants no one to have any. I'm much in thinking to the RMS way, but even he has spent his energy (and thus part of the money which has been given to him) in ways that I think are insane.
Lets take an example: The legal paperwork required to submit code to any Emacs related project. In principal, it's a good idea, but I strongly doubt that the energy to maintain that ideal is worth the end gain. I suspect that if it came to a trial, you'd find that they couldn't prove they had assignment rights for everyone that has submitted code. (In fact, the guidelines for accepting a patch is something like "well, if it has less than 6 lines of code changed then we can accept it without paperwork", which alone will cause problems). So, in the end I suspect this whole policy has actually just slowed down the progress of their coding force rather than really helped "get things done".
Any idealist is likely to actually impeed progress in some way. Certainly M$ is doing an excellent job shooting other people's feet, and we can all agree on that. But, I suggest that RMS is actually doing similar things some of the time as well.
So my rule of thumb: Don't support the idealists. I don't give M$ any money, and I'm not sure I want RMS to spend all my money barking up a tree just because he thinks a dog might some day be up there.
Ok, it's 6:00 and I haven't had any coffee yet. For the moderators out there: this really wasn't intended to be flamebait. I wonder if it'll hold.
Spam blocking has been around for ages. Blocking broken mail servers has been around for ages. Apparently, it's not working as my mail box still contains a lot of spam.
We need a new solution folks, and blocking large portions of the net will not fix the problem. If you want to make *all* spam to go away, you need a different form of a solution because you can't block everyone who might want to legitimately talk to you. This decision will certainly block a whole slew of legitimate users from speaking with each other.
I'm thinking SMTP needs to be entirely rethought. Unfortunately, this isn't practical either as it'll have the same effect as deliberate breakage during the transition. (hence the reason we don't have ipv6 yet either).
Wouldn't something like this easily fall into it? It'd be interesting to do a study to see if people responded to stuff transmitted just on the fringe of their hearing range.
/; insert microsoft XP CD.
This kinda scares me a bit. I feel the sudden urge to rm -rf
You wouldn't want to have an accident, would ya COLONEL? Accidents happen, COLONEL! You wouldn't want something to happen to all those tanks, would ya COLONEL?
Yeah, but it would be ugly to write (making sure no duplicates, trying to make sure that we hadn't already solved it in versions that are beyond their released version, yadadada)
Actually, if bugzilla just had the ability to send out mail for any bugs in the system for a given package, that would be very benificial. I want to track everything in "this" package kind of thing. (It has the ability to track individual bugs, but not every bug in a package).
Distributions do a great job redistributing stuff, but don't do a great job working with the package authors themselves. The net-snmp package is an extremely hard one to maintain, for we support a really large number of operating systems for code which is very operating system sensitive (the architecture ifdefs in some portions of the code will drive you mad. Trust me.) net-snmp is redistrubuted through a number of distributions, and let me tell you that almost no bug reports get to us that are entered into distribution bug tracking databases. It's a nightmare, and because we can't continously search other bug databases for problems, we frequently are left out.
To make matters worse, the distributions often fix things. RedHat and other RPM packages simply roll their own patches into their redistribution and don't send it to us. FreeBSD has a ports tree that contains patches for projects that the projects themselves may have never seen.
I'll never forget the first time I opend the source rpm of the net-snmp package from redhat. There were 3 patches in it that I had never seen for bugs I didn't even know about. Why hadn't I heard of them? because the RedHat package maintainers didn't notify us that they had fixed something.
Finally, what's even worse is that all of the RedHat source RPMs are GPLed. Our package uses a BSD license and thus we can't pull the patches out of the RPMs and apply them to our source without getting explicit permission to re-license it.
The proper thing to do would be to probably search freshmeat for the project page and look at the documentation. Maybe submit it to both the package maintainer and to distribution maintainer if you really have the time (ha!).
My personal plea to the distribution maintainers: help the package authors out! Please!
AgentX is actually an IETF sub-agent protocol for use with SNMP. Though no longer officially on the List of currently active working groups, it's fairly widely used.
You'll be glad to know that the Cerberus/PlutoPlus implementations done by NIST are going to be more widely available in the near future. Specifically, I've been working on extending them to support large-scale configuration management of it. I ported the cerberus (read: ipsec) support to the 2.4 kernel, and am wrapping up the final details at the moment. The good news about it is that it's not done in the hacky way that freeswan did stuff. I'll be creating a sourceforge project for it within the week (I have a deadline to do it by next week), so look for it shortly.
I actually tried to approach the FreeSWAN folk to considering instrumenting their code with our policy-role-based configuration management support infrastructure, but they said "no US no way" and I didn't really have a choice if I wanted my patches rolled back into the project. The Cerberus and PlutoPlus developers, on the other hand, have been much more polite and helpful.
yes, change is hard. they know it and don't want to do it. People that require unsecure protocols probably deserve what they get. But the solution is not necessarily to turn it off if they want it. It's to upgrade instead.
Well, the sad thing is that you'd think SANS would have gotten it right. At least checked it with people who knew something. They're just one of those organizations that I thought I could trust. Which means, most other people also think they can trust them.
Which, um, I guess means "trust no one, mannnnnn".
Here's a note I just sent to their web master (they had no other place to send "comments"):
Overall the top20 list is a good summary as always.
However, I can't believe the lack of knowledge about at least the SNMP portion of it. SNMP *used to use* clear-text community strings in the first and second versions of the protocols. The following statement, along with others in the section:
'SNMP uses an unencrypted "community string" as its only authentication mechanism. Lack of encryption is bad enough...'
Is spreading simply incomplete information. At a minimum, it should be suggested that all users upgrade their SNMP enabled software to version 3 compliant SNMP agents and to disable the version 1 and version 2 SNMP protocols. All of the major network vendors, as well as software vendors implement the v3 protocol so there is very little excuse for not using it (and, worst case you can deploy v3->v1 proxies near v1-devices to minimize the transmision distance of clear-text v1 community strings). *Please* change the wording to suggest that people upgrade their equipment to SNMPv3 compliant software, which will take care of at least the insecure problems with the protocol.
I'm sorry, but you'll simply have to downgrade your OS before donating it. I'm going to go donate a machine today and remove windows and put back on the original DOS I guess. The schools will like that better, according to Microsoft.
Or maybe I'll go donate a machine and put OS/2 back on it instead of windows.
Disclaimer: the author doesn't actually have a machine that ever had DOS or OS/2 installed.
I really didn't think the Coyboyneal Big Diaper/Toilet Paper Act was something that should be passed by congress.
The first time I looked into a redhat distribution, I was amazed to see 3 patches I'd never seen before. Since then I've tried to make it a point to check what the maintainers there have done every once in a while.
On a side note, the redhat bug database really needs a way for me to be able to say "send me mail for any problem from package X". Sure, you can subscribe to a particular bug, but I need to subscribe to an entire package. Last I checked, this isn't possible. It would certainly be an easier way to help keep package authors in sync with the distribution packagers.
I have no doubt that some maintainers are only interested in platform X. However, in my case at least, that's not true at all (since we advertise it as being supprted on FreeBSD, etc). Typically the only changes I ever reject are ones which break other architectures due to impropeer ifdeffing. That's a whole other problem, actually. Most people really aren't expereienced in writing portable code.
As a maintainer of a package which is distributed via many linux and *BSD distributions, I'd like to complain on the behalf of software authors everywhere. The linux distributions are nutoriously bad about applying patches to their rpms (say) but never submitting them back to the authors of the package themselves. The BSD distributions are just as bad. The infamous FreeBSD port tree also frequently houses patches that never make their way back to developers.
I'm not sure how this could ever be considered a good thing, as the project authors must spend time searching through distribution source releases looking for patches, which takes time. The distributions must continually apply their patch to a changing source tree (and I'm sure it'll eventually break and need reworking), so they loose time as well. This is one case where communication really could be a very positive thing.
sigh... It's about time I went to search for patches again...
Probably. I'd actually bet they only tested one version and didn't test 4.2.2 (which would have told them it was safe). It's easier to just say "4.2.3 is safe" and not test the rest of the versions.
ucd-snmp 4.2.2 is not vulnerable, unless the OpenBSD packaging of it is broken. See the vendor statement for net-snmp.
Actually, that's not true. Of a survey I recently took of SNMP users, 33% did use SNMPv3 and what's even better is that 15% of the total didn't use v1 at all.
.com/.org/.net roots)
People are beginning to use v3 as the product vendors are beginning to ship it in the majority of the products. Unfortunately, it's still not "all", as you well know.
(and as for dnssec, the reason it can't be used effectively now is that verisign won't let it be used because they refuse to sign the
No standardized version of SNMPv2 contains security either. Only SNMPv3 has security.
... They have never been deployed and though they might have been secure they really shouldn't be called SNMPv2.
Note: there were some defined versions of SNMPv2 that never made it very far through the standards process. These were snmpv2*, snmpv2c, snmp2p,