Slashdot Mirror

Alan Robertson, who maintains the heartbeat package and works for IBM, recently posted to the ha-linux list on this subject.

Alan does not accept patches to the heartbeat code that were developed on company time unless he receives a disclaimer from somebody at the company.

This is obviously spoofable, but it's probably a good way to legally protect the code -- Alan can honestly say he received it in good faith, which keeps IBM's lawyers' from breathing down his neck. It's kind of weird for me, though, I have to send a disclaimer giving myself permission to send in a patch....

So, to answer your question: explain to your CEO why helping the OSS community helps you to help your company, and get her/him to sign off on a policy that allows you to do so. Ask for legal authority to be delegated to yourself (or your boss) to license or assign corporate intellectual property to open-source projects. Then have HR propagate the policy to your co-workers.

I was pretty shocked by next article that an OpenBSD-user showed me. (I'm a Linux user, thank you). You can read it here.

From: Theo de Raadt
comp.unix.bsd.openbsd.misc

...

> I'm just
> curious to know if anyone has broken into an open source system because it
> was open source.

Linux is the best example of this, there are many examples. As the
system being attacked, that is -- even if their source was not being
analyzed earlier. Funny thing is, (especially around two years ago)
it was a case of _us_ finding the holes, fixing them in OpenBSD,
telling the BUGTRAQ mailing list, and then crackers writing exploits
and using them on _other_ operating systems. (I guess that is
distributed and applied ;-)

Sometimes, as in the case of the recent RedHat lpd security report,
years elapse. Let's look closer at what happened:

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947550717304 74&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947310141065 60&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947552011315 70&w=2

And then read

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947699382089 89&w=2

And pay special attention to the original bug report. That's October
of '97.

http://www.nai.com/ nai_labs/asp_set/advisory/20_bsd_lpd_adv.asp

I was pretty shocked by next article that an OpenBSD-user showed me. (I'm a Linux user, thank you). You can read it here.

From: Theo de Raadt
comp.unix.bsd.openbsd.misc

...

> I'm just
> curious to know if anyone has broken into an open source system because it
> was open source.

Linux is the best example of this, there are many examples. As the
system being attacked, that is -- even if their source was not being
analyzed earlier. Funny thing is, (especially around two years ago)
it was a case of _us_ finding the holes, fixing them in OpenBSD,
telling the BUGTRAQ mailing list, and then crackers writing exploits
and using them on _other_ operating systems. (I guess that is
distributed and applied ;-)

Sometimes, as in the case of the recent RedHat lpd security report,
years elapse. Let's look closer at what happened:

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947550717304 74&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947310141065 60&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947552011315 70&w=2

And then read

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947699382089 89&w=2

And pay special attention to the original bug report. That's October
of '97.

http://www.nai.com/ nai_labs/asp_set/advisory/20_bsd_lpd_adv.asp

I was pretty shocked by next article that an OpenBSD-user showed me. (I'm a Linux user, thank you). You can read it here.

From: Theo de Raadt
comp.unix.bsd.openbsd.misc

...

> I'm just
> curious to know if anyone has broken into an open source system because it
> was open source.

Linux is the best example of this, there are many examples. As the
system being attacked, that is -- even if their source was not being
analyzed earlier. Funny thing is, (especially around two years ago)
it was a case of _us_ finding the holes, fixing them in OpenBSD,
telling the BUGTRAQ mailing list, and then crackers writing exploits
and using them on _other_ operating systems. (I guess that is
distributed and applied ;-)

Sometimes, as in the case of the recent RedHat lpd security report,
years elapse. Let's look closer at what happened:

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947550717304 74&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947310141065 60&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947552011315 70&w=2

And then read

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947699382089 89&w=2

And pay special attention to the original bug report. That's October
of '97.

http://www.nai.com/ nai_labs/asp_set/advisory/20_bsd_lpd_adv.asp

I was pretty shocked by next article that an OpenBSD-user showed me. (I'm a Linux user, thank you). You can read it here.

From: Theo de Raadt
comp.unix.bsd.openbsd.misc

...

> I'm just
> curious to know if anyone has broken into an open source system because it
> was open source.

Linux is the best example of this, there are many examples. As the
system being attacked, that is -- even if their source was not being
analyzed earlier. Funny thing is, (especially around two years ago)
it was a case of _us_ finding the holes, fixing them in OpenBSD,
telling the BUGTRAQ mailing list, and then crackers writing exploits
and using them on _other_ operating systems. (I guess that is
distributed and applied ;-)

Sometimes, as in the case of the recent RedHat lpd security report,
years elapse. Let's look closer at what happened:

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947550717304 74&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947310141065 60&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947552011315 70&w=2

And then read

http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947699382089 89&w=2

And pay special attention to the original bug report. That's October
of '97.

http://www.nai.com/ nai_labs/asp_set/advisory/20_bsd_lpd_adv.asp

sockfs was developed for Linux in the 2.0.x days. Sadly it didn't seem to ever build a great deal of momentum, and I don't think Malcolm has bothered to port it to 2.2/2.3 (and release it publically), although he did give hints more than once on l-k about how easy it would be to do so.

You can read various discussions of sockfs by searching any linux-kernel mailing list archive -- here's a URL to get started:

<ShamelessPlug>
http://www .progressive-comp.com/Lists/?l=linux-kernel&r=1&s= sockfs&q=b&w=2
</ShamelessPlug>

Hank Leininger

See recent posts on linux-kernel by Jeff Merkey. Basically, there's a private firm of ex-Novell employees (the good people who all quit--Merkey wrote Novell's SMP kernel, for example) who are implementing Netware file system support (GPLed for Linux, sold to Microsoft to be in Service Pack #1 of Windows 2k). Now that that's done, they're moving on to NDS.

When the Timpanogas Group gets those two items finished, there will be no reason in the world why you can't instantly migrate any Novell setup to Linux or NT. And, there will be lots of reasons to do it....

Obviously, Novell is scared shitless over all this. They've fought Timpanogas in court, and lost, so now they're trying to FUD to stall public acceptance of the Timpanogas Group code--why run TRG NDS when you can allegedly wait 6 months for the "real thing" from Novell? Of course, if you wait for the code from Novell, you're going to wind up waiting for Godot....

See, for example, this post of leaked internal Novell discussions.

Any idea how it compares in scope? From looking at the sites, Zope appears to be a MUCH larger project than Midgard.

Which one is better depends greatly on your viewpoint. If you like Python, Zope is probably what you'll want to use. Otherwise, it might also be Midgard.

The projects have a quite different focus and I believe there will be enough room for both.

Jukka Zitting's take on the matter can be found from Midgard's mailing list archives. The comment is from few days after Midgard 1.0 was released, and our situation has improved much after that.

Of course, it depends mostly about what kind of Web application serving or development needs you have.

/Bergie

--

The GPL already covers translations because they are derivative works of the original. - RMS

I now understand CORBA much more than before, and my conclusion is that people who want to make proprietary programs talk with your objects have a lawful way do so, no matter what licenses you use.

The license for the IDL file cannot stop this in an enforcible way. Since there is only one way to write a valid IDL description of any given protocol, people are allowed to use the same IDL description, so you cannot really enforce the copyright on it. And if one ORB does not let them use the generated library in non-free software, they can use some other ORB. I am sure there are some ORBs (perhaps proprietary, but these people won't mind that) which permit it.

However, using the GPL on IDL files might have a substantial practical effect even if it isn't legally airtight. It might discourage much proprietary software from being written to talk to your objects, and it might convince many of the people who write programs that use your objects to make their programs free.

If a substantial amount of code in the ORB is copied into the output, then the output is also a derivative work of the ORB, and covered by the copyright on the ORB. Of course, this only covers the output made by that particular ORB. I presume that you can use the same IDL file with another ORB, and then you will get a library which might be derivative of the other ORB, but is certainly not a derivative of the first ORB.

More information can be found at http://w ww.progressive-comp.com/Lists/?l=berlin-design&r=1 &w=2#berlin-design

The GPL already covers translations because they are derivative works of the original. - RMS

I now understand CORBA much more than before, and my conclusion is that people who want to make proprietary programs talk with your objects have a lawful way do so, no matter what licenses you use.

The license for the IDL file cannot stop this in an enforcible way. Since there is only one way to write a valid IDL description of any given protocol, people are allowed to use the same IDL description, so you cannot really enforce the copyright on it. And if one ORB does not let them use the generated library in non-free software, they can use some other ORB. I am sure there are some ORBs (perhaps proprietary, but these people won't mind that) which permit it.

However, using the GPL on IDL files might have a substantial practical effect even if it isn't legally airtight. It might discourage much proprietary software from being written to talk to your objects, and it might convince many of the people who write programs that use your objects to make their programs free.

If a substantial amount of code in the ORB is copied into the output, then the output is also a derivative work of the ORB, and covered by the copyright on the ORB. Of course, this only covers the output made by that particular ORB. I presume that you can use the same IDL file with another ORB, and then you will get a library which might be derivative of the other ORB, but is certainly not a derivative of the first ORB.

More information can be found at http://w ww.progressive-comp.com/Lists/?l=berlin-design&r=1 &w=2#berlin-design

The GPL already covers translations because they are derivative works of the original. - RMS

I now understand CORBA much more than before, and my conclusion is that people who want to make proprietary programs talk with your objects have a lawful way do so, no matter what licenses you use.

The license for the IDL file cannot stop this in an enforcible way. Since there is only one way to write a valid IDL description of any given protocol, people are allowed to use the same IDL description, so you cannot really enforce the copyright on it. And if one ORB does not let them use the generated library in non-free software, they can use some other ORB. I am sure there are some ORBs (perhaps proprietary, but these people won't mind that) which permit it.

However, using the GPL on IDL files might have a substantial practical effect even if it isn't legally airtight. It might discourage much proprietary software from being written to talk to your objects, and it might convince many of the people who write programs that use your objects to make their programs free.

If a substantial amount of code in the ORB is copied into the output, then the output is also a derivative work of the ORB, and covered by the copyright on the ORB. Of course, this only covers the output made by that particular ORB. I presume that you can use the same IDL file with another ORB, and then you will get a library which might be derivative of the other ORB, but is certainly not a derivative of the first ORB.

More information can be found at http://w ww.progressive-comp.com/Lists/?l=berlin-design&r=1 &w=2#berlin-design

The GPL already covers translations because they are derivative works of the original. - RMS

I now understand CORBA much more than before, and my conclusion is that people who want to make proprietary programs talk with your objects have a lawful way do so, no matter what licenses you use.

The license for the IDL file cannot stop this in an enforcible way. Since there is only one way to write a valid IDL description of any given protocol, people are allowed to use the same IDL description, so you cannot really enforce the copyright on it. And if one ORB does not let them use the generated library in non-free software, they can use some other ORB. I am sure there are some ORBs (perhaps proprietary, but these people won't mind that) which permit it.

However, using the GPL on IDL files might have a substantial practical effect even if it isn't legally airtight. It might discourage much proprietary software from being written to talk to your objects, and it might convince many of the people who write programs that use your objects to make their programs free.

If a substantial amount of code in the ORB is copied into the output, then the output is also a derivative work of the ORB, and covered by the copyright on the ORB. Of course, this only covers the output made by that particular ORB. I presume that you can use the same IDL file with another ORB, and then you will get a library which might be derivative of the other ORB, but is certainly not a derivative of the first ORB.

More information can be found at http://w ww.progressive-comp.com/Lists/?l=berlin-design&r=1 &w=2#berlin-design

(Microsoft has acknowledged the bug, so the first half of your question is complete.)

I was curious just how quickly the ICMP attack took to fix, so here is my 5 minute investigation, it's taken longer to write this than research it. Kudos to the folks at Progressive Computer Concepts for their excellent mail list archives ( www.progressive-comp.com). I assume the date/times listed are in their local time.

Bug Notice: Posted to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.

Solution: Posted to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted to Bugtraq by Alan Cox, 1 June 1999 22:30:33.

So, 6 hours, 39 minutes, 47 seconds from the time it was made public to solution (7.5 minutes more if you only monitored Bugtraq).

And then this IIS bug, reported to Microsoft 8 June 1999, made public on Bugtraq at 12:18:16 today (15 June 1999). A week lead time, and no fix in sight.

Security is the heart of any business that relies on its web page for income (order taking, etc). Now that it's been made public, I'm sure all the skript kiddies will be wreaking havoc this evening on as many servers as they can hit. Although, for completeness, I'd be interested in noting any servers that do get hit. The Wired article specifically mentions Nasdaq, Disney, and Compaq as running "large ecommerce operations" on IIS. I can't imagine how a large company could stick with it with such pathetic service from MS.

Oh wait. I went to the security web site listed in the article, and MS has posted a workaround, basically remove the .HTR extension from IIS (the post on Bugtraq lists .ASP and .IDC as being affected as well). The funny thing is their terminology and timeline. At the top it says, "Originally Posted: May 27, 1999." So they knew about it a whole 11 days before eEye told them about it. Posted where, you might ask? Who knows. But at the bottom of the page it says, "June 15, 1999: Bulletin Created." I presume that "bulletin created" means they put it on their web site. Even still, not only with a week's notice, but 18 days notice the bug is not fixed.

Other inconsistencies in the notice, in the "What Microsoft is Doing" section, "Microsoft has released patches that fix the problem identified" (my bold). Oh, it's been fixed by golly. Then you go down to the "What Customers Should Do" section (be it 4 lines down, web design cracks aside) like they say next, what does it say? "A patch will be available shortly..." So it's fixed, but you cannot have it. This just makes my point even better. Why rely your business on them with this double-talk and no real solutions??

(Microsoft has acknowledged the bug, so the first half of your question is complete.)

I was curious just how quickly the ICMP attack took to fix, so here is my 5 minute investigation, it's taken longer to write this than research it. Kudos to the folks at Progressive Computer Concepts for their excellent mail list archives ( www.progressive-comp.com). I assume the date/times listed are in their local time.

Bug Notice: Posted to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.

Solution: Posted to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted to Bugtraq by Alan Cox, 1 June 1999 22:30:33.

So, 6 hours, 39 minutes, 47 seconds from the time it was made public to solution (7.5 minutes more if you only monitored Bugtraq).

And then this IIS bug, reported to Microsoft 8 June 1999, made public on Bugtraq at 12:18:16 today (15 June 1999). A week lead time, and no fix in sight.

Security is the heart of any business that relies on its web page for income (order taking, etc). Now that it's been made public, I'm sure all the skript kiddies will be wreaking havoc this evening on as many servers as they can hit. Although, for completeness, I'd be interested in noting any servers that do get hit. The Wired article specifically mentions Nasdaq, Disney, and Compaq as running "large ecommerce operations" on IIS. I can't imagine how a large company could stick with it with such pathetic service from MS.

Oh wait. I went to the security web site listed in the article, and MS has posted a workaround, basically remove the .HTR extension from IIS (the post on Bugtraq lists .ASP and .IDC as being affected as well). The funny thing is their terminology and timeline. At the top it says, "Originally Posted: May 27, 1999." So they knew about it a whole 11 days before eEye told them about it. Posted where, you might ask? Who knows. But at the bottom of the page it says, "June 15, 1999: Bulletin Created." I presume that "bulletin created" means they put it on their web site. Even still, not only with a week's notice, but 18 days notice the bug is not fixed.

Other inconsistencies in the notice, in the "What Microsoft is Doing" section, "Microsoft has released patches that fix the problem identified" (my bold). Oh, it's been fixed by golly. Then you go down to the "What Customers Should Do" section (be it 4 lines down, web design cracks aside) like they say next, what does it say? "A patch will be available shortly..." So it's fixed, but you cannot have it. This just makes my point even better. Why rely your business on them with this double-talk and no real solutions??

(Microsoft has acknowledged the bug, so the first half of your question is complete.)

I was curious just how quickly the ICMP attack took to fix, so here is my 5 minute investigation, it's taken longer to write this than research it. Kudos to the folks at Progressive Computer Concepts for their excellent mail list archives ( www.progressive-comp.com). I assume the date/times listed are in their local time.

Bug Notice: Posted to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.

Solution: Posted to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted to Bugtraq by Alan Cox, 1 June 1999 22:30:33.

So, 6 hours, 39 minutes, 47 seconds from the time it was made public to solution (7.5 minutes more if you only monitored Bugtraq).

And then this IIS bug, reported to Microsoft 8 June 1999, made public on Bugtraq at 12:18:16 today (15 June 1999). A week lead time, and no fix in sight.

Security is the heart of any business that relies on its web page for income (order taking, etc). Now that it's been made public, I'm sure all the skript kiddies will be wreaking havoc this evening on as many servers as they can hit. Although, for completeness, I'd be interested in noting any servers that do get hit. The Wired article specifically mentions Nasdaq, Disney, and Compaq as running "large ecommerce operations" on IIS. I can't imagine how a large company could stick with it with such pathetic service from MS.

Oh wait. I went to the security web site listed in the article, and MS has posted a workaround, basically remove the .HTR extension from IIS (the post on Bugtraq lists .ASP and .IDC as being affected as well). The funny thing is their terminology and timeline. At the top it says, "Originally Posted: May 27, 1999." So they knew about it a whole 11 days before eEye told them about it. Posted where, you might ask? Who knows. But at the bottom of the page it says, "June 15, 1999: Bulletin Created." I presume that "bulletin created" means they put it on their web site. Even still, not only with a week's notice, but 18 days notice the bug is not fixed.

Other inconsistencies in the notice, in the "What Microsoft is Doing" section, "Microsoft has released patches that fix the problem identified" (my bold). Oh, it's been fixed by golly. Then you go down to the "What Customers Should Do" section (be it 4 lines down, web design cracks aside) like they say next, what does it say? "A patch will be available shortly..." So it's fixed, but you cannot have it. This just makes my point even better. Why rely your business on them with this double-talk and no real solutions??

(Microsoft has acknowledged the bug, so the first half of your question is complete.)

I was curious just how quickly the ICMP attack took to fix, so here is my 5 minute investigation, it's taken longer to write this than research it. Kudos to the folks at Progressive Computer Concepts for their excellent mail list archives ( www.progressive-comp.com). I assume the date/times listed are in their local time.

Bug Notice: Posted to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.

Solution: Posted to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted to Bugtraq by Alan Cox, 1 June 1999 22:30:33.

So, 6 hours, 39 minutes, 47 seconds from the time it was made public to solution (7.5 minutes more if you only monitored Bugtraq).

And then this IIS bug, reported to Microsoft 8 June 1999, made public on Bugtraq at 12:18:16 today (15 June 1999). A week lead time, and no fix in sight.

Security is the heart of any business that relies on its web page for income (order taking, etc). Now that it's been made public, I'm sure all the skript kiddies will be wreaking havoc this evening on as many servers as they can hit. Although, for completeness, I'd be interested in noting any servers that do get hit. The Wired article specifically mentions Nasdaq, Disney, and Compaq as running "large ecommerce operations" on IIS. I can't imagine how a large company could stick with it with such pathetic service from MS.

Oh wait. I went to the security web site listed in the article, and MS has posted a workaround, basically remove the .HTR extension from IIS (the post on Bugtraq lists .ASP and .IDC as being affected as well). The funny thing is their terminology and timeline. At the top it says, "Originally Posted: May 27, 1999." So they knew about it a whole 11 days before eEye told them about it. Posted where, you might ask? Who knows. But at the bottom of the page it says, "June 15, 1999: Bulletin Created." I presume that "bulletin created" means they put it on their web site. Even still, not only with a week's notice, but 18 days notice the bug is not fixed.

Other inconsistencies in the notice, in the "What Microsoft is Doing" section, "Microsoft has released patches that fix the problem identified" (my bold). Oh, it's been fixed by golly. Then you go down to the "What Customers Should Do" section (be it 4 lines down, web design cracks aside) like they say next, what does it say? "A patch will be available shortly..." So it's fixed, but you cannot have it. This just makes my point even better. Why rely your business on them with this double-talk and no real solutions??

(Microsoft has acknowledged the bug, so the first half of your question is complete.)

I was curious just how quickly the ICMP attack took to fix, so here is my 5 minute investigation, it's taken longer to write this than research it. Kudos to the folks at Progressive Computer Concepts for their excellent mail list archives ( www.progressive-comp.com). I assume the date/times listed are in their local time.

Bug Notice: Posted to Bugtraq by Piotr Wilkin 1 June 1999 15:43:17.

Solution: Posted to Linux Kernel by Alan Cox, 1 June 1999 22:23:04. Also Posted to Bugtraq by Alan Cox, 1 June 1999 22:30:33.

So, 6 hours, 39 minutes, 47 seconds from the time it was made public to solution (7.5 minutes more if you only monitored Bugtraq).

And then this IIS bug, reported to Microsoft 8 June 1999, made public on Bugtraq at 12:18:16 today (15 June 1999). A week lead time, and no fix in sight.

Security is the heart of any business that relies on its web page for income (order taking, etc). Now that it's been made public, I'm sure all the skript kiddies will be wreaking havoc this evening on as many servers as they can hit. Although, for completeness, I'd be interested in noting any servers that do get hit. The Wired article specifically mentions Nasdaq, Disney, and Compaq as running "large ecommerce operations" on IIS. I can't imagine how a large company could stick with it with such pathetic service from MS.

Oh wait. I went to the security web site listed in the article, and MS has posted a workaround, basically remove the .HTR extension from IIS (the post on Bugtraq lists .ASP and .IDC as being affected as well). The funny thing is their terminology and timeline. At the top it says, "Originally Posted: May 27, 1999." So they knew about it a whole 11 days before eEye told them about it. Posted where, you might ask? Who knows. But at the bottom of the page it says, "June 15, 1999: Bulletin Created." I presume that "bulletin created" means they put it on their web site. Even still, not only with a week's notice, but 18 days notice the bug is not fixed.

Other inconsistencies in the notice, in the "What Microsoft is Doing" section, "Microsoft has released patches that fix the problem identified" (my bold). Oh, it's been fixed by golly. Then you go down to the "What Customers Should Do" section (be it 4 lines down, web design cracks aside) like they say next, what does it say? "A patch will be available shortly..." So it's fixed, but you cannot have it. This just makes my point even better. Why rely your business on them with this double-talk and no real solutions??

That site doesn't seems to have added posts after the 3rd yet. The thread is available here.

Don't forget that Creative Labs is planning to support 3D video drivers for all their products, including the Graphics Blaster Riva TNT. To find out more information from GGI developer Jon M. Taylor, check out his post to the GGI mailing list.