Re:This is a lot of work - have you read the LGPL?
on
LGPL is Viral for Java
·
· Score: 1
Directly linking to an LGPL library actually does not fulfill the LGPL requirement that the user should be able to upgrade to later versions of the LGPL library. It is too easy to break binary compatibility. Only by using a plugin architecture, (or making the entire project opensource) is a user enabled to work around any incompatibilities with later library versions.
BTW, this has nothing to do with 'selling' software. The issure is mixing software licenses. I use and write open source software - and sell consulting services. However, when a customer needs a service, and no open source solutions are available, and the customer doesn't want to fund development, then integrating a proprietary solution is the way to go. That integration requires mixing the proprietary code (which I am buying, not selling) with all the open source stuff to deliver to the customer.
Re:This is a lot of work - have you read the LGPL?
on
LGPL is Viral for Java
·
· Score: 1
According to the article, someone at FSF says that the LGPL *is* viral for Java.
Even if the FSF is wrong, creating the plugin API provides explicit support for one of requirements of the LGPL - that users be able to easily use a later version of the LGPL library.
The plugin technique also works for GPL Java code. Since your app has hever heard of the GPL code until it loads the class by name at runtime, it does not fall under the GPL requirements. I.e., your plugin is GPL, but not the app that merely loads the plugin by name from a config file.
If the above were not true, then we would not be allowed to run GPLed programs on a proprietary OS like Windows.
I believe that using an LGPL library through a plugin API will meet the demands of the FSF. Your code will never refer to the LGPL library - only the plugin interface. Your plugin itself will be LGPL, but that will help your users plugin future versions of the library - or their own versions.
The factory to create the plugin instances uses the name of a plugin class stored in a config file to load the plugin class. Users can change plugin implementations by just changing the config file.
The 'import' statement in Java doesn't actually link anything - it is just a namespace declaration. However, when you refer at compile time to methods, fields, and constants in another class, the compiler actually reads in that class and does the equivalent of '#include done right'. This makes Java code that directly refers at compile time to LGPL code a derivative work.
However, you can use a plugin model to use an LGPL library without directly importing it. You write an interface that your code imports, and write an implementation that imports both your interface and the LGPL library. The implementation of your plugin interface is now LGPL, inherited from the LGPL library. However, your code that that simply imports the interface is not LGPL.
If you are wondering how the implementation class every gets instantiated without refering to it at compile time, then you are not an experienced Java programmer:-) The answer is that your factory class reads a config file to get the name of the implementation class, and then loads it via Class.forName() (or one of the more complex ClassLoader APIs).
Now, your application has avoided becoming LGPL (except for the small class that implements the plugin API). Furthermore, you are conforming to the spirit of the LGPL because users of your application can easily adapt any future version of the LGPL library - or even their own innovation implementation - using your plugin API, and the working source you provide to 'plugin' the LGPL library.
For illustration, suppose there is an LGPL library to translate any text from one language to another. It provides a Translator class (sorry, Slashdot doesn't seem to let me indent the code):
/* LGPL license */ package fsf.goodies; import java.util.Locale; public class C3P0 { public String translate(String msg,Locale src,Locale dst) { /* magic AI code here */ } }
Now, you want to use this in your BSD license UberChat application. You can't just use Translator, because then your app would need to be LGPL as well. Instead, you define an interface:
/* BSD license */ package org.bsd.uberchat;
import java.util.Locale;
public interface Translator { String translate(String msg,Locale src,Locale dst); }
Then, you make a plugin that implements the Translator interface. Your plug in is LGPL because it uses the LGPL library.
/* LGPL */ import fsf.goodies.C3P0; public class C3P0Plugin implements Translator { /* in this trivial example (except for C3P0, that is), nothing more is required. In real life, you might need to massage arguments and do other processsing to match the interface with the implementation. */ }
Finally, you need a factory class to obtain a Translator instance:
package org.bsd.uberchat;
public class TranslatorFactory { /* Actually, there are more exceptions that needs to be handled in a real factory class. */ static public Translator getTranslator() { Config config = new Config("uberchat"); String cname = config.getString("translator"); Object trans = Class.forName(cname); if (trans instanceof Translator) return (Translator)trans; throw new RuntimeException("translator plugin does not implement the proper interface"); } }
public class Foo { static public void main(String[] argv) { Translator t = TranslatorFactory.getTranslator(); String msg = t.translate(argv[0],Locale.US,Local.GERMAN); &nbs p; System.out.println(msg); } }
And, while none of this is tested, presumably with "fsf.goodies.C3P0" as the value of the "translator" property in your configuration framework (now included with Java 1.4), running
Sometimes, corporations will fund development for itches they need scratched. For instance, I've done a lot of work on Python Milter and Python Dspam during work hours because our customers are screaming from the irritation of Spam and Email Viruses (although they won't listen to our recommendation not to use OutHouse, I mean OutLook).
These are problems they would not wish on their fiercest competitors, so there is no desire to keep it proprietary. In general, when a company's primary business is not computers, the computer is just a tool. And they are willing to contribute to projects to improve the tool for everyone.
These investments are always going to be small and short term. However, sometimes you can go around to many businesses in a trade, and convince them to pool contributions for a project that benefits them all. They are competitors, so there is suspicion to overcome, but if you are a neutral third party (e.g. you are a computer consultant) it can be done.
For hex addition, I sometimes use a
chinese abacus. The chinese style has two top beads and 5 bottom beads (as opposed to the Japanese style which has 1 top bead and 4 bottom beads). One of the top beads and one of the bottom beads on a chinese abacus are never used for decimal addition (they are used for carries when multiplying). However, if you count each top bead as 5 and each bottom bead as 1, they add up to 15 - which works perfectly for addition in base 16 (just as the 1 top and 4 bottom add up to 9 for decimal addition). The beauty of adding on an abacus is that the answer appears as you "key" in the operands. No wasted keystrokes to type "+" or ENTER.
A decent commercial offering would have discovered the problem during testing on all supported platforms (write once, test everywhere) and would either use Sun's API checking tools or create their own.
The "unwary" are all the in-house and hobby programmers who might get the impression that only Windows runs "Java" correctly. This group far outnumbers the ranks of competent programmers for commercial products - especially in-house programmers for corporations.
As it turned out, MS's move damaged Java on the desktop and Java applets, but didn't affect servers - where most in-house programming was done anyway. Servers either wouldn't be running Windows, or would have the latest Sun or IBM JVMs since they were under the control of the programmers.
While I would like to see more Java applets (instead of flash or shockwave), Java has some technical hurdles to overcome (like multiple apps per JVM) before it is really ready for the desktop. So perhaps the delay was for the best.
J/Direct and other true extensions were not a problem. The problem was that Sun included MS only extensions to core Java packages - in direct violation of their contract. MS was welcome to provide any number of MS only extensions as long as they weren't in packages named java.* or javax.*.
The conforming extensions were welcome and handy for high level WIndows programming. But MS insisted on dropping in extensions to the java.* core packages to catch the unwary.
The illegal signatures were listed from the output of a tool Sun provided to check core ABI compatibility, and the output included in the court evidence.
What was MS's excuse in court? "Gee, that provision only applied to JDK1.0. We can do anything we want with JDK1.1." Incredibly, MS was right. The contract failed to mention something along the lines of "this goes for all subsequent official versions too". Chalk up a big boo boo for Sun's legal department. Nevertheless, MS's behavior was reprehensible.
Subsequently, Sun introduced the 100% Pure campaign and made API checking tools widely available so that you could check whether any code used non-standard core package extensions. This helped, but most of the damage was already done.
To me what they seem to be desribing is a particular application of DNAT. Implementing what they describe on Linux to logically replace an entire server (claim 1) is indeed trivial with iptables out of the box using DNAT and quite obvious. In fact, I've always done it without thinking when moving HTTP servers (or SMTP servers or squid cache or IMAP servers or anything else with a host and port) to new boxes.
However, the second two claims mention replacing/mirroring only part of the content of a server, which would require a kernel module to parse HTTP request packets. This is not so trivial to implement - but still an obvious elaboration. Of course, a tool to automatically maintain DNAT tables based on a high level network description would be non-trivial to implement also - but an obvious labor saver for large networks.
If only there was a patent on DNAT, they couldn't get away with this. In fact, claim 1 seems to be exactly DNAT if generalized to arbitrary ports. This illustrates the fundamental problem with software patents. Most software engineering is putting together building blocks in simple combinations to fit a particular application. Imagine getting a patent on particular combinations of programs in a pipeline. I'm patenting "ps -ef | grep".
If their patent covered only parsing HTTP packets in a router, I would be only annoyed. If I needed the capability bad enough to devote the time to do it, I could probably use their product cheaper. However, if claim 1 is going to prevent me from ever using DNAT again, I am outraged - but impotent as usual. Like it or not, I probably violate thousands of stupid patents every day without knowing it. What's one more.
Black Hole . . . bottomless pit . . . yes it is all clear now.
Disclaimer: Yes I believe the Bible. No, I don't put any stock in the "Left Behind" style interpretation (map prophetic events to modern events, use a hammer to make it fit) except as a form of Sci Fi/Fantasy entertainment.
Revelation 9
1 And the fifth angel sounded, and I saw a star fall from heaven unto the earth: and to him was given the key of the bottomless pit. 2 And he opened the bottomless pit; and there arose a smoke out of the pit, as the smoke of a great furnace; and the sun and the air were darkened by reason of the smoke of the pit. 3 And there came out of the smoke locusts upon the earth: and unto them was given power, as the scorpions of the earth have power. 4 And it was commanded them that they should not hurt the grass of the earth, neither any green thing, neither any tree; but only those men which have not the seal of God in their foreheads. 5 And to them it was given that they should not kill them, but that they should be tormented five months: and their torment was as the torment of a scorpion, when he striketh a man. 6 And in those days shall men seek death, and shall not find it; and shall desire to die, and death shall flee from them. 7 And the shapes of the locusts were like unto horses prepared unto battle; and on their heads were as it were crowns like gold, and their faces were as the faces of men. 8 And they had hair as the hair of women, and their teeth were as the teeth of lions. 9 And they had breastplates, as it were breastplates of iron; and the sound of their wings was as the sound of chariots of many horses running to battle. 10 And they had tails like unto scorpions, and there were stings in their tails: and their power was to hurt men five months. 11 And they had a king over them, which is the angel of the bottomless pit, whose name in the Hebrew tongue is Abaddon, but in the Greek tongue hath his name Apollyon.
Counterfeiter adopts $18 standard
on
Making Change
·
· Score: 1
A counterfeiter printed a batch of $18 bills, but had trouble passing them in the city. Thinking he would have better luck where people were less sophisticated, he tried an old general store in the country.
"Can you give me change for an $18 bill?", he asked the gizzled proprieter.
"Shore! What'll it be? Two nines, or three sixes?"
Run the queries in parallel on each server, then merge the results. Remember that SQL tables are sets. The merging overhead is proportional to the size of the result size - and independent of the size of the tables being queried. As long as your result set stays small, you can throw an unlimited number of servers at parallelizing the query with linear performance gain.
Here is a simple example to help understanding and spark some political debate at the same time.:-) You have detailed ATM card transactions for 300 million americans. The detail records are distributed via a hash function over 1000 database servers. Each server has the same schema - but the tables on each server have a different subset of the records for that table. Each server independently looks for records of visiting a particular ATM on a particular day, and forwards those records to a merge processor. The result set is small, so the merge processing is insignificant, and the query gets a 1000X speedup.
When inserting a record, the hash function determines which server to send it to for insertion. This randomized distribution is necessary to keep the number of records on each server roughly equal without requiring feed back from the servers. (Although tracking size of each table on each server is also reasonable.)
We used to write software for the IBM 5110 (64K RAM, 128K ROS, or ROM as they say nowadays, and 2 x 8" 1 MB floppy drives. One of our clients raised beef cattle. He had the machine in the back of his pickup (the main unit was the size of a modern desktop, with an integrated 7" display) along with a load of hay. The hay caught fire. The chemical fire extinguisher wasn't up to the job and he called the fire department. The fire hoses put out the fire. The firemen threw the computer and diskette drives out of the truck onto the grass. The truck was in bad shape. The computer had changed its enclosure color from putty to charcoal, and was smoking. The floppies were melted.
After letting the computer cool off and dry off, he cleaned off the chemical residue from the fire extinguisher. He put in a backup floppy, turned it on, and it ran! (Note 5110 booted from ROS, but applications resided on floppies.)
This is a not-for-profit, but Unshacked! offers custom CD's by mail order. The web site offers only consecutive episodes on CD, but the mail order form lets you pick any selection by number, which are burned onto CDR (or audio tape for the old fashioned).
There is a natural solution to this problem - that also solves the problem of legitimate mass email.
All penny black servers must also support SMTP authentication.
Unauthenticated email clients must provide a penny black payment.
Authenticated clients need not do so.
This scheme allows SMTP authentication to be gradually deployed. Any enterprise with an SMTP server will be motivated to implement SMTP AUTH + Penny black to stop spam. Initially, clients without authentication will use the penny black system. If that is a bother, then they can upgrade to proper SMTP authentication.
Legitimate mass email simply needs to support SMTP authentication.
We ditched SCO way back in the days of Xenix. (We switched to Motorola, which was a great Unix vendor). Initially, we had standard tech support. The problem was, that whatever problem we had (for example 'tar' sends error messages to stdout, corrupting our archives!), their answer was always "Reformat your disk and reinstall Xenix". (Thankfully, we were able to replace tar with GNUtar. Thank you, thank you, Richard Stallman. We bought a tape!)
My boss said that we just needed to pay for the premium tech support to get real help. So we paid $1200 for one year of premium support. The next problem we had involved a system with brand new ESDI drives. ESDI was the Next Big Thing after ST506 for inexpensive disk drives. The problem was that Xenix would crash while formatting the ESDI disk when it encountered a bad sector, requiring a reboot (from floppy, since the system wasn't installed yet). So we called premium tech support, figuring that at least they couldn't tell us to "Reformat the disk and reinstall Xenix".
You can probably guess what their suggested solution was. When I tried to explain why that solution was impossible, the tech person replied haughtily that *he* was the tech person and if I wanted his help I would have to follow instructions. That finally convinced my boss that it was time to find another Unix company.
A bit later one of our clients ordered an SCO system against our advice because they claimed to support SMP. It turned out that most IPC did not work between processors (not even shell pipelines!). The fork() call would always create a processor on the same processor, so that login shells would mostly work. But IPC based servers (such as a database server) would fail whenever the client was on a different processor.
We called our clients premium tech support, and were informed that their system could not possibly be as broken as we described, and we would have to hire a certified SCO consultant at our (clients) expense to verify the problem. So we hired the consultant, and he came out and verified that yep, IPC only works on the same processor, and you can use a special API to assign a process to a particular processor to access a service that happens to be running on that processor.
The consultant called SCO, and SCO insisted that that was the way it should work, and it was not broken. So we disabled all but one CPU so the system would at least run.
After this, my bosses theory was that all SCO employees were stoned.
A
partial list was provided with the initial lawsuit (which was posted online). However, the two problems were naming and completeness.
As part of their contract, MS was forbidden to add public names to system packages (e.g. java.lang, java.net, etc). Nevertheless, they did so. There were some stretchers on both sides.
Microsoft PR claimed that Sun was forbidding them to add Windows specific extensions. This was silly - there was no problem with any number of packages named com.ms.* or whatever (except that the ms.com domain belongs to Morgan Stanley, and thus didn't follow the 3rd party naming convention - but that wasn't in the contract). There were some very nice extensions with proper names - like JDirect which let you call Microsoft DLL's without writing JNI glue. The problem was that Microsoft wanted to name some extensions java.*. This would of course cause the unwary programmer to inadvertantly create Java programs which only run on Windows - despite not knowingly using any MS specific packages. Exactly what MS wanted.
On Sun's part, the contract included a list of packages which Microsoft could not touch the public name space of. More system packages were added to Java 1.1. Sun claimed that Microsoft couldn't touch those either - reasonable, but they weren't in the specific list in the contract.
The completeness problem was along the same lines. Microsoft provided a complete 1.0 API. However, they left out components of the 1.1 API that competed with their own offerings. For instance, they left out RMI and offered DCOM support instead. Sun said that it was understood that the same restrictions regarding system name space pollution and completeness would apply to the packages of subsequent API versions. But this was not spelled out in the contract. It would not be in the ruthless spirit of Microsoft for them to follow the spirit of a contract if they could find a loophole.
Regardless of quibbling over whether the system package list under contract should expand to match new API versions, Microsoft polluted even core packages from 1.0 with handy additions sure to entice the unwary. So they were guilty even by the letter of the law.
Won't be any worse off than we are now. We currently have to beg the listed "owner" to make changes for us. If someone snaps it and sells back (and actually *does* sell it back) for something reasonable, like $100, we'll be happy.
I'm actually campaigning for an entirely new domain, preferably shorter.:-)
If we can get the old one too for a reasonable amount, that would be gravy.
That's nothing. One of our clients paid the big bucks for an "express transfer" two years ago - and the domain is still under the wrong org. Maddeningly, they have the correct organization for 'billing', but 'billing' can't make changes to DNS servers, etc - just pay the bill.
We don't have time or money for lawsuits. The only option seems to be to let the domain expire (in Feb 2004), and then try to be the first to re-register it (with a different registrar of course).
Slashdot Mirror
BTW, this has nothing to do with 'selling' software. The issure is mixing software licenses. I use and write open source software - and sell consulting services. However, when a customer needs a service, and no open source solutions are available, and the customer doesn't want to fund development, then integrating a proprietary solution is the way to go. That integration requires mixing the proprietary code (which I am buying, not selling) with all the open source stuff to deliver to the customer.
I believe that using an LGPL library through a plugin API will meet the demands of the FSF. Your code will never refer to the LGPL library - only the plugin interface. Your plugin itself will be LGPL, but that will help your users plugin future versions of the library - or their own versions. The factory to create the plugin instances uses the name of a plugin class stored in a config file to load the plugin class. Users can change plugin implementations by just changing the config file.
Oops, the "translator" property should be "C3P0Plugin". I did preview, I did!
However, you can use a plugin model to use an LGPL library without directly importing it. You write an interface that your code imports, and write an implementation that imports both your interface and the LGPL library. The implementation of your plugin interface is now LGPL, inherited from the LGPL library. However, your code that that simply imports the interface is not LGPL.
If you are wondering how the implementation class every gets instantiated without refering to it at compile time, then you are not an experienced Java programmer :-) The answer is that your factory class reads a config file to get the name of the implementation class, and then loads it via Class.forName() (or one of the more complex ClassLoader APIs).
Now, your application has avoided becoming LGPL (except for the small class that implements the plugin API). Furthermore, you are conforming to the spirit of the LGPL because users of your application can easily adapt any future version of the LGPL library - or even their own innovation implementation - using your plugin API, and the working source you provide to 'plugin' the LGPL library.
For illustration, suppose there is an LGPL library to translate any text from one language to another. It provides a Translator class (sorry, Slashdot doesn't seem to let me indent the code):
Now, you want to use this in your BSD license UberChat application. You can't just use Translator, because then your app would need to be LGPL as well. Instead, you define an interface:Then, you make a plugin that implements the Translator interface. Your plug in is LGPL because it uses the LGPL library.Finally, you need a factory class to obtain a Translator instance:Finally, using the plugin is simple:And, while none of this is tested, presumably with "fsf.goodies.C3P0" as the value of the "translator" property in your configuration framework (now included with Java 1.4), runningshould result in an output of:Particle physicists don't have much ground to complain about cutesy names. "Leprechaun" seems like a good name for a charmed lepton to me.
These are problems they would not wish on their fiercest competitors, so there is no desire to keep it proprietary. In general, when a company's primary business is not computers, the computer is just a tool. And they are willing to contribute to projects to improve the tool for everyone.
These investments are always going to be small and short term. However, sometimes you can go around to many businesses in a trade, and convince them to pool contributions for a project that benefits them all. They are competitors, so there is suspicion to overcome, but if you are a neutral third party (e.g. you are a computer consultant) it can be done.
For hex addition, I sometimes use a chinese abacus. The chinese style has two top beads and 5 bottom beads (as opposed to the Japanese style which has 1 top bead and 4 bottom beads). One of the top beads and one of the bottom beads on a chinese abacus are never used for decimal addition (they are used for carries when multiplying). However, if you count each top bead as 5 and each bottom bead as 1, they add up to 15 - which works perfectly for addition in base 16 (just as the 1 top and 4 bottom add up to 9 for decimal addition). The beauty of adding on an abacus is that the answer appears as you "key" in the operands. No wasted keystrokes to type "+" or ENTER.
Do something we've done for hundreds of years - but do it on a computer!
The second era of software patents:
Do something we've done on computers for decades - but do it on the web!
The new era of software patents:
Do something we've done on the web for years - but do it on IM!
The "unwary" are all the in-house and hobby programmers who might get the impression that only Windows runs "Java" correctly. This group far outnumbers the ranks of competent programmers for commercial products - especially in-house programmers for corporations.
As it turned out, MS's move damaged Java on the desktop and Java applets, but didn't affect servers - where most in-house programming was done anyway. Servers either wouldn't be running Windows, or would have the latest Sun or IBM JVMs since they were under the control of the programmers.
While I would like to see more Java applets (instead of flash or shockwave), Java has some technical hurdles to overcome (like multiple apps per JVM) before it is really ready for the desktop. So perhaps the delay was for the best.
The conforming extensions were welcome and handy for high level WIndows programming. But MS insisted on dropping in extensions to the java.* core packages to catch the unwary.
The illegal signatures were listed from the output of a tool Sun provided to check core ABI compatibility, and the output included in the court evidence.
What was MS's excuse in court? "Gee, that provision only applied to JDK1.0. We can do anything we want with JDK1.1." Incredibly, MS was right. The contract failed to mention something along the lines of "this goes for all subsequent official versions too". Chalk up a big boo boo for Sun's legal department. Nevertheless, MS's behavior was reprehensible.
Subsequently, Sun introduced the 100% Pure campaign and made API checking tools widely available so that you could check whether any code used non-standard core package extensions. This helped, but most of the damage was already done.
However, the second two claims mention replacing/mirroring only part of the content of a server, which would require a kernel module to parse HTTP request packets. This is not so trivial to implement - but still an obvious elaboration. Of course, a tool to automatically maintain DNAT tables based on a high level network description would be non-trivial to implement also - but an obvious labor saver for large networks.
If only there was a patent on DNAT, they couldn't get away with this. In fact, claim 1 seems to be exactly DNAT if generalized to arbitrary ports. This illustrates the fundamental problem with software patents. Most software engineering is putting together building blocks in simple combinations to fit a particular application. Imagine getting a patent on particular combinations of programs in a pipeline. I'm patenting "ps -ef | grep".
If their patent covered only parsing HTTP packets in a router, I would be only annoyed. If I needed the capability bad enough to devote the time to do it, I could probably use their product cheaper. However, if claim 1 is going to prevent me from ever using DNAT again, I am outraged - but impotent as usual. Like it or not, I probably violate thousands of stupid patents every day without knowing it. What's one more.
Disclaimer: Yes I believe the Bible. No, I don't put any stock in the "Left Behind" style interpretation (map prophetic events to modern events, use a hammer to make it fit) except as a form of Sci Fi/Fantasy entertainment.
Revelation 9
"Can you give me change for an $18 bill?", he asked the gizzled proprieter.
"Shore! What'll it be? Two nines, or three sixes?"
Here is a simple example to help understanding and spark some political debate at the same time. :-) You have detailed ATM card transactions for 300 million americans. The detail records are distributed via a hash function over 1000 database servers. Each server has the same schema - but the tables on each server have a different subset of the records for that table. Each server independently looks for records of visiting a particular ATM on a particular day, and forwards those records to a merge processor. The result set is small, so the merge processing is insignificant, and the query gets a 1000X speedup.
When inserting a record, the hash function determines which server to send it to for insertion. This randomized distribution is necessary to keep the number of records on each server roughly equal without requiring feed back from the servers. (Although tracking size of each table on each server is also reasonable.)
That's OK. I gave up Slashdot for Lent, so the timing of the repost was perfect. Now to HTML encode my email on all my web pages . . .
After letting the computer cool off and dry off, he cleaned off the chemical residue from the fire extinguisher. He put in a backup floppy, turned it on, and it ran! (Note 5110 booted from ROS, but applications resided on floppies.)
They don't make 'em like they used to.
This is a not-for-profit, but Unshacked! offers custom CD's by mail order. The web site offers only consecutive episodes on CD, but the mail order form lets you pick any selection by number, which are burned onto CDR (or audio tape for the old fashioned).
- All penny black servers must also support SMTP authentication.
- Unauthenticated email clients must provide a penny black payment.
- Authenticated clients need not do so.
This scheme allows SMTP authentication to be gradually deployed. Any enterprise with an SMTP server will be motivated to implement SMTP AUTH + Penny black to stop spam. Initially, clients without authentication will use the penny black system. If that is a bother, then they can upgrade to proper SMTP authentication.Legitimate mass email simply needs to support SMTP authentication.
My boss said that we just needed to pay for the premium tech support to get real help. So we paid $1200 for one year of premium support. The next problem we had involved a system with brand new ESDI drives. ESDI was the Next Big Thing after ST506 for inexpensive disk drives. The problem was that Xenix would crash while formatting the ESDI disk when it encountered a bad sector, requiring a reboot (from floppy, since the system wasn't installed yet). So we called premium tech support, figuring that at least they couldn't tell us to "Reformat the disk and reinstall Xenix".
You can probably guess what their suggested solution was. When I tried to explain why that solution was impossible, the tech person replied haughtily that *he* was the tech person and if I wanted his help I would have to follow instructions. That finally convinced my boss that it was time to find another Unix company.
A bit later one of our clients ordered an SCO system against our advice because they claimed to support SMP. It turned out that most IPC did not work between processors (not even shell pipelines!). The fork() call would always create a processor on the same processor, so that login shells would mostly work. But IPC based servers (such as a database server) would fail whenever the client was on a different processor.
We called our clients premium tech support, and were informed that their system could not possibly be as broken as we described, and we would have to hire a certified SCO consultant at our (clients) expense to verify the problem. So we hired the consultant, and he came out and verified that yep, IPC only works on the same processor, and you can use a special API to assign a process to a particular processor to access a service that happens to be running on that processor.
The consultant called SCO, and SCO insisted that that was the way it should work, and it was not broken. So we disabled all but one CPU so the system would at least run.
After this, my bosses theory was that all SCO employees were stoned.
I expect it's more like "95% of computers participating in p2p networks that RIAA knows about".
As part of their contract, MS was forbidden to add public names to system packages (e.g. java.lang, java.net, etc). Nevertheless, they did so. There were some stretchers on both sides.
Microsoft PR claimed that Sun was forbidding them to add Windows specific extensions. This was silly - there was no problem with any number of packages named com.ms.* or whatever (except that the ms.com domain belongs to Morgan Stanley, and thus didn't follow the 3rd party naming convention - but that wasn't in the contract). There were some very nice extensions with proper names - like JDirect which let you call Microsoft DLL's without writing JNI glue. The problem was that Microsoft wanted to name some extensions java.*. This would of course cause the unwary programmer to inadvertantly create Java programs which only run on Windows - despite not knowingly using any MS specific packages. Exactly what MS wanted.
On Sun's part, the contract included a list of packages which Microsoft could not touch the public name space of. More system packages were added to Java 1.1. Sun claimed that Microsoft couldn't touch those either - reasonable, but they weren't in the specific list in the contract.
The completeness problem was along the same lines. Microsoft provided a complete 1.0 API. However, they left out components of the 1.1 API that competed with their own offerings. For instance, they left out RMI and offered DCOM support instead. Sun said that it was understood that the same restrictions regarding system name space pollution and completeness would apply to the packages of subsequent API versions. But this was not spelled out in the contract. It would not be in the ruthless spirit of Microsoft for them to follow the spirit of a contract if they could find a loophole.
Regardless of quibbling over whether the system package list under contract should expand to match new API versions, Microsoft polluted even core packages from 1.0 with handy additions sure to entice the unwary. So they were guilty even by the letter of the law.
I'm actually campaigning for an entirely new domain, preferably shorter. :-)
If we can get the old one too for a reasonable amount, that would be gravy.
And I just noticed that Verisign doesn't show the billing party on the whois screen anymore.
We don't have time or money for lawsuits. The only option seems to be to let the domain expire (in Feb 2004), and then try to be the first to re-register it (with a different registrar of course).