Apple seems willing to address these objections
on
RMS on APSL
·
· Score: 3
The Apple executives I spoke with seemed very willing to work on the objections that we raised. There is definitely a problem in that the termination clause says Affected Original Code but never defines it. So, you can't really say what code would be terminated and what would not. Defining it better seems to be big deal for them.
Notification is a problem. In general, you can take a Linux distribution and just hack it a bit and re-distribute it, as long as you distribute the source code with it. Notification is a bigger problem when it's part of 100 licenses rather than one. Then you have to find and notify 100 people before re-distributing. Or 1000. That's a good reason to keep it out of our licenses.
I still think you are underestimating the paperwork problem. You will probably have to form a corporation for each individual software project. The corporation will have to pay corporate income taxes, and I think the developers will all have to be voting directors of the corporation (owners, really) and pay their own taxes as well - the international aspect of this will probably make double-taxation a problem. You will need to change directors and officers very often.
Don't start without a lawyer and accountant, or you could be in trouble with the Oz equivalent of the IRS some time later.
Yes, I know that. Unfortunately, the last time I checked it required a serial console to run and did not stand alone. Maybe someday, and more RAM should help.
But 48M? That could be interesting.
Someone says that a PCMCIA adapter is in the works. That's OK, but I'd really like to have all of that RAM in my pocket in a compact package, as with the Everex.
Well, give us a few years and we'll have our cake and eat it too.
I think perhaps Matthew should accept the other, well-tested revenue-capture strategy. Don't make every last thing you produce free. Choose carefully what you want to make free, and use the rest to support your free software. It works for Sendmail Inc., Digital Creations, etc.
I did read your license. I dismissed the "steward" stuff as unworkable and attacked direct revenue licenses in general.
You'd have programmers voting as blocks to get their pet steward elected. You'd have people creating false identities just to get another vote. You'd have elections every week.
Go ahead and try this. You'll have to walk away from your own software within a month or two.
There are a number of places where you can go to work writing free software. Are there enough for everyone? No. I didn't have any proplem with writing proprietary software to support my free software efforts, maybe you should try that.
Can we support an entire industry that makes free software? No. We don't need an industry to do that. Free software's purpose is not to supplant Microsoft. We'd be much better off if we let Microsoft continue to be Microsoft and worked on the things that free software does well.
Lots of people responded that CE isn't a good OS compared to PalmOS (no surprise) and that the batteries ran down, etc.
Put an open, hackable operating system on the box instead of CE and I'd buy it in a minute and deal with the battery problems.
Now, if I could just get the hardware documentation...
What would I put in 48MB? Maps, for one thing. A nice detailed S.F. bay and surrounding communities map with searching would be cool. The rest could be applications and maybe "web channels" for reading news offline.
I'm not getting paid for it, nor do I need to be. I am satisfied with the intangible benefits.
As far as others not contributing, so far I am satisfied that the people who are selling the software are contributing to free software in various ways. Red Hat by funding various free developers, SuSE by funding X drivers, etc.
The IBM license would be fair if they put in a few changes. The developer who contributes his time for free needs to have the right to distribute, modify, sell, and use the program in perpetuity, and the right to pass that privilege on to others. That's the pay-back. IBM's license falls just a bit short of that.
Oh, take an example. Red Hat sells my "Electric Fence". Are they making all of the money from it? But SuSE, Caldera, Debian, etc., all distribute it too. I don't think anyone has cornered the market and is making big bucks on it.
I'd much rather have a job and get an hour an evening to write free software than this, and have to be in combat all the time to keep the steward who gets me paid in place.
And just think about what happens when it goes wrong. Lawsuits between members. The IRS trying to figure out who to collect from.
No, it's not for me. I have a nice closed-source job that pays for me to write Open Source software.
You ask, am I being paid by the trolls? That's not nice. I raised holy hell to get them to change their license. After a year or so, they actually did what I asked them to do and changed it. So, why would they need to pay me?
You've got a point, but not necessarily really the one you wanted to make. I can see this devolving into manipulation about money, with groups working as a block to promote a steward who will be their pet, etc. Much more political and acrimonious than licensing discussions.
Just think about how the taxes would be handled. What a book-keeping mess.
Thanks, but I'm going to continue writing GPL-ed stuff and not get into squabbles over who gets paid what.
I don't think the steward thing is workable. If you think argument about licenses is a mess, argument about the monetary value of someone's contribution is even worse.
If I remember correctly, the NPL gives Netscape special rights over your modifications, because they were already contracted to distribute Navigator under other licenses. The MPL does not. But I'm going by memory.
There's a little Everex WIN CE machine out there that is of reasonable size, has 4MB RAM, and costs $300. I can get a 48MB CompactFlash card and plug it into that for $150 to $200. Now, that's a lot of memory.
As far as I can tell, Palm can't come close to this in either capacity or price.
Not that I'm about to scrap my Palm Pro and do this. If we could ever get an open OS on one of those machines, though, I'd go for it.
The entire purpose of the Alladin license is to make people who want to sell the software buy a commercial license from Peter. It's really the same as the NCL in this respect.
I think they are wrong in saying licensing details don't seem to have had much effect on who participates. I know for sure that entire teams of people have decided to work with Netscape or not based on the license - GNOME considered it very carefully, for example. I've also heard of it on an individual basis. I think they would have done better with GPL or LGPL and advised them so when the NPL was being written, but that's water under the bridge.
No magic bullet? Did they expect microsoft to roll over and die or something? Instantly? The jury is still out.
(Here's a better-formatted version of my previous post)
This license and others like it can be classsified as "Mandiatory Direct Revenue-Capture for the Initial Developer."
It disregards the role of the unpaid collaborator who would add features to your program, because the initial developer has an advantage that the unpaid collaborator can neither obtain nor circumvent. This is a disincentive to the unpaid collaborator because instead of contributing work to the community they are now contributing work that someone else will be paid for no matter what they do. Contrast this to indirect revenue methods. If I don't like Red Hat, I can circumvent them and make my own Linux distribution, obtaining what would have been their profit for myself for some (possibly small) number of customers. Consider this in the case of a product like Linux, where the initial developer contributed a small amount of the total work and his services as an architect and coordinator, while the lion's share of the work was done by others.
It makes collaborative development unwieldy. If every developer insists on their own revenue capture, you would soon have a too-expensive product or a paperwork and procedural mess. Who decides how much each developer gets? Who decides who is worthy as a developer? Do they all make that decision for themselves and then compete with each other in some way?
It gives the initial developer a lock that causes a disincentive to "fork" a product. If Linus had direct revenue-capture from Linux and I decided to make a fork of it because I felt I could engineer it better, I might be able to do an excellent job, but Linus would still be compensated for my effort.
So, to sum it up, I think that direct revenue capture works to the detriment of collaboration.
This license and others like it can be classsified as "Mandiatory Direct Revenue-Capture for the Initial Developer."
It disregards the role of the unpaid collaborator who would add features to your program, because the initial developer has an advantage that the unpaid collaborator can neither obtain nor circumvent. This is a disincentive to the unpaid collaborator because instead of contributing work to the community they are now contributing work that someone else will be paid for no matter what they do. Contrast this to indirect revenue methods. If I don't like Red Hat, I can circumvent them and make my own Linux distribution, obtaining what would have been their profit for myself for some (possibly small) number of customers. Consider this in the case of a product like Linux, where the initial developer contributed a small amount of the total work and his services as an architect and coordinator, while the lion's share of the work was done by others. It makes collaborative development unwieldy. If every developer insists on their own revenue capture, you would soon have a too-expensive product or a paperwork and procedural mess. Who decides how much each developer gets? Who decides who is worthy as a developer? Do they all make that decision for themselves and then compete with each other in some way? It gives the initial developer a lock that causes a disincentive to "fork" a product. If Linus had direct revenue-capture from Linux and I decided to make a fork of it because I felt I could engineer it better, I might be able to do an excellent job, but Linus would still be compensated for my effort.
So, to sum it up, I think that direct revenue capture works to the detriment of collaboration.
The OSD/DSFG allow licenses that want modifications distributed in patches. Patches can be both generated and extracted automaticaly, using them is then no more complicated than using tar files. Debian does all of its modification in patches, for the entire distribution!
Slashdot Mirror
Notification is a problem. In general, you can take a Linux distribution and just hack it a bit and re-distribute it, as long as you distribute the source code with it. Notification is a bigger problem when it's part of 100 licenses rather than one. Then you have to find and notify 100 people before re-distributing. Or 1000. That's a good reason to keep it out of our licenses.
Bruce
Don't start without a lawyer and accountant, or you could be in trouble with the Oz equivalent of the IRS some time later.
Bruce
But 48M? That could be interesting.
Someone says that a PCMCIA adapter is in the works. That's OK, but I'd really like to have all of that RAM in my pocket in a compact package, as with the Everex.
Well, give us a few years and we'll have our cake and eat it too.
Thanks
Bruce
Thanks
Bruce
You'd have programmers voting as blocks to get their pet steward elected. You'd have people creating false identities just to get another vote. You'd have elections every week.
Go ahead and try this. You'll have to walk away from your own software within a month or two.
Bruce
Can we support an entire industry that makes free software? No. We don't need an industry to do that. Free software's purpose is not to supplant Microsoft. We'd be much better off if we let Microsoft continue to be Microsoft and worked on the things that free software does well.
Bruce
Put an open, hackable operating system on the box instead of CE and I'd buy it in a minute and deal with the battery problems.
Now, if I could just get the hardware documentation...
What would I put in 48MB? Maps, for one thing. A nice detailed S.F. bay and surrounding communities map with searching would be cool. The rest could be applications and maybe "web channels" for reading news offline.
You give me the space, I'll find a use for it.
Bruce
As far as others not contributing, so far I am satisfied that the people who are selling the software are contributing to free software in various ways. Red Hat by funding various free developers, SuSE by funding X drivers, etc.
Will this feed me? No. Do I need it to? No.
Commercial viability is not everything.
Bruce
Thanks
Bruce
Bruce
And just think about what happens when it goes wrong. Lawsuits between members. The IRS trying to figure out who to collect from.
No, it's not for me. I have a nice closed-source job that pays for me to write Open Source software.
Bruce
Bruce
The KDE folks addressed this by using the LGPL.
Just think about how the taxes would be handled. What a book-keeping mess.
Thanks, but I'm going to continue writing GPL-ed stuff and not get into squabbles over who gets paid what.
Bruce
I don't think the Trolls want to talk about their side. But you could ask them.
Thanks
Bruce
As far as I can tell, Palm can't come close to this in either capacity or price.
Not that I'm about to scrap my Palm Pro and do this. If we could ever get an open OS on one of those machines, though, I'd go for it.
Bruce
The entire purpose of the Alladin license is to make people who want to sell the software buy a commercial license from Peter. It's really the same as the NCL in this respect.
Thanks
Bruce
No magic bullet? Did they expect microsoft to roll over and die or something? Instantly? The jury is still out.
Thanks
Bruce
Thanks
Bruce
This license and others like it can be classsified as "Mandiatory Direct Revenue-Capture for the Initial Developer."
It disregards the role of the unpaid collaborator who would add features to your program, because the initial developer has an advantage that the unpaid collaborator can neither obtain nor circumvent. This is a disincentive to the unpaid collaborator because instead of contributing work to the community they are now contributing work that someone else will be paid for no matter what they do. Contrast this to indirect revenue methods. If I don't like Red Hat, I can circumvent them and make my own Linux distribution, obtaining what would have been their profit for myself for some (possibly small) number of customers. Consider this in the case of a product like Linux, where the initial developer contributed a small amount of the total work and his services as an architect and coordinator, while the lion's share of the work was done by others.
It makes collaborative development unwieldy. If every developer insists on their own revenue capture, you would soon have a too-expensive product or a paperwork and procedural mess. Who decides how much each developer gets? Who decides who is worthy as a developer? Do they all make that decision for themselves and then compete with each other in some way?
It gives the initial developer a lock that causes a disincentive to "fork" a product. If Linus had direct revenue-capture from Linux and I decided to make a fork of it because I felt I could engineer it better, I might be able to do an excellent job, but Linus would still be compensated for my effort.
So, to sum it up, I think that direct revenue capture works to the detriment of collaboration.
Thanks
Bruce Perens
It disregards the role of the unpaid collaborator who would add features to your program, because the initial developer has an advantage that the unpaid collaborator can neither obtain nor circumvent. This is a disincentive to the unpaid collaborator because instead of contributing work to the community they are now contributing work that someone else will be paid for no matter what they do. Contrast this to indirect revenue methods. If I don't like Red Hat, I can circumvent them and make my own Linux distribution, obtaining what would have been their profit for myself for some (possibly small) number of customers. Consider this in the case of a product like Linux, where the initial developer contributed a small amount of the total work and his services as an architect and coordinator, while the lion's share of the work was done by others. It makes collaborative development unwieldy. If every developer insists on their own revenue capture, you would soon have a too-expensive product or a paperwork and procedural mess. Who decides how much each developer gets? Who decides who is worthy as a developer? Do they all make that decision for themselves and then compete with each other in some way? It gives the initial developer a lock that causes a disincentive to "fork" a product. If Linus had direct revenue-capture from Linux and I decided to make a fork of it because I felt I could engineer it better, I might be able to do an excellent job, but Linus would still be compensated for my effort.
So, to sum it up, I think that direct revenue capture works to the detriment of collaboration.
Thanks
Bruce Perens
Bruce