I have often found South America to be sort of interesting in these ways. I offered to pay tarrifs on a computer I was giving to a friend in Ecuador back in 2001, and the customs officials laughed at me. I was told that, no, I didn't have to pay tarrifs and that everything was fine (after the embassy told me to pay 40% of the value as a tarriff!)
I suspect things are a little different now with the new movement centered around Chavez and De Silva (not that they are on the same track-- the only real shared emphasis seems to be in regional economic development-- also with Correa joining that, I think there is a good chance that Chavez will find himself more or less sidelined). While South America is not what it was 7 years ago, it is probably on the track to becoming something better. There is a trend toward coming down *hard* on foreign companies that break the law, and this is probably a good thing (at least in Brazil and Ecuador, neither country seems to endorse the same sort of socialization as Venezuela or Bolivia, and even Bolivia is a very different situation than Venezuela).
BTW, this might be slightly off-topic, but I have been very heartened by the adoption of LedgerSMB in both Venezuela and Columbia. I expect Ecuador, Brazil, and other areas to follow suit as our software becomes more mature. I think that the way forward for most of the world is in open source and my business is committed to helping make that happen.
Trademark Obscurity of "Open" "Open Source" "Open Standards" Microsoft may be guilty of trademark obscurity, but do any of these have any real trademarks attached as relate to software? (Excluding Amex's trademark on "Open").
"Open Source" is somethng the OSI wants to try to suggest they can enforce but it has 10 years or so of generic use now and given that only a tiny fraction of open source licenses are OSI-approved, I somehow doubt that one couldn't argue well that the trademark had been diluted to the point of being worthless. IANAL, though.
Microsoft already has a few projets under these licenses. The Sharepoint Learning Toolkit (or whatever it is called) is under the MS Reciprocal License. The ASP.Net Ajax Control Kit, and so forth.
So yes, they have already been using these licenses.
They have also released works under other licneses (WiX, under the CPL, for example).
MS-RL is more like the MPL than the GPL v2. There is only limited compatibility between either of these licenses and the GPL v2, and bigger issues with the GPL v3.
First the MS-RL (MS-Reciprocal License, not the Reference License), applies to any of your files that contain the code.
The MS-PL applies only to the code you licensed. It is designed to be similar to the BSDL, requiring you to sublicense that code only under the terms of the original license, while you can license your *own code* under any terms you want. It is unclear whether or not this is GPL v3 compatible (there is some limited compatibility of both licenses with the GPL v2 provided that they are not ditributed as part of the same work). IANAL though.
isn not exactly the paragon of Freedom as in Free Speech either. As much as Debian may be a dysfunctional democracy, they are better at consistantly addressing this issue than the FSF.
Ever wonder why the GFDL has the invariant sections clause? According to Stallman himself (in a post to debian-legal), it was because he wanted to *force* the distribution of the GNU Manifesto with the Emacs manual. This essentially turns the ideal of free speech on its head by creating a situation where forced advocacy is accepted. When the then-main-architect of HURD criticized the decision, Stallman asked him to resign. If this is the sort of Stallmanist "Free Speech" we are to associate with Free Software, I want nothing to do with it.
Debian did the right thing and to this day considers any GFDL work containing invariant sections to be non-Free.
Note that I am not a Debina Developer, and I think that at the end we should think for ourselves and not be groupies of RMS or anyone else.
Interestingly the OSI's Open Source Definition is derived from an attempt to define the FSF's 4 freedoms.
The lineage goes from the FSF to Debian (and the Debian Free Software Guidelines) to the OSI's Open Source Definition (which were mostly copied from the DFSG).
If you read the MS-Reciprical License and the MS-PL, you will see that they don't provide any restrictions on use, so this distinction doesn't really matter anyway.
At first, I was nodding in agreement. But then I realized, how do you find out when you've built in hidden single points of failure? Design review, testing, More review, More testing.
A single power cutoff to all three computers should not have passed a design review. Yes, you will probably always have some single point of failure somewhere (or at least a possibility that a single event can disrupt both primary and secondary systems), but you design your way out of it, and you ensure that all designs are adequately reviewed.
This is not a tricky problem, but these sorts of errors do happen no matter how much you do. However, when they do, it is because someone missed something in the review process.
The issue in this case was at least in part a failing dehumidifier. So in reality there is would seem to be more than enough blame to go around relating to the condensation.
However, the big issue is the fact that there was a single point of failure for this supposedly triply-redundant system. *That* seems t be the Russians' fault pure and simple.
I would also add that the PCI-DSS is not the beginning and end of preventing cardholder information compromises. I think that some new regulation is required, not for the retailers, but for the acquirers.
Basically, I think that the PAN should be barred from being saved and that the acquirer should take on that responsibility. They are in a better position to manage such security issues anyway, and there are better ways of doing this anyway. For example, why not handle recurring payments as keyed to the original approval code instead of the PAN? The approval code is then tied to a merchant account and so is non-reusable in the same way. Barring that, I think that the payment gateway should hold the information.
They are basically cut and pasted from the requirements that the payment card industry places on merchants anyway. V/MC "levy fines" of up to a half a million dollars in the event of noncompliance which results in credit card data theft. This law would have helped buisnesses avoid fines which would result in bankrupcy by helping them understand what they were required to do.
The basic thing is that another multinational enforces a contractual provision against all merchants big and small, doing business in various parts of the world. That multinational is Visa/Mastercard. And they levy fines of up to $500,000.00 USD for noncompliance.
All this law would have done practically speaking would have been to encourage small businesses to protect data properly. Right now, I don;t think most of them know what they are required to do. It is a shame and nothing more than political posturing which creates a dangerous illusion.
That problem mostly affects large businesses only (i.e. those who can afford to talk directly to the V/MC network and skip the gateway). And the cost of compliance there is *huge.*
For smaller businesses, generally this is handled via the acquirer (in the case of a small credit card processing terminal) or the payment gateway (like Authorize.net or TrustCommerce). There is no reason to store the credit card number beyond the initial approval there.
Note furthermore, that you *can* store the credit card number indefinitely under PCI-DSS provided that it is encrypted. You cannot however store (subsequent to authorization) anything including or containing: The PIN number or PIN block, the CVV2 (printed on the plastic) or the CVV (contained in the track data).
So, for example, one option to handling internet down issues is: 1) Track data is encrypted with public key at the POS server after being transferred via ssl to that system then inserted into db. If the key does not exist, we ask a separate process to generate and store keys. 2) When internet connection comes back up, a spool process (accepts the private key from a USB device, decrypts the track data, submits it for approval, and then deletes it. When this is done, the private key is deleted. The key is appropriately protected and file access is audited.
Because of PCI compliance you have Linux/Unix admins across the country installing useless virus scanners that scan for windows viruses on their Linux/Unix machines. PCI compliance is a private initiative by the credit card companies. Then the problem is either with the admins or that the compliance people can't read.
The PCI-DSS 1.1 states:
5.1: Deploy anti-virus software on all systems commonly affected by viruses (particularly personal computers and servers) Note: Systems commonly affected by viruses typically do not include UNIX-based operating systems or mainframes.[emphasis mine] Next time someone complains about the PCI-DSS requiring antivirus software on Linux/UNIX systems, you can point them to the fact that the standard specifically excluded these systems from the antivirus requirements.
If you accept credit cards, you already have to comply. Look up the PCI-DSS, and note that Visa/MC already require everything that was in this bill. Note too that Visa/MC already reserve the right to "fine" you for noncompliance (if you have a merchant account) up to $500,000.00 USD.
Yet most small businesses have *no* idea what is required of them. This passage of the law would have helped businesses avoid problems which could put them out of business.
Please note that my business is fairly small and most of my customers are small to midsize buinesses. I sympathize with the concern over too much regulation but this particular case is something which would not have added practical regulatory issues and would have helped publicize what credit card merchants are required to do anyway.
In fact, the requirements are basically copied from the PCI-DSS 1.1 which Visa/Mastercard require compliance with anyway (and reserve the right to "fine" you for up to half a million dollars for losses of credit card numbers if you fail to comply).
This is at best political posturing and at worst a dangerous illusion for small businesses.
If you have a noncompliant system today, whether or not this law would have been signed, and its problems resulted in the theft of a credit card number, your small business could be fined up to $500,000 by Visa/Mastercard.
That is the cost (right now) of noncompliance. So the solution to your question is-- do your homework, evaluate what you have, and get the right system.
Actually, security is as big an issue for larger businesses. You have legacy systems built when nobody foresaw the sorts of security threats we have today, and a *lot* of data is still stored in them. Some of those systems probably store data no longer allowed by the PCI-DSS.
The goal ought to be to help build awareness of PCI-DSS compliance and help all businesses become compliant.
Most of my customers are small businesses which also process credit cards. What you have to remember is the controversial portions of the law are *already* requirements for small businesses which process credit cards. I invite you to read the PCI-DSS 1.1 (and yes, there are a lot of non-compliant small businesses out there).
Now the PCI-DSS does not really have the force of law at the moment, but it might as well. Visa/Mastercard reserves the right to fine merchants up to half a million dollars for violations resulting in theft of sensitive cardholder information. Many smaller fines are levied against businesses who are required to certify their compliance with third parties (these are either larger businesses or those who have had past problems).
This isn't about an attack on smaller businesses. Businesses *should* be doing this already. If they don't they are already risking their continued operations. Hopefully such a law would help build awareness of these sorts of problems and help small businesses actually avoid problems. Yes, compliance is a bear, but already the costs of noncompliance, as levied by Visa/Mastercard are sufficient to drive small businesses out of business.
I would check out who you contact at Visa/Mastercard. This is a pretty serious violation of security reqirements, and the hotel chain could be fined substantially for the lapse in security. Note that if you have the full credit card number and the customer's address, you can basically get AVS-type queries to pass. I would suggest helping ensure that it gets turned in to Visa/Mastercard.
I am not quite sure what the fine is for something like this, but the maximum (when credit card numbers are actually stolen) is about half a million dollars per incident.
Slashdot Mirror
I have often found South America to be sort of interesting in these ways. I offered to pay tarrifs on a computer I was giving to a friend in Ecuador back in 2001, and the customs officials laughed at me. I was told that, no, I didn't have to pay tarrifs and that everything was fine (after the embassy told me to pay 40% of the value as a tarriff!)
I suspect things are a little different now with the new movement centered around Chavez and De Silva (not that they are on the same track-- the only real shared emphasis seems to be in regional economic development-- also with Correa joining that, I think there is a good chance that Chavez will find himself more or less sidelined). While South America is not what it was 7 years ago, it is probably on the track to becoming something better. There is a trend toward coming down *hard* on foreign companies that break the law, and this is probably a good thing (at least in Brazil and Ecuador, neither country seems to endorse the same sort of socialization as Venezuela or Bolivia, and even Bolivia is a very different situation than Venezuela).
BTW, this might be slightly off-topic, but I have been very heartened by the adoption of LedgerSMB in both Venezuela and Columbia. I expect Ecuador, Brazil, and other areas to follow suit as our software becomes more mature. I think that the way forward for most of the world is in open source and my business is committed to helping make that happen.
"Open Source" is somethng the OSI wants to try to suggest they can enforce but it has 10 years or so of generic use now and given that only a tiny fraction of open source licenses are OSI-approved, I somehow doubt that one couldn't argue well that the trademark had been diluted to the point of being worthless. IANAL, though.
Open Standards is clearly generic.
Microsoft already has a few projets under these licenses. The Sharepoint Learning Toolkit (or whatever it is called) is under the MS Reciprocal License. The ASP.Net Ajax Control Kit, and so forth.
So yes, they have already been using these licenses.
They have also released works under other licneses (WiX, under the CPL, for example).
The patent rights go away (and you lose the right to *use* the software) if you breech the license.
:-)
THat is one thing I really like about the GPL v2
Give me one example of OSS that is not FLOSS.
There is the reciprocal public license that the FSF considers to be non-Free but only because of a very minor technicality.
However, I can't think of any substantive instance where there is a real disagreement.
MS-RL is more like the MPL than the GPL v2. There is only limited compatibility between either of these licenses and the GPL v2, and bigger issues with the GPL v3.
First the MS-RL (MS-Reciprocal License, not the Reference License), applies to any of your files that contain the code.
The MS-PL applies only to the code you licensed. It is designed to be similar to the BSDL, requiring you to sublicense that code only under the terms of the original license, while you can license your *own code* under any terms you want. It is unclear whether or not this is GPL v3 compatible (there is some limited compatibility of both licenses with the GPL v2 provided that they are not ditributed as part of the same work). IANAL though.
isn not exactly the paragon of Freedom as in Free Speech either. As much as Debian may be a dysfunctional democracy, they are better at consistantly addressing this issue than the FSF.
Ever wonder why the GFDL has the invariant sections clause? According to Stallman himself (in a post to debian-legal), it was because he wanted to *force* the distribution of the GNU Manifesto with the Emacs manual. This essentially turns the ideal of free speech on its head by creating a situation where forced advocacy is accepted. When the then-main-architect of HURD criticized the decision, Stallman asked him to resign. If this is the sort of Stallmanist "Free Speech" we are to associate with Free Software, I want nothing to do with it.
Debian did the right thing and to this day considers any GFDL work containing invariant sections to be non-Free.
Note that I am not a Debina Developer, and I think that at the end we should think for ourselves and not be groupies of RMS or anyone else.
Interestingly the OSI's Open Source Definition is derived from an attempt to define the FSF's 4 freedoms.
The lineage goes from the FSF to Debian (and the Debian Free Software Guidelines) to the OSI's Open Source Definition (which were mostly copied from the DFSG).
If you read the MS-Reciprical License and the MS-PL, you will see that they don't provide any restrictions on use, so this distinction doesn't really matter anyway.
A single power cutoff to all three computers should not have passed a design review. Yes, you will probably always have some single point of failure somewhere (or at least a possibility that a single event can disrupt both primary and secondary systems), but you design your way out of it, and you ensure that all designs are adequately reviewed.
This is not a tricky problem, but these sorts of errors do happen no matter how much you do. However, when they do, it is because someone missed something in the review process.
The most important problem is that the triply redundant system was not triply redundant and had a single power-off command.
Humidity was a big issue, and arguably more could hae been done in this area, but if it was the only one, it wouldn't have triggered the problem.
The issue in this case was at least in part a failing dehumidifier. So in reality there is would seem to be more than enough blame to go around relating to the condensation.
However, the big issue is the fact that there was a single point of failure for this supposedly triply-redundant system. *That* seems t be the Russians' fault pure and simple.
I would also add that the PCI-DSS is not the beginning and end of preventing cardholder information compromises. I think that some new regulation is required, not for the retailers, but for the acquirers.
Basically, I think that the PAN should be barred from being saved and that the acquirer should take on that responsibility. They are in a better position to manage such security issues anyway, and there are better ways of doing this anyway. For example, why not handle recurring payments as keyed to the original approval code instead of the PAN? The approval code is then tied to a merchant account and so is non-reusable in the same way. Barring that, I think that the payment gateway should hold the information.
http://usa.visa.com/merchants/risk_management/cisp_overview.html?it=c|/merchants/risk_management/cisp.html|How%20to%20Comply#anchor_2 but this does not mention the amount fined.
Wells-fargo mentions the scope of fines here https://www.wellsfargo.com/biz/merchant/service/manage/associations/news and it seems my information may have been out of date. The fines are still pretty hefty.
They are basically cut and pasted from the requirements that the payment card industry places on merchants anyway. V/MC "levy fines" of up to a half a million dollars in the event of noncompliance which results in credit card data theft. This law would have helped buisnesses avoid fines which would result in bankrupcy by helping them understand what they were required to do.
The basic thing is that another multinational enforces a contractual provision against all merchants big and small, doing business in various parts of the world. That multinational is Visa/Mastercard. And they levy fines of up to $500,000.00 USD for noncompliance.
All this law would have done practically speaking would have been to encourage small businesses to protect data properly. Right now, I don;t think most of them know what they are required to do. It is a shame and nothing more than political posturing which creates a dangerous illusion.
That problem mostly affects large businesses only (i.e. those who can afford to talk directly to the V/MC network and skip the gateway). And the cost of compliance there is *huge.*
For smaller businesses, generally this is handled via the acquirer (in the case of a small credit card processing terminal) or the payment gateway (like Authorize.net or TrustCommerce). There is no reason to store the credit card number beyond the initial approval there.
Note furthermore, that you *can* store the credit card number indefinitely under PCI-DSS provided that it is encrypted. You cannot however store (subsequent to authorization) anything including or containing: The PIN number or PIN block, the CVV2 (printed on the plastic) or the CVV (contained in the track data).
So, for example, one option to handling internet down issues is:
1) Track data is encrypted with public key at the POS server after being transferred via ssl to that system then inserted into db. If the key does not exist, we ask a separate process to generate and store keys.
2) When internet connection comes back up, a spool process (accepts the private key from a USB device, decrypts the track data, submits it for approval, and then deletes it. When this is done, the private key is deleted. The key is appropriately protected and file access is audited.
The PCI-DSS 1.1 states: 5.1: Deploy anti-virus software on all systems commonly affected by viruses (particularly personal
computers and servers)
Note: Systems commonly affected by viruses typically do not include UNIX-based operating
systems or mainframes.[emphasis mine] Next time someone complains about the PCI-DSS requiring antivirus software on Linux/UNIX systems, you can point them to the fact that the standard specifically excluded these systems from the antivirus requirements.
If you accept credit cards, you already have to comply. Look up the PCI-DSS, and note that Visa/MC already require everything that was in this bill. Note too that Visa/MC already reserve the right to "fine" you for noncompliance (if you have a merchant account) up to $500,000.00 USD.
Yet most small businesses have *no* idea what is required of them. This passage of the law would have helped businesses avoid problems which could put them out of business.
Please note that my business is fairly small and most of my customers are small to midsize buinesses. I sympathize with the concern over too much regulation but this particular case is something which would not have added practical regulatory issues and would have helped publicize what credit card merchants are required to do anyway.
the issue of compliance goes away.
In fact, the requirements are basically copied from the PCI-DSS 1.1 which Visa/Mastercard require compliance with anyway (and reserve the right to "fine" you for up to half a million dollars for losses of credit card numbers if you fail to comply).
This is at best political posturing and at worst a dangerous illusion for small businesses.
You are missing a very basic fact---
If you have a noncompliant system today, whether or not this law would have been signed, and its problems resulted in the theft of a credit card number, your small business could be fined up to $500,000 by Visa/Mastercard.
That is the cost (right now) of noncompliance. So the solution to your question is-- do your homework, evaluate what you have, and get the right system.
Actually, security is as big an issue for larger businesses. You have legacy systems built when nobody foresaw the sorts of security threats we have today, and a *lot* of data is still stored in them. Some of those systems probably store data no longer allowed by the PCI-DSS.
The goal ought to be to help build awareness of PCI-DSS compliance and help all businesses become compliant.
Most of my customers are small businesses which also process credit cards. What you have to remember is the controversial portions of the law are *already* requirements for small businesses which process credit cards. I invite you to read the PCI-DSS 1.1 (and yes, there are a lot of non-compliant small businesses out there).
Now the PCI-DSS does not really have the force of law at the moment, but it might as well. Visa/Mastercard reserves the right to fine merchants up to half a million dollars for violations resulting in theft of sensitive cardholder information. Many smaller fines are levied against businesses who are required to certify their compliance with third parties (these are either larger businesses or those who have had past problems).
This isn't about an attack on smaller businesses. Businesses *should* be doing this already. If they don't they are already risking their continued operations. Hopefully such a law would help build awareness of these sorts of problems and help small businesses actually avoid problems. Yes, compliance is a bear, but already the costs of noncompliance, as levied by Visa/Mastercard are sufficient to drive small businesses out of business.
I would check out who you contact at Visa/Mastercard. This is a pretty serious violation of security reqirements, and the hotel chain could be fined substantially for the lapse in security. Note that if you have the full credit card number and the customer's address, you can basically get AVS-type queries to pass. I would suggest helping ensure that it gets turned in to Visa/Mastercard.
I am not quite sure what the fine is for something like this, but the maximum (when credit card numbers are actually stolen) is about half a million dollars per incident.
connection TERMINATED with error: 404.