You want to have a strong program before you start adding a non-profit on top of it. Being too process-heavy from the start will only slow down development and drive away talent.
However, I think you should re-think the money side of it. There really is a lot of money to be made in open source POS solutions both in terms of development and in terms of implementation. If you can make money by shipping systems and implementing them, you can pay developers to add things you need to add.
The LedgerSMB project hasn't actually come up with a funding mechanism yet because allof us are making money independantly off the software. However, if you did want to help fund some advertising, promotion, or specific areas of development, we could facilitate this even if we have a lot of work already on our plates.
Aside from the Escape/Meta-Alt-Ctrl-Shift and Eighty-Megs-At-Startup jokes, why is it a bad thing to have a text editor which includes the rest of the operating environment in it (from the games to the web browser)?
Then again, some of us don't want an operating system that thinks it is a text editor....
I would suggest that a good counterexample is LedgerSMB.
I started my business a few years before the fork, with the aim of helping businesses use open source software. We did a number of SQL-Ledger modifications and then the author of the software decided to see me as a burden instead of an opportunity. I ran into a lot of issues with being silently removed from the email list many times, and eventually mostly focused on attracting business through the wiki (I used to run the SQL-Ledger Wiki).
At one point, I was working on a customer's SQL-Ledger instance and I discovered a privelege escallation issue which I reported to the author and got no response. Six months later, the issue was still unfixed and so I did my digging an discovered it was no privelege escallation issue but really an authentication bypass problem. I argued with the author some more but let it go (as I felt like I didn't have the time or energy to run a fork).
Nearly a year after I brought the issue to the author's attention, I finally realized I had to fork because it wasn't going to get fixed. Josh Berkus introduced me to CHristopher Murtagh and the project was born. LedgerSMB was a fork which was mostly mandated by a requirement that I help support my customers, not a hobby project or anything like it. Now we have 3 additional people on the core team, and have released more than 15 releases in the last year, and our userbase is growing by leaps and bounds.
In general, I would suggest that the key issue has to do with having software which is either interesting to geeks or needed by consultants, and it is critical that one build the community around the software.
You can buy all the hardware for a good, efficient retail POS system for about $2000. That includes an LCD monitor, a minimal PC running Linux, a dot matrix receipt printer, a POS keyboard (optionally including magstripe reader), a barcode scanner, a pole display, and a cash drawer. If you need a touchscreen but not the keyboard, barcode scanner, and pole display, add another $300 or so.
In a retail environment you want to input all your data using a barcode scanner and keyboard anyway. Touchscreens not only cost more but make the system slower as people reach between the keyboard (optionally including a trackball) and the touchscreen.
Now, in a coffee shop or restaurant, you need touch screens. This is a different issue.
How does a computer kick open a cash drawer? This is cash-drawer dependant but not really complex. Most of these involve sending commands to the receipt printer or serial ports.
What about CC and ATM cards? Get a card reader that pretends to be a keyboard. That is easy.
However, now you need to read the PCI Data Security Standard and make sure your application is up to snuff... This is anything but trivial.
It will take you couple of weeks to figure out exactly what it should do, and to collect interfaces it will need to talk to. Most of this is not hard. Now, when you start trying to determine what businesses processes you are going to support, and how these are going to work, that is difficult. The interfaces might take a day or so to collect. The processes, on the other hand, may take a lot longer.
1) What is the cashier's workflow? Are you supporting retail, coffee shop, restaurant, or other environments? How do you expect them to use the software?
2) What business requirements do you need to support for the managemnet of data? Are you connecting to another accounting project? Ae you taking over any additional accounting logic? What is handled in your app vs, say, in Quickbooks?
3) What measures need to be in place to support efficient cashier workflow in each of the above situations?
4) What data checking and security measures need to be in place? After all, real money is at stake.
Those questions take *far* longer to answer, and the answers may continue to evolve over time. Chances are the answers will have to come from your prospective customers. Furthermore, this is a very difficult set of questions because, for example, you need it to be as time-efficient for the cashier as possible.
Imagine how much more you would be annoyed if you were in line at the grocery store and the system took 30 extra seconds to open a new invoice...
First, I think the GP is right about most of it, so you need to decide what you are really good at doing. If it is not programming, then don;t do the maintenance part.
If you were instead to, say, join LedgerSMB, we could do the programming for you at a whole lot less that you would have starting the project yourself. You could help the project and we could help you too. If you have funds, pay for features you or your customers need. If not, you can still sell the software and leverage the larger community. But if you can't do the programming, you are going to get stuck really fast.
Moving parts? check (printers, fans, barcode scanners, etc) Databases that can get out of whack? Check File buffers that can cause corruption on a hard shutdown? Check (I have seen businesses lose an entire day's records due to data corruption on P-o-S POS solutions).
Databases that can suddenly introduce performance issues? Check (especially if you use a good and robust RDBMS like PostgreSQL, there are traps you can fall into that can cause sudden and problematic plan changes). Corruption due to failing hardware or environmental issues? Check
Note that such a system is going to hold a lot of data after a while. All manner of things can go wrong. Having someone who understans the entire stack and implementation is critical. Which is what my business does...
L-ane has not had a release in a long time, has SQL injection issues which are not widely published, is a nightmare to maintain, and has some data integrity issues. And it doesn't work with PostgreSQL 8.0 or higher unless you apply special configuration options which are also undocumented (I figured out what they were from reading the code).
Every attempt I have made at working with L-ane has been a maintenance nightmare.
I would second the idea that this should not be something to throw a lot of money at if you don;t know what you are doing.
And if you don't know enough about programming you *will* create something that is hard to maintain. I walked away from my first big FOSS project because it had become unmaintainable. It doesn't take training as the combination of experience and an obsession with learning how to do things right.
A better option is to find an open source project that meets your needs (like LedgerSMB), and hire a programmer to help adapt the software to fit your project's needs. Then sell the full set of hardware together. YOu can pay programmers to make necessary changes (or if you want, you can use this as a way to learn how to program in such an environment well-- note that this will be frustrating and time consuming, however. You can provide technical support (and send back additional requests to programmers), etc.
Your main profit then comes from selling the solution.
I have customers running LedgerSMB in a POS environment. It doesn't handle all environments at the moment (mostly just for retail), but it does work.
In general, you are talking about a system which generates invoices, collects and tracks money coming in and out, etc. Sounds almost like a full accounting system (which is in fact what LedgerSMB is). LedgerSMB is under the GPL v2 or later (no plans at all for moving to the GPL v3).
We inherited a mess of a codebase though and are working on it as quickly as we can. And we welcome contributions (and are willing to share the workload in terms of paid work too).
Please join the LedgerSMB project. Our POS solution at the moment works for retail environments, but there an understanding that we need to build an alternate interface for it. You could be a part of that and enter into a project where there is already a lot of (paid) work and where a lot of the code is in place to do what you want it to do.
LedgerSMB is a full accounting solution. A POS component would merely interface with core accounting logic. It is not a lot of code and could be managed with Perl/Tk, Perl/GTK, or (as we begin seriously on 1.4) any other framework you like as the core accounting data is moving into the database. In six months, hopefully you can have a product that would take yourself years to build, and you can be selling your services for good rates.
As I mentioned, there is a lot of demand for LedgerSMB consultants, and this is expected to go through the roof as get a better POS framework in place. Most of the core team is saturated with work on this project (most of it paid), and so it is an opportunity for others as well.
1) I have seen as many issues with IE7 migrations as issues solved by migrations to IE7.
2) IE7, however, does correct a number of insane deviations from standards that IE6 and earlier made. One notable example is the fact that IE7 submits the button value attribute back to the server instead of the innerHTML (as IE6 and earlier do). Furthermore, before you pull MSDN documnetation to prove me wrong, I will note that MSDN was not updated for some of these changes.
So IE7 breaks backwards compatibility with IE6 in a few areas (and about time...) but Microsoft isn't documenting the browser properly and so I can imagine that web devs are confused.
projects maintained primarily by single organizations.
The other main application relates to reference implementations by large businesses.
However, my main point is that these change when the pace of development remains high for a period of time. In these cases, you either give back, fork, or pay through the nose. Viable open source projects need not fear the BSD license for this reason.
In these specific cases, there are strong technical reasons why the commercial components belong to niche markets.
1) Oracle does certain things which are arguably wrong as relate to NULL handling (even though they obey Codd's rules, they introduce semantic ambiguity into the db structure).
2) Oracle follows some standards in ways which the PostgreSQL community would rather not.
3) A master node in BizgressMPP is hardly a generally applicable piece of software. Over time, open source competitors may surface but they are not going to be part of hte PostgreSQL core distribution.
GIMP still doesn't have CMYK-support but they're working hard on it. Every new feature or bugfix the GIMP developers code goes into the next MIMP release, but none of the MIMP bugfixes or features get handed back to GIMP, except by the 'kindness' of Microsoft. Imagine then that Microsoft gives away MIMP with Vista Home Premium and above as an extra to differentiate it from Home Basic - high market penetration, near-ubiquitous usage... how much developer time will GIMP attract now? What if MS released MIMP for Linux? And that is exactly where things get interesting. You see, as the GIMP team works on their CMYK support, this is going to touch a lot of the same code Microsoft is altering. This means that the complexity of maintaining the patches goes way up, increasing their costs.
You are also assuming that the GIMP changes are inferior to the MIMP changes. If this is the case, it is actually worse for Microsoft, and they are likely going to be forced to fork entirely (and cease using new GIMP enhancements), contribute their changes back, sacrifice features in order to cut costs, or get stuck with skyrocketing development costs. The BSD license is deceptive that way.
How active was ArgoUML before competition got hot?
My theory only works if you can maintain a pace of development for some time in the face of competition and you are willing to really try to compete. If you can't, you get screwed (but you get screwed anyway in this case).
I do not entirely agree with you. While I do agree that competing with a free product can be a challenge, I think that the BSD license makes it easier. If the new product has enough value added and enough branding it can win. OS X is a good example of this. It absorbed a lot of free code and has stolen a good part of the commercial value of those free projects. Part of this is the failure of the BSD+Linux community to make a decent desktop offering but Apple has used the free code it absorbed to make a giant leap forward for itself without pulling the community that created much of that code along with it. Are you telling me that OS X is aimed at the BSD/Linux crowd? Seriously? No. THey are competing with Windows ($$$).
Yes, but they can't redistribute the combined work of "your" code and "their" modifications, in binary form, without redistributing the source to their modifications. That's very significant if their goal is to profit from the combination via redistribution.
The argument goes like this: "Why should you freely benefit from my hard work when I can't benefit from yours?" the BSD camp doesn't care (as far as commercial lockup is concerned) where the GPL camp does.
I am not sure that is a valid concern for a viable project wiht a reasonable pace of development (such as Apache or PostgreSQL. In such a project, it doesn't really matter what commercial versions are developed and what closed source licenses they are under. They can't compete with Free, and witholding contributions, especially when the community wants them, is a good way to drive up one's own costs.
If the community doesn't want PostgreSQL to behave like Oracle in some ways why shouldn't they let EnterpriseDB sell an Oracle compatibility component? In fact this is good for everybody as it helps to attack a viscious competitor and at the same time, generates work on the codebase on behalf of the customers they pull over from Elison's Empire (which, to the extent the community wants it, is donated back to the project).
The argument that the GPL is "restrictive" or "non-free" in the sense that it does not permit the "freedom" to make derived works "non-free" is simply semantic bull feces. Without a license, copyright (at least in the U.S. and similar places) would grant NONE of the freedoms the GPL does. The fact that it does not grant ALL freedoms instead does not make it "restrictive". The fact that it grants many makes it "free" (though "liberal" might be a better adjective).
One of the issues I have with the GPL v3 is that it adds a lot of new restrictions which are both outside the scope of a general purpose software license (Tivoization for example), it seeks to extend itself well beyond the scope of general copyrights (section 7, paragraph 2 requires that licenses allow for sublicensing under the exact terms of the GPL v3 to be compatible).
Note that Tivoization, while slightly more expensive under the GPL3 is still quite possible (by using the aggregation clause to create an environment where the updated application doesn't have anything to talk to because other software components on the other sides of pipes are missing), and a similar scheme (using VMs and hypervisors) can remove access to DRM controls from the GPL'd system.
GPLv2 had a number of weaknesses and I think GPLv3 retains some of them. For example, I once was employed by a company that took much GPL code, made significant enhancements (particularly to the Anaconda installer, and SYSLINUX), redistributed the result, but did not share the enhancements with the "community"... all in accordance with the GPL.
How?
Simple. We DID distribute source to all our recipients of the combined work, some half-dozen of them, for millions of dollars each. Each of them had absolutely no interest in further redistribution, having paid the high price, and so the enhancements effectively stayed "locked up". Pity that: I thought some of them were useful.
I have no problem with charging someone several millions of dollars for the software and then giving them and only them the source in addition.
As far as a GPL-hijacking of BSD code is concerned, it seams to me that the combined derived work can be licensed under the GPL, so long as the original BSD bits (including bits that were deleted) can be extracted and taken private.
This is my problem with GPL v3 compatibility and the BSDL. The license seems to indicate that one cannot do this, while the GPL v2 indicated that one clearly could.
What part of "Portions licensed under the BSD license" is so hard
If you pay me millions of dollars for me to give you a copy of the software, provide support, etc, that is fine. Yes, I have to provide the source, and that is what the poster obviously did.
BTW, in the GPL v3, I see no reason you can't offer beta versions under NDA provided that you state that you do so solely for the purpose of the recipient rendering services (in this case testing) for you. The FSF aside, their license says something other than what they think it says.
Similarly, under the GPL v2, I see *no reason* why I can't distribute the source code under an appropraitely scoped NDA. I could, for example, state that you cannot disclose that you got the source from me, must remove all my trademarks, and the like, but I can't prevent you from distributing the code once you comply with such reasonable restrictions. So you can accomplish anything other than code redistribution control using NDA's and the GPL v2. (THe GPL v2 does not preclude an NDA about my company's business activities regarding GPL'd code-- it just precludes using this to restrict redistribution of the code per se.)
1) No company wants to compete with a Free product. Even one which is merely gratis is problematic (look where Netscape went). Since a proprietary product can only charge for their value adds, they don't get anything by taking the code continuously while never giving back. Note that in the last siven years, I have watched most prioprietary spinnoffs of PostgreSQL die. These include Mammoth PostgreSQL, Pervasive PostgreSQL, and Fujitsu PostgreSQL.
2) Refusing to contribute has serious financial risks in BSDL project. Basicaly, if someone else makes inferior but similar modifications, you end up bearing the burden of managing an increasingly complex changeset across versions. This is extremely draining.
So I think you are mistaken as to whom the second class citizens really are in such a project. Note again, in the PostgreSQL world, those companies that do use the code in their proprietary products successfully give back everything they possibly can (meaning everything the community expresses an interest in making part of the core project). The community as a whole doesn't really want the proprietary bits in BizgressMPP, nor do they want the Oracle compat bits of EnterpriseDB. So everyone is just as happy to let them sell their products.
Slashdot Mirror
You want to have a strong program before you start adding a non-profit on top of it. Being too process-heavy from the start will only slow down development and drive away talent.
However, I think you should re-think the money side of it. There really is a lot of money to be made in open source POS solutions both in terms of development and in terms of implementation. If you can make money by shipping systems and implementing them, you can pay developers to add things you need to add.
The LedgerSMB project hasn't actually come up with a funding mechanism yet because allof us are making money independantly off the software. However, if you did want to help fund some advertising, promotion, or specific areas of development, we could facilitate this even if we have a lot of work already on our plates.
Aside from the Escape/Meta-Alt-Ctrl-Shift and Eighty-Megs-At-Startup jokes, why is it a bad thing to have a text editor which includes the rest of the operating environment in it (from the games to the web browser)?
Then again, some of us don't want an operating system that thinks it is a text editor....
I would suggest that a good counterexample is LedgerSMB.
I started my business a few years before the fork, with the aim of helping businesses use open source software. We did a number of SQL-Ledger modifications and then the author of the software decided to see me as a burden instead of an opportunity. I ran into a lot of issues with being silently removed from the email list many times, and eventually mostly focused on attracting business through the wiki (I used to run the SQL-Ledger Wiki).
At one point, I was working on a customer's SQL-Ledger instance and I discovered a privelege escallation issue which I reported to the author and got no response. Six months later, the issue was still unfixed and so I did my digging an discovered it was no privelege escallation issue but really an authentication bypass problem. I argued with the author some more but let it go (as I felt like I didn't have the time or energy to run a fork).
Nearly a year after I brought the issue to the author's attention, I finally realized I had to fork because it wasn't going to get fixed. Josh Berkus introduced me to CHristopher Murtagh and the project was born. LedgerSMB was a fork which was mostly mandated by a requirement that I help support my customers, not a hobby project or anything like it. Now we have 3 additional people on the core team, and have released more than 15 releases in the last year, and our userbase is growing by leaps and bounds.
In general, I would suggest that the key issue has to do with having software which is either interesting to geeks or needed by consultants, and it is critical that one build the community around the software.
You can buy all the hardware for a good, efficient retail POS system for about $2000. That includes an LCD monitor, a minimal PC running Linux, a dot matrix receipt printer, a POS keyboard (optionally including magstripe reader), a barcode scanner, a pole display, and a cash drawer. If you need a touchscreen but not the keyboard, barcode scanner, and pole display, add another $300 or so.
In a retail environment you want to input all your data using a barcode scanner and keyboard anyway. Touchscreens not only cost more but make the system slower as people reach between the keyboard (optionally including a trackball) and the touchscreen.
Now, in a coffee shop or restaurant, you need touch screens. This is a different issue.
However, now you need to read the PCI Data Security Standard and make sure your application is up to snuff... This is anything but trivial. It will take you couple of weeks to figure out exactly what it should do, and to collect interfaces it will need to talk to. Most of this is not hard. Now, when you start trying to determine what businesses processes you are going to support, and how these are going to work, that is difficult. The interfaces might take a day or so to collect. The processes, on the other hand, may take a lot longer.
1) What is the cashier's workflow? Are you supporting retail, coffee shop, restaurant, or other environments? How do you expect them to use the software?
2) What business requirements do you need to support for the managemnet of data? Are you connecting to another accounting project? Ae you taking over any additional accounting logic? What is handled in your app vs, say, in Quickbooks?
3) What measures need to be in place to support efficient cashier workflow in each of the above situations?
4) What data checking and security measures need to be in place? After all, real money is at stake.
Those questions take *far* longer to answer, and the answers may continue to evolve over time. Chances are the answers will have to come from your prospective customers. Furthermore, this is a very difficult set of questions because, for example, you need it to be as time-efficient for the cashier as possible.
Imagine how much more you would be annoyed if you were in line at the grocery store and the system took 30 extra seconds to open a new invoice...
Best Wishes,
Chris Travers
First, I think the GP is right about most of it, so you need to decide what you are really good at doing. If it is not programming, then don;t do the maintenance part.
If you were instead to, say, join LedgerSMB, we could do the programming for you at a whole lot less that you would have starting the project yourself. You could help the project and we could help you too. If you have funds, pay for features you or your customers need. If not, you can still sell the software and leverage the larger community. But if you can't do the programming, you are going to get stuck really fast.
will break from time to time.
Moving parts? check (printers, fans, barcode scanners, etc)
Databases that can get out of whack? Check
File buffers that can cause corruption on a hard shutdown? Check (I have seen businesses lose an entire day's records due to data corruption on P-o-S POS solutions).
Databases that can suddenly introduce performance issues? Check (especially if you use a good and robust RDBMS like PostgreSQL, there are traps you can fall into that can cause sudden and problematic plan changes).
Corruption due to failing hardware or environmental issues? Check
Note that such a system is going to hold a lot of data after a while. All manner of things can go wrong. Having someone who understans the entire stack and implementation is critical. Which is what my business does...
L-ane has not had a release in a long time, has SQL injection issues which are not widely published, is a nightmare to maintain, and has some data integrity issues. And it doesn't work with PostgreSQL 8.0 or higher unless you apply special configuration options which are also undocumented (I figured out what they were from reading the code).
Every attempt I have made at working with L-ane has been a maintenance nightmare.
I would second the idea that this should not be something to throw a lot of money at if you don;t know what you are doing.
And if you don't know enough about programming you *will* create something that is hard to maintain. I walked away from my first big FOSS project because it had become unmaintainable. It doesn't take training as the combination of experience and an obsession with learning how to do things right.
A better option is to find an open source project that meets your needs (like LedgerSMB), and hire a programmer to help adapt the software to fit your project's needs. Then sell the full set of hardware together. YOu can pay programmers to make necessary changes (or if you want, you can use this as a way to learn how to program in such an environment well-- note that this will be frustrating and time consuming, however. You can provide technical support (and send back additional requests to programmers), etc.
Your main profit then comes from selling the solution.
I now make a good living doing that. Mostly involving LedgerSMB....
The main complaint has to do with making a lot of money on other peoples' labor, which is an entirely different thing.
In that case, you want to sell products, not professional services.
I built my first POS project for about $1000. They still pay me for enhancements (now we want to enter vendor invoices on a PDA...).
Granted I was modifying an existing project. Granted a lot of the hard parts were already done...
And granted that in the two years I have donated probably tens of thousands of dollars worth of labor to the core project we forked (LedgerSMB)....
If I had started from scratch, it would have been $10000 for the first version at least....
the *hardware* for a POS terminal. We haven't even got to software yet.
This is an expensive area. And it is one where timely support is absolutely critical, as is database performance, and the like.
a POS framework needs to do.
I have customers running LedgerSMB in a POS environment. It doesn't handle all environments at the moment (mostly just for retail), but it does work.
In general, you are talking about a system which generates invoices, collects and tracks money coming in and out, etc. Sounds almost like a full accounting system (which is in fact what LedgerSMB is). LedgerSMB is under the GPL v2 or later (no plans at all for moving to the GPL v3).
We inherited a mess of a codebase though and are working on it as quickly as we can. And we welcome contributions (and are willing to share the workload in terms of paid work too).
Please join the LedgerSMB project. Our POS solution at the moment works for retail environments, but there an understanding that we need to build an alternate interface for it. You could be a part of that and enter into a project where there is already a lot of (paid) work and where a lot of the code is in place to do what you want it to do.
LedgerSMB is a full accounting solution. A POS component would merely interface with core accounting logic. It is not a lot of code and could be managed with Perl/Tk, Perl/GTK, or (as we begin seriously on 1.4) any other framework you like as the core accounting data is moving into the database. In six months, hopefully you can have a product that would take yourself years to build, and you can be selling your services for good rates.
As I mentioned, there is a lot of demand for LedgerSMB consultants, and this is expected to go through the roof as get a better POS framework in place. Most of the core team is saturated with work on this project (most of it paid), and so it is an opportunity for others as well.
Best Wishes,
Chris Travers
Can you write that in assembler please?
1) I have seen as many issues with IE7 migrations as issues solved by migrations to IE7.
2) IE7, however, does correct a number of insane deviations from standards that IE6 and earlier made. One notable example is the fact that IE7 submits the button value attribute back to the server instead of the innerHTML (as IE6 and earlier do). Furthermore, before you pull MSDN documnetation to prove me wrong, I will note that MSDN was not updated for some of these changes.
So IE7 breaks backwards compatibility with IE6 in a few areas (and about time...) but Microsoft isn't documenting the browser properly and so I can imagine that web devs are confused.
to be open source.
It does not provide any rights to use the code for anything. Hence it is not open source.
projects maintained primarily by single organizations.
The other main application relates to reference implementations by large businesses.
However, my main point is that these change when the pace of development remains high for a period of time. In these cases, you either give back, fork, or pay through the nose. Viable open source projects need not fear the BSD license for this reason.
In these specific cases, there are strong technical reasons why the commercial components belong to niche markets.
1) Oracle does certain things which are arguably wrong as relate to NULL handling (even though they obey Codd's rules, they introduce semantic ambiguity into the db structure).
2) Oracle follows some standards in ways which the PostgreSQL community would rather not.
3) A master node in BizgressMPP is hardly a generally applicable piece of software. Over time, open source competitors may surface but they are not going to be part of hte PostgreSQL core distribution.
You are also assuming that the GIMP changes are inferior to the MIMP changes. If this is the case, it is actually worse for Microsoft, and they are likely going to be forced to fork entirely (and cease using new GIMP enhancements), contribute their changes back, sacrifice features in order to cut costs, or get stuck with skyrocketing development costs. The BSD license is deceptive that way.
How active was ArgoUML before competition got hot?
My theory only works if you can maintain a pace of development for some time in the face of competition and you are willing to really try to compete. If you can't, you get screwed (but you get screwed anyway in this case).
Yes, but they can't redistribute the combined work of "your" code and "their" modifications, in binary form, without redistributing the source to their modifications. That's very significant if their goal is to profit from the combination via redistribution.
The argument goes like this: "Why should you freely benefit from my hard work when I can't benefit from yours?" the BSD camp doesn't care (as far as commercial lockup is concerned) where the GPL camp does.
I am not sure that is a valid concern for a viable project wiht a reasonable pace of development (such as Apache or PostgreSQL. In such a project, it doesn't really matter what commercial versions are developed and what closed source licenses they are under. They can't compete with Free, and witholding contributions, especially when the community wants them, is a good way to drive up one's own costs.
If the community doesn't want PostgreSQL to behave like Oracle in some ways why shouldn't they let EnterpriseDB sell an Oracle compatibility component? In fact this is good for everybody as it helps to attack a viscious competitor and at the same time, generates work on the codebase on behalf of the customers they pull over from Elison's Empire (which, to the extent the community wants it, is donated back to the project).
The argument that the GPL is "restrictive" or "non-free" in the sense that it does not permit the "freedom" to make derived works "non-free" is simply semantic bull feces. Without a license, copyright (at least in the U.S. and similar places) would grant NONE of the freedoms the GPL does. The fact that it does not grant ALL freedoms instead does not make it "restrictive". The fact that it grants many makes it "free" (though "liberal" might be a better adjective).
One of the issues I have with the GPL v3 is that it adds a lot of new restrictions which are both outside the scope of a general purpose software license (Tivoization for example), it seeks to extend itself well beyond the scope of general copyrights (section 7, paragraph 2 requires that licenses allow for sublicensing under the exact terms of the GPL v3 to be compatible).
Note that Tivoization, while slightly more expensive under the GPL3 is still quite possible (by using the aggregation clause to create an environment where the updated application doesn't have anything to talk to because other software components on the other sides of pipes are missing), and a similar scheme (using VMs and hypervisors) can remove access to DRM controls from the GPL'd system.
GPLv2 had a number of weaknesses and I think GPLv3 retains some of them. For example, I once was employed by a company that took much GPL code, made significant enhancements (particularly to the Anaconda installer, and SYSLINUX), redistributed the result, but did not share the enhancements with the "community"... all in accordance with the GPL.
How?
Simple. We DID distribute source to all our recipients of the combined work, some half-dozen of them, for millions of dollars each. Each of them had absolutely no interest in further redistribution, having paid the high price, and so the enhancements effectively stayed "locked up". Pity that: I thought some of them were useful.
I have no problem with charging someone several millions of dollars for the software and then giving them and only them the source in addition.
As far as a GPL-hijacking of BSD code is concerned, it seams to me that the combined derived work can be licensed under the GPL, so long as the original BSD bits (including bits that were deleted) can be extracted and taken private.
This is my problem with GPL v3 compatibility and the BSDL. The license seems to indicate that one cannot do this, while the GPL v2 indicated that one clearly could.
What part of "Portions licensed under the BSD license" is so hard
There was no GPL violation. IANAL, though.
If you pay me millions of dollars for me to give you a copy of the software, provide support, etc, that is fine. Yes, I have to provide the source, and that is what the poster obviously did.
BTW, in the GPL v3, I see no reason you can't offer beta versions under NDA provided that you state that you do so solely for the purpose of the recipient rendering services (in this case testing) for you. The FSF aside, their license says something other than what they think it says.
Similarly, under the GPL v2, I see *no reason* why I can't distribute the source code under an appropraitely scoped NDA. I could, for example, state that you cannot disclose that you got the source from me, must remove all my trademarks, and the like, but I can't prevent you from distributing the code once you comply with such reasonable restrictions. So you can accomplish anything other than code redistribution control using NDA's and the GPL v2. (THe GPL v2 does not preclude an NDA about my company's business activities regarding GPL'd code-- it just precludes using this to restrict redistribution of the code per se.)
that.
There are two basic things:
1) No company wants to compete with a Free product. Even one which is merely gratis is problematic (look where Netscape went). Since a proprietary product can only charge for their value adds, they don't get anything by taking the code continuously while never giving back. Note that in the last siven years, I have watched most prioprietary spinnoffs of PostgreSQL die. These include Mammoth PostgreSQL, Pervasive PostgreSQL, and Fujitsu PostgreSQL.
2) Refusing to contribute has serious financial risks in BSDL project. Basicaly, if someone else makes inferior but similar modifications, you end up bearing the burden of managing an increasingly complex changeset across versions. This is extremely draining.
So I think you are mistaken as to whom the second class citizens really are in such a project. Note again, in the PostgreSQL world, those companies that do use the code in their proprietary products successfully give back everything they possibly can (meaning everything the community expresses an interest in making part of the core project). The community as a whole doesn't really want the proprietary bits in BizgressMPP, nor do they want the Oracle compat bits of EnterpriseDB. So everyone is just as happy to let them sell their products.