Abit leaving the motherboard market

According to this article, Abit is exiting the motherboard market by the end of this year. Abit's been my preferred motherboard brand for a long time now, with the right mix of interfaces and options for what I want. Now I've got to find another brand that has models with the right mix and a history of reliability. Annoying.

aseigo on new MS/Novell deal

http://aseigo.blogspot.com/2008/08/microsoft-and-novell-reaffirm-pact.html

aseigo has some comments on MS's new deal with Novell to buy more Linux support coupons. I have to agree with him. One thing that has bothered me with MS's activites is their nebulous claims about their IP that's supposedly infringed upon by Linux. My first reaction is "I'm from Missouri. Show me.". Exactly what intellectual property does Microsoft claim to own that's being infringed upon, and exactly what in a Linux distribution infringes upon it and how? Lay it out and let's get it resolved. And yet Microsoft won't do that. They play coy, dodging around saying exactly what it is they're accusing Linux of. And my immediate reaction to that is to think that they really don't have any claim that'll stand up to public scrutiny, that if they had to actually lay it out all they'd end up with is "We got nuthin'.". And that makes me immediately suspicious of any deal that supports them in this. When someone's running a scam (which is what a false claim to get others to pay you is, a scam), there's only two kinds of people doing business with them: marks, and accomplices. I probably want to avoid both.

DMCA: copyright owners must consider fair use

Copyright owners must consider fair use before filing a DMCA takedown notice. The full decision is here. The basic upshot of this is that copyright owners are required to consider whether a use of their material would reasonably be considered fair use under copyright law. The DMCA requires that the copyright owner have a good-faith belief that the use is infringing before they can file a takedown notice, and if the use falls under fair use and a reasonable person would have concluded this beforehand then the "good-faith belief" test fails. That, BTW, leaves the copyright liable for damages and penalties if the target of the notice wants to push it. The downside, of course, is that showing bad faith is a difficult thing to do in court, but still it's nice to have the principle upheld.

The judge says he's not sanguine about the defendant's chances of proving bad faith on the part of the plaintiff. I'm not so sure, at least if the judge is unbiased about it. The infringement in question is a song playing in the background of a baby video posted to YouTube. The Supreme Court has set forth 4 factors to consider in determining fair use: the nature of the use (commercial vs. non-commercial), the nature of the infringed work, the amount and substantiality of the portion used and the effect of the infringement on the potential market for the work. It's going to be very hard for a record label to argue that people are going to put up with watching someone's baby video repeatedly just to save the cost of buying the song. They're also going to have a hard time arguing commercial use, YouTube may put ads on the page but the uploader doesn't get any money from them and has no control over them and the entity that does get the money (YouTube) isn't the one the plaintiff's making a claim against. Even the nature of the copyrighted work works against the label. The work is a song, and it's merely incidental background noise in a video whose point is to showcase the uploader's baby. The only factor that works anywhere near in the plaintiff's favor is the amount of the song audible, and that's countered by the fact that the song's purely incidental background. As I said, it's not likely anyone's going to look at this video mainly for the music, any more than anyone watches a football game mainly to see the advertisements pasted around the stadium. Given all that, if the defendant's got a good lawyer I think they can make a very strong case that plaintiffs couldn't reasonably have believed the use wouldn't meet the qualifications for fair use. And proceeding when you know or should know otherwise is the very definition of bad faith.

Google session vulnerability

At DefCon there was a presentation on a way to hijack a Google Mail session. Google's implemented a new option to counter it, the option to always use SSL. Now, important point: the attack is not the one that sniffs your session cookie if you're using an unencrypted link. That attack can be prevented merely by using SSL all the time. This attack will work even if you use SSL for everything. It works by inserting code on a non-GMail page that'll cause a request to the non-SSL GMail pages, and the browser will send the session cookie in that unencrypted request without you being aware of it. When you use Google's fix, setting your account to always use HTTPS, Google does more than just force you to an "https:" URL. It also wipes your existing session cookie and creates a new one with a flag on it to tell the browser to only send this cookie in secure (HTTPS) requests. This prevents the cookie from being sent in the clear ever.

Law & Life: Silicon Valley: Major Victory for Open Source in Jacobsen Decision

Law & Life: Silicon Valley: Major Victory for Open Source in Jacobsen Decision

Artistic License is a copyright license after all

In the Jacobsen v. Katzer case, the trial court had ruled that the Artistic License (the open-source license under which the software involved was distributed) was a contract, not a copyright license. The Appeals Court for the Federal Circuit has overturned that ruling. The case is convoluted, because it originates not out of a copyright dispute but out of a patent issue. The copyright aspect came up out of the patent portion of the case. But it's good news nonetheless for open-source software. One of the standard arguments by open-source detractors is that the GPL and similar licenses are just contracts, subject to the vagaries of contract law, and violations of them have to be pursued as contract breaches. Now it's possible to hold up this ruling and say to them "The US Appeals Court disagrees with you.". Among other things this affects are the ability to recover costs. In a standard breach-of-contract suit the plaintiff, even if they win, is expected to bear their own costs except in unusual circumstances. In copyright-infringement actions, though, the law grants the prevailing party a much greater right to recover their costs and legal fees. This makes it easier for open-source authors to find lawyers willing to help them with copyright enforcement.

