WINE used to be under the GPL, but due to other considerations was moved to the LGPL (not related to licensing, more related to promoting contributions).
The basic thing is-- the GPL uses the term "based on" in several places. IANAL, but my reading of the current copyright law in the US suggests that "based on" has a very specific meaning which is quite different than the way RMS and Linus use it. "Based on" as in "this movie is based on the following book" implies transforming one work into another through a creative process. This is the same standard and definition of "derivative work" which is fundamentally different than a "collected" or "compiled" work under copyright law (linking seems to my mind to create the latter, not the former).
However you have evidently never tried to go to your store and pick out a Linux-compatible wireless network card off the shelf. Please try this and then get back to me.
Back to my original point-- this is something that NDISwrapper could conceivably get Linus to back down if they play their cards right:
1) Distribute a patch that unblacklists the driver. 2) Get distros like OpenSUSE which distribute NDISWrapper to include the patch in their kernels. 3) Get repostitories like Livna to include the patch. 4) Start working on organizing political pressure from various distros to include the patch in the official kernel.
Yes, I think it can be done. No I don't think that ndiswrapper is in the wrong here.
Finally, I do prefer open source drivers, but if you can't tell whether a driver is available based on available information without a *lot* of work (and likely buying the card, doing an lspci on it, looking up the chipset), then you simply can't complain about having a safety measure. Unless of course, you don't buy wireless PCMCIA cards and don't want the rest of us to either....
People who think NDISWrapper is a bad idea have generally never tried to determine whether a wireless card is Linux-compatible by looking at the box on the shelf. No, it is not my first choice, but I am really glad it's there.
I think in this case, I see no issues with ndiswrapper, even absent a linking exception.
The NDIS drivers are not in any way based on the GPL code, and the NDISwrapper is not in any way based on any of those specific drivers. So I don't see what the issue is. It is the same issue which has been hashed out over and over in SCO v. IBM relating to whether JFS is a derivative of Sco's purported copyrights. The answer has clearly been "no" for much the same reason, even before Novel won the judgement relating to the copyrights.
Note: This is not a GPL issue with respect to the Linux kernel; if it's a GPL issue at all, it is with NDISWrapper not validly being able to use the GPL, and if that is the case, then they should not be allowed to access the GPLONLY symbols.
Actually I read it as an issue of Linus saying that ndiswrapper shouldn't have access to these symbols, not a specific legal licensing issue. I don't see Linus making any claims about NDISWrapper's licensing.
Since it is not a licensing issue, it seems to me that the easy way forward is for ndiswrapper to include a patch which restores this access and require that patch be included on the kerenels on which it runs. This just means that distros have to build their kernels with that patch. Sooner or later, pressure will build to get the functionality merged back into the main kernel.
That seems the obvious, easy, and safe way forward.
In addition to getting a lawyer, you also want to get other OpenNMS copyright holders (particularly the commercial companies) in the loop. This helps increase the leverage and the resources available to fight. And they will bring in more lawyers, in all liklihood.
Well, the other thing is that the desired development model is entirely different. Linux tends to support cheap process creation and optimize for that. The NT kernel is really optimized for single process, multithreaded applications which use things like async I/O. So yes, you can get the software to run from one to the other, but the performance overhead of running on the wrong platform could be substantial under load.
We track inventory on a perpetual basis, which means there has to be some basic double-entry accounting logic in it.
1 line per item relating to inventory vs COGS 1 summary line for AR debits 1 line for tax --- 1 summary line for AR credit on payment 1 line per payment to appropriate asset account etc.
This means that once a week they can just import the financial data into Quickbooks and track inventory on a perpetual basis. If you are doing periodic inventory, you probably could provide more separation between your accounting and POS systems, however.
Agreed for the most part, but my main point is that compliance is a matter of reading the standard and making sure that: 1) Required documentation is maintained. 2) All appropriate security measures are in place. 3) Any required security measures which are not appropraite for one's environment are documented and justified.
It isn't like this requires thousands of dollars and some special certification group (certification requirements are separate from compliance requirements). It does however, require a few hours of time and basic understanding of computer security issues.
Because the database is as dreadful as the Perl code.
Oh, and I missed one thing about the Perl code. Use of cute, short variable names like $a and $b (*really* bad ideas since they are reserved in the language).
Here is what we are doing: 1.3 will have a new framework we developed for this purpose. It is clean, database-centric, flexible, and enforces importand boundaries in the program. We basically are refactoring with a chain saw. We cut out a section. Redesign the database from scratch. Rewrite the code from scratch, move onto another section. In 1.3, all of the contact management, and some of the financial logic will be moved onto the new framework. In 1.4, all of the financial logic will be on the new framework. We didn't use existing MVC implementations because the way they abstract database logic suggests that it encourages bad db design.
1) I didn't realize how bad it was until about 2 months after we forked. 2) I had customers running SL and wanted to get serious security issues for them fixed without waiting for years to get a replacement ready.
Here are some choice decisions on the part of SL: 1) Use of logins as session keys, and timestamps as session validation values (which were only validated in the sense that "this is a recent time"). This was fixed after we forked. 2) some_function(\%$form, \%myconfig); 3) In one report, he pulls litterally every invoice from the database, does some calculations in Perl, filters them in the CGI script, and then procedes to build the page. 4) No protection against SQL injection attacks (we fixed this in LSMB 1.2) 5) Interesting ideas about code structure (wandering code logic, etc). 6) Interesting ideas about security beyond #1 above. For example, the template editor could be used to do all sorts of cool things (like change other people's passwords) 7) No data integrity constraints (you know it is bad when it takes us over a year to get referential integrity enforcement working on the database) 8) Interesting ideas about database design which allow for equally interesting data integrity problems beyond mere foreign key constraints.
I am sure there are more. But we are now ripping out the all the old code and rewriting which is what we need to be doing now.
PABP does not apply to software which is not developed for sale. Such in-house software is covered instead under PCI-DSS. Open source software would also seem to be exempt from the certification requirements under PABP there unless it was sold.
No, you are missing my point. Being compliant means having your network and systems up to PCI-DSS standards. Certification (or self-certification) is an entirely different issue.
For a small vendor like this, the question is not the certification, it is what happens if something goes wrong, and you have an employee who, say, steals credit card numbers. At this point a few things are going to happen: 1) Compliance will be assessed by Visa/Mastercard. 2) You will be bumped up to the top tier in compliance certification requirements. 3) If you are not compliant, you will be charged an additional "fine" by Visa/MC up to half a million dollars.
For a small vendor, this means that you really need to read, understand, and implement the standards. That is a substantial amount of work and a substantial price if you screw up.
The vendors *need* to take the PCI-DSS compliance issue very seriously regardless of whether self-certification is acceptable.
My point is that it is *really* easy to underestimate how much data you have to be able to handle.
For a tiny business with 2 cash registers, 1M records in a year is a *lot* more than one would likely expect. Generally at that point you may want to start thinking about the possibility of table partitioning, partial indexes, and the like. It also means that when you run complex reports, it might be a good idea to run them off a replica so you don't tie up the main server.
Otherwise you can introduce performance issues into your point of sale system which is a big no-no.
You are right-- it is not a lot of data on the enterprise scale, but it is enough to make the design a bit harder for even a small isntallation, and it introduces scalability issues in larger deployments if you aren't careful.
If the Bush administration could tap everyone's phone without a warrant, maybe they would be able to get information from some random guy as to the real root of this crash. Therefore the crash is clearly the fault of the Democrats who let this bill expire.
Build a system which is heavily optimized for work flow, which can be used fast, has no performance problems, gives all the data you want when you want it, etc.
I mean, all the pieces are easy, but it is hard to get right.
Besides, point of sale solutions are really challenging.
1) You have to heavily optimize the workflow for your industry. You dont want to slow down the sale, right? 2) You have to ensure the data is stored in an accurate way. 3) Performance issues just can't crop up. 4) The amount of data that these systems store will probably amaze you. I have one customer running a 2-till store that puts in almost a million rows of data into one table every year.
Small business systems actually are quite flaky - unless you're shop is using a well-designed vertical market system tailored for your shops needs. Yeah, tell me about it.....:-( I hve spent a lot of time struggling with insane codebases in these sorts of areas. I have concluded that an aweful lot of this software was not designed by competent people.
One project (which is usable but still a little flakey now but which we expect to make robust as we go forward) is LedgerSMB. I would suggest you take a look at our origins, our progress on key issues (maintainability, security, spooky action at a distance), and consider us for future use. BTW, we forked from SQL-Ledger. Past Slashdot comments on that program should give you an idea what we were up against...
One of our main principles going forward is to separate interface from workflow, and both of these from core logic. This way you *will* be able to improve lots of things easily without worrying about spooky bugs that you may never be able to track down. In the mean time we settle for trying to help others grok the codebase which some have nominated for worst ever.
LedgerSMB is an accounting system with invoicing and timecard capabilties. It also happens to have a POS module.
That is really what you need is something which is conscious of all the information. That way if you need to sync with the latest Quickbooks, the data is there.
Slashdot Mirror
The basic thing is-- the GPL uses the term "based on" in several places. IANAL, but my reading of the current copyright law in the US suggests that "based on" has a very specific meaning which is quite different than the way RMS and Linus use it. "Based on" as in "this movie is based on the following book" implies transforming one work into another through a creative process. This is the same standard and definition of "derivative work" which is fundamentally different than a "collected" or "compiled" work under copyright law (linking seems to my mind to create the latter, not the former).
In principle I agree with you.
However you have evidently never tried to go to your store and pick out a Linux-compatible wireless network card off the shelf. Please try this and then get back to me.
Back to my original point-- this is something that NDISwrapper could conceivably get Linus to back down if they play their cards right:
1) Distribute a patch that unblacklists the driver.
2) Get distros like OpenSUSE which distribute NDISWrapper to include the patch in their kernels.
3) Get repostitories like Livna to include the patch.
4) Start working on organizing political pressure from various distros to include the patch in the official kernel.
Yes, I think it can be done. No I don't think that ndiswrapper is in the wrong here.
Finally, I do prefer open source drivers, but if you can't tell whether a driver is available based on available information without a *lot* of work (and likely buying the card, doing an lspci on it, looking up the chipset), then you simply can't complain about having a safety measure. Unless of course, you don't buy wireless PCMCIA cards and don't want the rest of us to either....
People who think NDISWrapper is a bad idea have generally never tried to determine whether a wireless card is Linux-compatible by looking at the box on the shelf. No, it is not my first choice, but I am really glad it's there.
The NDIS drivers are not in any way based on the GPL code, and the NDISwrapper is not in any way based on any of those specific drivers. So I don't see what the issue is. It is the same issue which has been hashed out over and over in SCO v. IBM relating to whether JFS is a derivative of Sco's purported copyrights. The answer has clearly been "no" for much the same reason, even before Novel won the judgement relating to the copyrights.
So by your idea, writing Windows-only GPL software should be....?
Note: This is not a GPL issue with respect to the Linux kernel; if it's a GPL issue at all, it is with NDISWrapper not validly being able to use the GPL, and if that is the case, then they should not be allowed to access the GPLONLY symbols.
Actually I read it as an issue of Linus saying that ndiswrapper shouldn't have access to these symbols, not a specific legal licensing issue. I don't see Linus making any claims about NDISWrapper's licensing.
Since it is not a licensing issue, it seems to me that the easy way forward is for ndiswrapper to include a patch which restores this access and require that patch be included on the kerenels on which it runs. This just means that distros have to build their kernels with that patch. Sooner or later, pressure will build to get the functionality merged back into the main kernel.
That seems the obvious, easy, and safe way forward.
In addition to getting a lawyer, you also want to get other OpenNMS copyright holders (particularly the commercial companies) in the loop. This helps increase the leverage and the resources available to fight. And they will bring in more lawyers, in all liklihood.
Well, the other thing is that the desired development model is entirely different. Linux tends to support cheap process creation and optimize for that. The NT kernel is really optimized for single process, multithreaded applications which use things like async I/O. So yes, you can get the software to run from one to the other, but the performance overhead of running on the wrong platform could be substantial under load.
However that is the past. Today, FOSS does this far better than Microsoft. In some ways, Microsoft is being beat at their own game.
Seriously: M-x tetris and see for yourself.
We track inventory on a perpetual basis, which means there has to be some basic double-entry accounting logic in it.
1 line per item relating to inventory vs COGS
1 summary line for AR debits
1 line for tax
---
1 summary line for AR credit on payment
1 line per payment to appropriate asset account
etc.
This means that once a week they can just import the financial data into Quickbooks and track inventory on a perpetual basis. If you are doing periodic inventory, you probably could provide more separation between your accounting and POS systems, however.
Agreed for the most part, but my main point is that compliance is a matter of reading the standard and making sure that:
1) Required documentation is maintained.
2) All appropriate security measures are in place.
3) Any required security measures which are not appropraite for one's environment are documented and justified.
It isn't like this requires thousands of dollars and some special certification group (certification requirements are separate from compliance requirements). It does however, require a few hours of time and basic understanding of computer security issues.
$a and $b are variables which expose the inner workings of sort().
$i and $j for things like iterators is OK, but $a and $b should be avoided....
Because the database is as dreadful as the Perl code.
Oh, and I missed one thing about the Perl code. Use of cute, short variable names like $a and $b (*really* bad ideas since they are reserved in the language).
Here is what we are doing:
1.3 will have a new framework we developed for this purpose. It is clean, database-centric, flexible, and enforces importand boundaries in the program. We basically are refactoring with a chain saw. We cut out a section. Redesign the database from scratch. Rewrite the code from scratch, move onto another section. In 1.3, all of the contact management, and some of the financial logic will be moved onto the new framework. In 1.4, all of the financial logic will be on the new framework. We didn't use existing MVC implementations because the way they abstract database logic suggests that it encourages bad db design.
By 2.0, we will be free of the code.
1) I didn't realize how bad it was until about 2 months after we forked.
2) I had customers running SL and wanted to get serious security issues for them fixed without waiting for years to get a replacement ready.
Here are some choice decisions on the part of SL:
1) Use of logins as session keys, and timestamps as session validation values (which were only validated in the sense that "this is a recent time"). This was fixed after we forked.
2) some_function(\%$form, \%myconfig);
3) In one report, he pulls litterally every invoice from the database, does some calculations in Perl, filters them in the CGI script, and then procedes to build the page.
4) No protection against SQL injection attacks (we fixed this in LSMB 1.2)
5) Interesting ideas about code structure (wandering code logic, etc).
6) Interesting ideas about security beyond #1 above. For example, the template editor could be used to do all sorts of cool things (like change other people's passwords)
7) No data integrity constraints (you know it is bad when it takes us over a year to get referential integrity enforcement working on the database)
8) Interesting ideas about database design which allow for equally interesting data integrity problems beyond mere foreign key constraints.
I am sure there are more. But we are now ripping out the all the old code and rewriting which is what we need to be doing now.
PABP does not apply to software which is not developed for sale. Such in-house software is covered instead under PCI-DSS. Open source software would also seem to be exempt from the certification requirements under PABP there unless it was sold.
No, you are missing my point. Being compliant means having your network and systems up to PCI-DSS standards. Certification (or self-certification) is an entirely different issue.
For a small vendor like this, the question is not the certification, it is what happens if something goes wrong, and you have an employee who, say, steals credit card numbers. At this point a few things are going to happen:
1) Compliance will be assessed by Visa/Mastercard.
2) You will be bumped up to the top tier in compliance certification requirements.
3) If you are not compliant, you will be charged an additional "fine" by Visa/MC up to half a million dollars.
For a small vendor, this means that you really need to read, understand, and implement the standards. That is a substantial amount of work and a substantial price if you screw up.
The vendors *need* to take the PCI-DSS compliance issue very seriously regardless of whether self-certification is acceptable.
For a tiny business with 2 cash registers, 1M records in a year is a *lot* more than one would likely expect. Generally at that point you may want to start thinking about the possibility of table partitioning, partial indexes, and the like. It also means that when you run complex reports, it might be a good idea to run them off a replica so you don't tie up the main server.
Otherwise you can introduce performance issues into your point of sale system which is a big no-no.
You are right-- it is not a lot of data on the enterprise scale, but it is enough to make the design a bit harder for even a small isntallation, and it introduces scalability issues in larger deployments if you aren't careful.
If the Bush administration could tap everyone's phone without a warrant, maybe they would be able to get information from some random guy as to the real root of this crash. Therefore the crash is clearly the fault of the Democrats who let this bill expire.
Ohloh.net is also a good place to look. You can often get better statistics about software development activity, team size, etc. from that site.
Build a system which is heavily optimized for work flow, which can be used fast, has no performance problems, gives all the data you want when you want it, etc.
I mean, all the pieces are easy, but it is hard to get right.
I saw a sig on Slashdot once that really sums up the problem:
Programming is like sex: make one little mistake and support it for the rest of your life.
That is really true of business apps such as POS applications. It is a good idea to know that this is what you want to do before you start.
Besides, point of sale solutions are really challenging.
1) You have to heavily optimize the workflow for your industry. You dont want to slow down the sale, right?
2) You have to ensure the data is stored in an accurate way.
3) Performance issues just can't crop up.
4) The amount of data that these systems store will probably amaze you. I have one customer running a 2-till store that puts in almost a million rows of data into one table every year.
One project (which is usable but still a little flakey now but which we expect to make robust as we go forward) is LedgerSMB. I would suggest you take a look at our origins, our progress on key issues (maintainability, security, spooky action at a distance), and consider us for future use. BTW, we forked from SQL-Ledger. Past Slashdot comments on that program should give you an idea what we were up against...
One of our main principles going forward is to separate interface from workflow, and both of these from core logic. This way you *will* be able to improve lots of things easily without worrying about spooky bugs that you may never be able to track down. In the mean time we settle for trying to help others grok the codebase which some have nominated for worst ever.
LedgerSMB is an accounting system with invoicing and timecard capabilties. It also happens to have a POS module.
That is really what you need is something which is conscious of all the information. That way if you need to sync with the latest Quickbooks, the data is there.