Network services/Problems: Difference between revisions

From WikiDotMako
(→‎Public: -- added an open question about our scope)
Line 8: Line 8:
=== Public ===
=== 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.
* 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
* 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
* 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



Revision as of 03:27, 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)".
  • 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.