Credit-card system

You know, we need a change to the way credit-card purchases are handled. Card-present transactions, ones where you're physically there with the card to swipe, are OK. But when the card's not present, we need a change. Currently the system works by the merchant pulling money from your account. We need to change it so the card-holder pushes the payment to the merchant. That would eliminate the whole need for the merchant to store credit-card information, and eliminate a bunch of fraud in the process.

How would it work? Well, for a one-shot payment (your standard on-line purchase), check-out would proceed as normal except that when you told it you'd pay by credit card it wouldn't prompt for the card number. When you got to the confirmation page, it'd give you a merchant identity code and a transaction number. You'd then go to your credit-card issuer's Web site, log in and use those two numbers to generate a payment to the merchant. You'd of course verify that the merchant's identity code gave you the expected merchant name. You'd make the payment for exactly the amount the merchant gave as the total, and your card issuer would charge your card and transmit the payment to the merchant. The merchant could match the transaction number they got along with the payment with their order records, and ship your order only once they'd received your payment. The merchant's account would be solely for receiving money, nothing could be pulled out of it, so it'd be impossible to steal from the merchant. Nobody who knew your card number and other information could run a transaction, regardless of how much they knew, unless they also had the password for your account at the issuer and could log in as you to generate the payment. It'd be impossible for merchants to make unexpected charges to your card. And if the merchant claimed you hadn't sent the payment, you'd have your bank/issuer's record of the merchant accepting the payment as proof you had. This could all piggy-back on the bill-payment systems a lot of banks already have in place.

For recurring payments, it'd work two ways. For payments where the amount's known, the merchant could give you a customer identifier to use as the transaction number. Then you could simply set up an automatic recurring payment for that amount with your bank. For payments where the amount wasn't known beforehand (eg. utility bills), a back-channel could be provided where you give the merchant your card number or other bank-provided customer identifier and the merchant can send a payment request to your bank using that identifier and providing the payment amount and a transaction number. That'd go into a payment-request list you could view, and you could generate payments to the merchant directly from that list. These payment requests could even be used for non-recurring charges too, with a checkbox in the payment-information step to indicate whether you wanted the merchant to generate a payment request or not and a way to give the merchant your customer identifier. For full auto-pilot operation, the bank might let you flag requests from certain merchants for auto-approval, preferrably with a limit on the payment amount (eg. if your electric bill was normally $45-55 you might put a limit of $75 on auto-approved payments, with anything above that requiring manual approval) and timeframe (eg. auto-approve the utility bills for the next 2 months while you're possibly on vacation). Of course auto-approval removes a lot of the protection from fraudulent and unauthorized charges.

For people without Web access, it still works. They obviously won't be buying on-line, not when they can't get to Web sites at all, so the impact's mainly to mail-order and telephone purchases. Payment authorization can be added to ATMs easily enough. It can probably be added to telephone banking systems, although it's easier with voice-recognition systems than with ones that depend on the touch-tone keypad to enter information. And of course it could be done by a teller at a bank branch. In the worse case, a simple interface to turn auto-approval on for payment requests from merchants you needed to pay would turn the system back into the traditional pull-payment system.

California IP and non-compete law

As a follow-up to the last post about non-competes, I thought I'd repost links to the relevant California codes on intellectual-property and non-compete agreements:

• California Labor Code 2870-2872 on intellectual-property agreements
• California Business and Professions Code 16600-16607 on non-compete agreements

Anyone in the tech field in California should be familiar with these, because tech companies routinely put terms in their employment agreements that exceed what these laws allow. I made sure, when I signed my intellectual-property agreement, to add a notation referencing the limitations in 2870-2872 and making my acceptance limited to only what was allowed by those sections of the law.

Non-compete agreement? Not in California.

The California Supreme Court has ruled non-compete agreements illegal except in a very few circumstances. The law allows for them explicitly in cases involving the break-up of a corporation or partnership, but beyond those exceptions written into the law the Court ruled that the law simply prohibits an employer from restricting a former employee's right to engage in their profession. The full ruling is here. Given that it's the California Supreme Court ruling on this, Federal courts are likely to follow this ruling when interpreting California employment law. So if you work in California and your company had you sign a non-compete clause, it's out the window now.

Note that this doesn't mean you can do anything you want. If you got training at the company's expense, for instance, the clause that says you must either stay a certain length of time or re-pay the cost of the training (probably pro-rated) is still enforceable. If you do something like take company confidential information (eg. software source code, customer lists, etc.) and give it to your new employer, your former employer has grounds other than non-compete they can sue you on. And if you're a salesman and openly solicit your former company's customers to follow you to your new one, your former company again can sue you for that.

Telnet

Telnet: a useful program for determining whether a remote system is accepting connections on a given port, and for issuing direct commands to SMTP, HTTP and other similar services. It's use as a terminal emulation program is Not Recommended.