(→Public: -- added an open question about our scope) |
(→Deployers: - add note about A(L)GPL) |
||
| Line 14: | Line 14: | ||
These are included kind of for completeness; it's nice (and practical, if we want any adoption to happen) to include the interests all parties in our discussion. | These are included kind of for completeness; it's nice (and practical, if we want any adoption to happen) to include the interests all parties in our discussion. | ||
* "Free" and "open" have different meanings for service deployers. "Free" has come to mean "gratis", and "open" just means "anyone can use it (even if it may requires payment)". | * "Free" and "open" have different meanings for service deployers. "Free" has come to mean "gratis", and "open" just means "anyone can use it (even if it may requires payment)". | ||
* AGPL is effectively a Lesser/Library license, in that it provides no mechanism for free-software-oriented deployers to ensure that consumers of networked APIs are themselves open if they so desire. | |||
* Typically free software requirements have stopped at the door of one's computer; it's nobody else's business what I do with my own software on my own server(s). Requirements on deployers will definitely give the appearance of being intrusive and asking too much. | * Typically free software requirements have stopped at the door of one's computer; it's nobody else's business what I do with my own software on my own server(s). Requirements on deployers will definitely give the appearance of being intrusive and asking too much. | ||
* Custom software, like for a Web service, often has lots of glue code, twiddles, dependencies and hacks. These aren't often documented internally, much less ready for distribution to the world as Free Software. | * Custom software, like for a Web service, often has lots of glue code, twiddles, dependencies and hacks. These aren't often documented internally, much less ready for distribution to the world as Free Software. | ||
Revision as of 01:33, 8 March 2008
We should have a clear statement and description of the problems for freedom that network services introduce along with examples, classifications, and necessary context.
Coders
- A number of coders have worked for long periods on code that they assumed would be 'free' only to discover that others were using their code (which they had distributed) as a service and not distributing derivatives.
- Some coders feel that an important freedom is the freedom to deliver applications on their own public accessible servers without sharing their derivatives.
- Some service interfaces and business models are patented, notably Amazon S3. See http://yro.slashdot.org/article.pl?sid=07/07/06/0439245 .
Public
- Generally, users of software as a service have a particularly difficult time gaining the freedom to copy, distribute, or study code. In short, their autonomy is compromised.
- Users of some critical civic applications (like software running voting machines) have no way to study the code - undermining basic principles of democracy. [While this is a problem, is it really a service-related problem? It seems like the scope of our problem is big enough without expanding it to include embedded systems like voting systems. I'd assumed our focus was on web services. Ditto next statement. --LuisVilla]
- As software becomes used in nanotechnology (like health applications), the four freedoms will likely become more and more important in areas that are not generally seen today as domains for software
Deployers
These are included kind of for completeness; it's nice (and practical, if we want any adoption to happen) to include the interests all parties in our discussion.
- "Free" and "open" have different meanings for service deployers. "Free" has come to mean "gratis", and "open" just means "anyone can use it (even if it may requires payment)".
- AGPL is effectively a Lesser/Library license, in that it provides no mechanism for free-software-oriented deployers to ensure that consumers of networked APIs are themselves open if they so desire.
- Typically free software requirements have stopped at the door of one's computer; it's nobody else's business what I do with my own software on my own server(s). Requirements on deployers will definitely give the appearance of being intrusive and asking too much.
- Custom software, like for a Web service, often has lots of glue code, twiddles, dependencies and hacks. These aren't often documented internally, much less ready for distribution to the world as Free Software.
