These commercials are great for starving artists. How often do you think a set painter gets to star in a MPAA TV commercial? I bet that pays a lot more than anything else a regular guy can do in Hollywood...
I assume that the MPAA is sufficiently media-savvy to know that if they don't use real, MPAA-employeed, starving artists in these commercials, they'll get torn apart when people determine that the commercials featured well-paid commercial actors funding an expensive lifestyle by pretending to be starving artists (since that's just a bit too easy to figure out).
In fact, MIT's lawyers determined that what the RIAA wanted them to do was illegal, and if there's anything MIT doesn't want, it's lawsuits from the families of students. In order to avoid liability, MIT in fact has to resist the subpoena as much as possible (I'd actually be interested to know if any Northeastern studetns and families are considering suing Northeastern over complying with subpoenas there).
MIT may be willing to comply with a proper subpoena (and, in fact, pretty much has to agree to comply with a truly proper one), but this could be the beginning of a long process. First, the subpoena has to be filed in a court that has jurisdiction over MIT; then they has to be given sufficient time to obey the law regarding informing the students. But it is also possible that subpoenas filed without a judge's approval (which may be done under the DMCA) may be unconstitutional, which is working its way up the court system.
By the time a subpoena reaches MIT which they can follow without being liable to suit by students' families, these students may well no longer be students, and the IP addresses may no longer be theirs, and the records may have been routinely purged.
For that matter, by now the students (who have seen their pseudonyms in the local paper and on slashdot), may have gotten different KaZaa names and IPs, such that when the RIAA gets the proper paperwork through, the address will be registered to one Jack Florey, resident of fifth east, who was just here but left down the stairwell at the other end of the hall... and, of course, the current records will be long gone, per institute policies, as required by federal law.
The passport office could additionally keep a database of all of the signatures they've issued, in which case they can verify that they've produced the signature you're presenting.
Realistically, not all passport checkpoints can be connected to a central database, because some of them are in, for example, Sierra Leone, which doesn't have a reliable connection to the US, or Israel, where they move the checkpoints around based on the events of the day. At least in these situations you can get a good idea of whether the passport is valid with public key cryptography, and people won't bother trying to break the key if their passports will be revealed as forgeries if the reviewer happens to be in contact at that point.
Remember that passports are considered valid photo IDs for lots of non-government applications, and the corner liquor store isn't generally going to want to call up the passport office for each customer, but they could check the signature. Someone isn't going to try to break the passport office's private key and risk being labelled a terrorist just to make fake IDs to buy alcohol, especially if the passport office would be able to identify a passport that showed evidence of a breach of their private key.
Furthermore, if you do purchase a license, you're entering a contract with SCO. They're reasonably likely to decide you violated the terms of it at some point, and sue you, and you're not protected against this by your Red Hat license.
These Law & Order spin-offs just get lamer and lamer...
Re:DirectFB Inherently Insecure?
on
Qt On DirectFB
·
· Score: 1
Actually, The Direct Rendering Manager kernel driver does essentially this, and is the preferred design. Having XFree86 messing with video registers isn't really that great, especially since the kernel will want to know what's happened so that it can change and restore them.
The Open Source developers are also more familiar with the rest of the kernel, and know how to use the library services it provides. They can also start from existing drivers which are mature and deal properly with the kernel. In this case, the advantage of Open Source is that half of your work is already done, whereas you'd have to start from scratch to write a proprietary driver.
Only if you put the box down before you leave. While retail versions of Linux aren't licensed, they are sold. Much like furniture, which isn't licensed, is sold, and you're not allowed to steal it from the store. Once you've bought it, though, you can share it with your friends (except for proprietary applications aggregated with Linux in the package), much like a couch you've bought.
If you want a release date, go for nightly builds. They're always released on time.
The focus on release dates, I think, is due to not allowing access to the code at other times. If you've implemented some functionality, and people want it, and they can't get it because you haven't released the next version, there's pressure to hurry the next version. If anyone can get the current code at any time, there's no reason to change the version number without implementing everything you want to get into this release. Having an official release only makes sense when you've managed to implement and stabilize a chunk of new functionality, and want to make this available to more conservative users. This is not really a function of time.
There isn't native Flash support in any web browser; it's always through a plugin, and plugins never integrate nicely with the browser's normal behavior. Just to be extra annoying, there's no well-publicized external Flash viewer to use outside of the browser, either.
It also gets undeserved flak due to web designers who think that an animation makes a good web site, and it's relatively hard to do alternative renderings of Flash (with SVG, you have some hope of getting the navigation information out and letting people use the site without watching the animation).
It would seem, by SCO's own actions, that anyone with any (or maybe no) code in the affected packages would have grounds to sue SCO for billions of dollars. The FSF in particular could probably claim more money than SCO will ever see.
Of course, SCO should be glad that congress didn't end up passing a law allowing copyright holders to destroy pirates' systems...
It's Microsoft Research. They come up with great ideas, and then pass them off to Microsoft, who then butchers them. Look forward to having to type a 8 letter password in response to a series of 4 broken image links, or in response to 3 images and one of them off the screen, or 4 images scaled so you can't recognize them, or...
("Um, guys, these aren't random inkblots, they're standard icons. Everybody calls then the same thing.")
In fact, preparation for an attack on US soil is wasted effort, in any case, because nobody's going to try that again for a while.
The goal of Al Queda is to get the US out of the middle east, both the US government and US corporate interests. Bin Laden is sufficiently clever to realize that the way to do this is to make it troublesome and dangerous for the US to be in the middle east. Thus, the attack on the USS Cole (making it clear that it's somewhat dangerous to refuel at some otherwise desireable ports), and the attack on the US business executive compound in Saudi Arabia. It's obvious that the US could escape attacks of the same sort by leaving the middle east. The goal of this whole campaign is for the US to decide that the middle east isn't worth the danger. The Sept 11 attacks, on the other hand, were on US soil and outlined a danger to the US without there being an obvious implication that the US could avoid the danger by leaving; they were therefore somewhat different from the usual pattern.
Furthermore, they were a terrible failure. Rather than pushing the US to leave the middle east, they formed the impetus to overthrow Al Queda's puppet government and the beginning of the justification for occupation of a middle eastern country. They also generated world-wide sympathy for the US. They did kill a bunch of Americans (although not more than three days' worth of US smoking deaths), but that's not their end goal.
Their test of terrorism on US soil failed. They've already gone back to attacks on US interests in the middle east. We won't see another attack on US soil at least until Sept 11 and the aftermath is entirely forgotten.
The authors of the Bill of Rights had to start each with "Congress shall make no law", and neglected to add "And congressmen shall not introduce such a bill, either". It's also too bad that "Congress shall have power to enforce this article by appropriate legislation" wasn't introduced until the 13th amendment.
See if you can sell them on the fact that radio play, which is the normal way of getting people interested in buying music, involves people getting a whole lot more than 5 songs for free. And once you have customers, you're not giving them music for free, you're allowing them to pay a variable amount whose minimum you set, with the decision on how much to pay made after the music is heard.
As far as the labels are concerned, you give 5 songs to trial customers to try to get them to join, and after that each song downloaded gets them 33 cents, with a possible top of up to 66 cents. You could say that you'll give them 33 cents per song downloaded, give them up to an extra 66 cents per song downloaded if the music is good, and charge them a mere $1.65 for each new person you expose to their music.
Obviously, this is the same deal as the earlier one, except that you hang on to the part of the $1.65 advertising fee whenever someone isn't 5 songs behind on rating.
If you're dealing with multiple artists/labels, it makes sense to give royalties on a 33 cent purchase for each song, regardless of what the person thought, and divide the remainder between the songs the person liked. That way you don't risk someone not getting any money, even if nobody likes their music, and it's easier for them to account for. The payment mechanism is simply to make the customer feel better, and doesn't change the actual economics meaningfully.
The problem with selling unknown music is that nobody wants to take the risk to pay for music they might not like. If I download a song and listen to it, I've spent several minutes and haven't gotten anything out of it. That's bad enough if I'm not paying anything for the experience.
What you'd ideally like is to give the music to everyone who stops by, and collect money from everyone who likes it. After all, you're probably not going to make a significant amount of money off of people who don't like the music (at least, not long-term), and people who do like the music should feel some obligation to pay for it.
One way to do this would be to require a PayPal account (or something of the sort) to get an account. With an account, you can download songs for free. Once you've downloaded a song, you're asked whether you liked it. You can have up to five songs you haven't rated yet, and then it won't give you more until you've rated those songs. Furthermore, you can't say you don't like more than a third of the songs you've downloaded. You're charged 99 cents for each song you say you like. Of course, if you've already rated a song, you can download it again without anything happening. The artists get to see what you said. You can also change your mind about a song later (you have to pay if you like it and haven't paid before, of course).
So practical upshot of this is: you get at least 33 cents for each song you send, except that each person can get 5 songs without paying. You get more than 33 cents/song if people tend to like your music, up to 99 cents/song. People who are actually fans will probably not refuse to pay, because the artists will know.
Of course, sending 5 songs to people who might never pay anything goes under marketting, much like radio.
The court can only place an injunction on IBM. A different court, in a case in which Linux users or other companies shipping Linux are defendants, could place an injunction on them. It would be possible that the suit against IBM could prevent IBM from shipping Linux machines, of course.
Of course, it is possible that a win against IBM could lead to suits against others. But SCO could at most get IP they own removed, and are much more likely to get themselves countersued by Linux companies who have now been asking for months what they would have to do to avoid violating SCO's IP rights.
Personally, I think if SCO wins their contract suit against IBM, they'll go after MicroSoft next. After all, they have a contract with MicroSoft and they've gotten a settlement out of MicroSoft before.
Personally, I prefer a 75 cent cup of coffee at my local coffeehouse. $3 is a lot to pay each day for something as simple as coffee.
I know people who do a one-week project (longer including collecting pictures and writing text, but a week of "publishing") each year. If you want it to come out nice, you need to give the printers a Quark file, but Quark is a big expense to justify for users who need Quark but not that frequently.
I also know people who use Quark constantly. They're just tired of having Quark crash on them.
"Mozilla, a Web browser that can perform basic workplace tasks." As opposed to IE, which can't? As opposed to IE, which might be a P2P network without telling you?
Browsing the web is, as far as I can tell, a basic workplace task. Mozilla isn't Evolution, GnuCash, a Java GUI, or OpenOffice, which perform specialized workplace tasks. Mozilla is, in fact, included for basic workplace tasks; it's just an odd phrasing that makes it sound like Mozilla ought to design engines or whatever you do in your workplace that isn't basic.
The "something you have" can generally be replicated with sufficient information (if I know the pin positions for your house key, I can make one, and then I have the thing you have). The "something you are" is still impractical to read out of "you" reliably without it being easy to fool with an item, which can be constructed from some information (e.g., you can fool retinal scanners with a photo of the person's eyes with holes for your pupils).
The reason those are considered to be different things is that pairs of them are unlikely to get stolen (or copied) together, whereas two of the same type can generally be stolen at the same time. But in the canonical good example, the ATM card with the PIN, where you have the card and know the PIN, both are actually information; it's just that one is stored in an object and one is stored in your memory.
Actually, having a machine that *isn't* a desktop is much better. What you want is an interface specialized to the task, without any of the distractions. Using a desktop operating system for a call center (or a point-of-sale terminal, or a number of similar applications) is like trying to dial a telephone with a GUI (go to File, then "Make call...", then click on the digits, click Okay...). Linux is ideal for this situation, because you can provide only a custom interface on the front end, and manage the machines entirely remotely.
Get companies who need the software involved
on
Funding Open Source?
·
· Score: 1
The biggest source of funding I see for Open Source development is companies who will contribute developer time in order to make an Open Source project suitable for their use. If your project is nearly good enough for something that some company wants to do, it's more cost-effective for them to pay someone to add the remaining features than to reimplement it in-house from scratch or to try to make a proprietary product work for their purposes.
Of course, this isn't useful for Palm-syncing software, since I doubt there are many companies out there with slightly odd needs with respect to Palm-syncing. It may help for Audigy, though; I bet there are some small labels out there whose needs are not well met by proprietary applications and who would be willing to spend some money to get Audigy to to point where they could use it more effective than what they're now paying to use.
As far as making your project tempting, what matters most is a clear explanation of what it does, how it works, how to use it, and how the internals are arranged; anyone who pays for development of the project has to consider the possibility that they'll end up maintaining the project themselves.
As for whether this model works: I've personally been paid by my company to add a feature to an LGPL package, and we went this route because we could evaluate the Open Source package more effectively and more conveniently than proprietary alternatives, and we could determine that only a small amount of our own effort would be necessary to make this package do everything we needed, while it would take an indeterminate amount of effort by people with different agendae to make other packages suitable, and a lot of our effort to implement the whole thing from scratch.
Slashdot Mirror
Great! Want me to sue you over your use of Windows? I'll split the settlement with you if I get one...
These commercials are great for starving artists. How often do you think a set painter gets to star in a MPAA TV commercial? I bet that pays a lot more than anything else a regular guy can do in Hollywood...
I assume that the MPAA is sufficiently media-savvy to know that if they don't use real, MPAA-employeed, starving artists in these commercials, they'll get torn apart when people determine that the commercials featured well-paid commercial actors funding an expensive lifestyle by pretending to be starving artists (since that's just a bit too easy to figure out).
In fact, MIT's lawyers determined that what the RIAA wanted them to do was illegal, and if there's anything MIT doesn't want, it's lawsuits from the families of students. In order to avoid liability, MIT in fact has to resist the subpoena as much as possible (I'd actually be interested to know if any Northeastern studetns and families are considering suing Northeastern over complying with subpoenas there).
MIT may be willing to comply with a proper subpoena (and, in fact, pretty much has to agree to comply with a truly proper one), but this could be the beginning of a long process. First, the subpoena has to be filed in a court that has jurisdiction over MIT; then they has to be given sufficient time to obey the law regarding informing the students. But it is also possible that subpoenas filed without a judge's approval (which may be done under the DMCA) may be unconstitutional, which is working its way up the court system.
By the time a subpoena reaches MIT which they can follow without being liable to suit by students' families, these students may well no longer be students, and the IP addresses may no longer be theirs, and the records may have been routinely purged.
For that matter, by now the students (who have seen their pseudonyms in the local paper and on slashdot), may have gotten different KaZaa names and IPs, such that when the RIAA gets the proper paperwork through, the address will be registered to one Jack Florey, resident of fifth east, who was just here but left down the stairwell at the other end of the hall... and, of course, the current records will be long gone, per institute policies, as required by federal law.
The passport office could additionally keep a database of all of the signatures they've issued, in which case they can verify that they've produced the signature you're presenting.
Realistically, not all passport checkpoints can be connected to a central database, because some of them are in, for example, Sierra Leone, which doesn't have a reliable connection to the US, or Israel, where they move the checkpoints around based on the events of the day. At least in these situations you can get a good idea of whether the passport is valid with public key cryptography, and people won't bother trying to break the key if their passports will be revealed as forgeries if the reviewer happens to be in contact at that point.
Remember that passports are considered valid photo IDs for lots of non-government applications, and the corner liquor store isn't generally going to want to call up the passport office for each customer, but they could check the signature. Someone isn't going to try to break the passport office's private key and risk being labelled a terrorist just to make fake IDs to buy alcohol, especially if the passport office would be able to identify a passport that showed evidence of a breach of their private key.
Furthermore, if you do purchase a license, you're entering a contract with SCO. They're reasonably likely to decide you violated the terms of it at some point, and sue you, and you're not protected against this by your Red Hat license.
These Law & Order spin-offs just get lamer and lamer...
Actually, The Direct Rendering Manager kernel driver does essentially this, and is the preferred design. Having XFree86 messing with video registers isn't really that great, especially since the kernel will want to know what's happened so that it can change and restore them.
"SCO will hold harmless commercial Linux customers that purchase a UnixWare license against any past copyright violations"
"Hello, RIAA. Please direct further correspondance to this other address."
The Open Source developers are also more familiar with the rest of the kernel, and know how to use the library services it provides. They can also start from existing drivers which are mature and deal properly with the kernel. In this case, the advantage of Open Source is that half of your work is already done, whereas you'd have to start from scratch to write a proprietary driver.
Only if you put the box down before you leave. While retail versions of Linux aren't licensed, they are sold. Much like furniture, which isn't licensed, is sold, and you're not allowed to steal it from the store. Once you've bought it, though, you can share it with your friends (except for proprietary applications aggregated with Linux in the package), much like a couch you've bought.
If you want a release date, go for nightly builds. They're always released on time.
The focus on release dates, I think, is due to not allowing access to the code at other times. If you've implemented some functionality, and people want it, and they can't get it because you haven't released the next version, there's pressure to hurry the next version. If anyone can get the current code at any time, there's no reason to change the version number without implementing everything you want to get into this release. Having an official release only makes sense when you've managed to implement and stabilize a chunk of new functionality, and want to make this available to more conservative users. This is not really a function of time.
There isn't native Flash support in any web browser; it's always through a plugin, and plugins never integrate nicely with the browser's normal behavior. Just to be extra annoying, there's no well-publicized external Flash viewer to use outside of the browser, either.
It also gets undeserved flak due to web designers who think that an animation makes a good web site, and it's relatively hard to do alternative renderings of Flash (with SVG, you have some hope of getting the navigation information out and letting people use the site without watching the animation).
It would seem, by SCO's own actions, that anyone with any (or maybe no) code in the affected packages would have grounds to sue SCO for billions of dollars. The FSF in particular could probably claim more money than SCO will ever see.
Of course, SCO should be glad that congress didn't end up passing a law allowing copyright holders to destroy pirates' systems...
It's Microsoft Research. They come up with great ideas, and then pass them off to Microsoft, who then butchers them. Look forward to having to type a 8 letter password in response to a series of 4 broken image links, or in response to 3 images and one of them off the screen, or 4 images scaled so you can't recognize them, or...
("Um, guys, these aren't random inkblots, they're standard icons. Everybody calls then the same thing.")
In fact, preparation for an attack on US soil is wasted effort, in any case, because nobody's going to try that again for a while.
The goal of Al Queda is to get the US out of the middle east, both the US government and US corporate interests. Bin Laden is sufficiently clever to realize that the way to do this is to make it troublesome and dangerous for the US to be in the middle east. Thus, the attack on the USS Cole (making it clear that it's somewhat dangerous to refuel at some otherwise desireable ports), and the attack on the US business executive compound in Saudi Arabia. It's obvious that the US could escape attacks of the same sort by leaving the middle east. The goal of this whole campaign is for the US to decide that the middle east isn't worth the danger. The Sept 11 attacks, on the other hand, were on US soil and outlined a danger to the US without there being an obvious implication that the US could avoid the danger by leaving; they were therefore somewhat different from the usual pattern.
Furthermore, they were a terrible failure. Rather than pushing the US to leave the middle east, they formed the impetus to overthrow Al Queda's puppet government and the beginning of the justification for occupation of a middle eastern country. They also generated world-wide sympathy for the US. They did kill a bunch of Americans (although not more than three days' worth of US smoking deaths), but that's not their end goal.
Their test of terrorism on US soil failed. They've already gone back to attacks on US interests in the middle east. We won't see another attack on US soil at least until Sept 11 and the aftermath is entirely forgotten.
The authors of the Bill of Rights had to start each with "Congress shall make no law", and neglected to add "And congressmen shall not introduce such a bill, either". It's also too bad that "Congress shall have power to enforce this article by appropriate legislation" wasn't introduced until the 13th amendment.
See if you can sell them on the fact that radio play, which is the normal way of getting people interested in buying music, involves people getting a whole lot more than 5 songs for free. And once you have customers, you're not giving them music for free, you're allowing them to pay a variable amount whose minimum you set, with the decision on how much to pay made after the music is heard.
As far as the labels are concerned, you give 5 songs to trial customers to try to get them to join, and after that each song downloaded gets them 33 cents, with a possible top of up to 66 cents. You could say that you'll give them 33 cents per song downloaded, give them up to an extra 66 cents per song downloaded if the music is good, and charge them a mere $1.65 for each new person you expose to their music.
Obviously, this is the same deal as the earlier one, except that you hang on to the part of the $1.65 advertising fee whenever someone isn't 5 songs behind on rating.
If you're dealing with multiple artists/labels, it makes sense to give royalties on a 33 cent purchase for each song, regardless of what the person thought, and divide the remainder between the songs the person liked. That way you don't risk someone not getting any money, even if nobody likes their music, and it's easier for them to account for. The payment mechanism is simply to make the customer feel better, and doesn't change the actual economics meaningfully.
The problem with selling unknown music is that nobody wants to take the risk to pay for music they might not like. If I download a song and listen to it, I've spent several minutes and haven't gotten anything out of it. That's bad enough if I'm not paying anything for the experience.
What you'd ideally like is to give the music to everyone who stops by, and collect money from everyone who likes it. After all, you're probably not going to make a significant amount of money off of people who don't like the music (at least, not long-term), and people who do like the music should feel some obligation to pay for it.
One way to do this would be to require a PayPal account (or something of the sort) to get an account. With an account, you can download songs for free. Once you've downloaded a song, you're asked whether you liked it. You can have up to five songs you haven't rated yet, and then it won't give you more until you've rated those songs. Furthermore, you can't say you don't like more than a third of the songs you've downloaded. You're charged 99 cents for each song you say you like. Of course, if you've already rated a song, you can download it again without anything happening. The artists get to see what you said. You can also change your mind about a song later (you have to pay if you like it and haven't paid before, of course).
So practical upshot of this is: you get at least 33 cents for each song you send, except that each person can get 5 songs without paying. You get more than 33 cents/song if people tend to like your music, up to 99 cents/song. People who are actually fans will probably not refuse to pay, because the artists will know.
Of course, sending 5 songs to people who might never pay anything goes under marketting, much like radio.
The court can only place an injunction on IBM. A different court, in a case in which Linux users or other companies shipping Linux are defendants, could place an injunction on them. It would be possible that the suit against IBM could prevent IBM from shipping Linux machines, of course.
Of course, it is possible that a win against IBM could lead to suits against others. But SCO could at most get IP they own removed, and are much more likely to get themselves countersued by Linux companies who have now been asking for months what they would have to do to avoid violating SCO's IP rights.
Personally, I think if SCO wins their contract suit against IBM, they'll go after MicroSoft next. After all, they have a contract with MicroSoft and they've gotten a settlement out of MicroSoft before.
Personally, I prefer a 75 cent cup of coffee at my local coffeehouse. $3 is a lot to pay each day for something as simple as coffee.
I know people who do a one-week project (longer including collecting pictures and writing text, but a week of "publishing") each year. If you want it to come out nice, you need to give the printers a Quark file, but Quark is a big expense to justify for users who need Quark but not that frequently.
I also know people who use Quark constantly. They're just tired of having Quark crash on them.
"Mozilla, a Web browser that can perform basic workplace tasks." As opposed to IE, which can't? As opposed to IE, which might be a P2P network without telling you?
Browsing the web is, as far as I can tell, a basic workplace task. Mozilla isn't Evolution, GnuCash, a Java GUI, or OpenOffice, which perform specialized workplace tasks. Mozilla is, in fact, included for basic workplace tasks; it's just an odd phrasing that makes it sound like Mozilla ought to design engines or whatever you do in your workplace that isn't basic.
Who wants afoot? Maybe if it's Luke Skywalker's foot or something. But what people really want to get is ahead...
The "something you have" can generally be replicated with sufficient information (if I know the pin positions for your house key, I can make one, and then I have the thing you have). The "something you are" is still impractical to read out of "you" reliably without it being easy to fool with an item, which can be constructed from some information (e.g., you can fool retinal scanners with a photo of the person's eyes with holes for your pupils).
The reason those are considered to be different things is that pairs of them are unlikely to get stolen (or copied) together, whereas two of the same type can generally be stolen at the same time. But in the canonical good example, the ATM card with the PIN, where you have the card and know the PIN, both are actually information; it's just that one is stored in an object and one is stored in your memory.
Actually, having a machine that *isn't* a desktop is much better. What you want is an interface specialized to the task, without any of the distractions. Using a desktop operating system for a call center (or a point-of-sale terminal, or a number of similar applications) is like trying to dial a telephone with a GUI (go to File, then "Make call...", then click on the digits, click Okay...). Linux is ideal for this situation, because you can provide only a custom interface on the front end, and manage the machines entirely remotely.
The biggest source of funding I see for Open Source development is companies who will contribute developer time in order to make an Open Source project suitable for their use. If your project is nearly good enough for something that some company wants to do, it's more cost-effective for them to pay someone to add the remaining features than to reimplement it in-house from scratch or to try to make a proprietary product work for their purposes.
Of course, this isn't useful for Palm-syncing software, since I doubt there are many companies out there with slightly odd needs with respect to Palm-syncing. It may help for Audigy, though; I bet there are some small labels out there whose needs are not well met by proprietary applications and who would be willing to spend some money to get Audigy to to point where they could use it more effective than what they're now paying to use.
As far as making your project tempting, what matters most is a clear explanation of what it does, how it works, how to use it, and how the internals are arranged; anyone who pays for development of the project has to consider the possibility that they'll end up maintaining the project themselves.
As for whether this model works: I've personally been paid by my company to add a feature to an LGPL package, and we went this route because we could evaluate the Open Source package more effectively and more conveniently than proprietary alternatives, and we could determine that only a small amount of our own effort would be necessary to make this package do everything we needed, while it would take an indeterminate amount of effort by people with different agendae to make other packages suitable, and a lot of our effort to implement the whole thing from scratch.