|
|
| (5 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| We should have a clear statement and description of the problems for freedom that network services introduce along with examples, classifications, and necessary context.
| | {{autonomous|Problems}} |
| | |
| === 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.
| |
| ** Is this a problem? Release code under AGPLv3, solved. If there is a problem it is that AGPLv3 is relatively unknown and not well understood, nor is there much code released under the license so as to encourage release of yet more code under the license. So the solution is AGPLv3 education, evangelism, and most importantly release of code by people who do understand under AGPLv3.
| |
| * Some coders feel that an important freedom is the freedom to deliver applications on their own public accessible servers without sharing their derivatives.
| |
| ** Is this a problem? Don't use AGPLv3 code, solved.
| |
| * Some service interfaces and business models are patented, notably Amazon S3. See http://yro.slashdot.org/article.pl?sid=07/07/06/0439245 .
| |
| ** Is this problem at all unique to services? http://endsoftpatents.org/ amen.
| |
| | |
| === 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]
| |
| ** Agree with Luis
| |
| * 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
| |
| ** Agree with Luis
| |
| * An otherwise Free service could require a non-Free client, eg if the service renders media or UI such as patent-encumbered formats and Flash. One way to think of the solution is that everything required to deploy and use a Free service should be DFSG compliant. For a Free serivce that is a website, this means the code and data on the server and the code required to interact with the service on the client.
| |
| | |
| | |
| === 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)".
| |
| ** Again, is this at all unique to services?
| |
| * 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.
| |
| ** In that case the GPL is a lesser license in that [http://www.gnu.org/licenses/gpl-faq.html#MereAggregation IPC does not necessarily trigger copyleft]. Attempting to legally mandate what runs on a client machine (private, not offering services to the public) seems antisocial, if not leading to treachery, and as a practical matter, very few users.
| |
| * 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.
| |
| ** Education/evangelism problem.
| |
| * 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.
| |
| ** This is also a leading excuse for not releasing non-networked code under a Free license. Embrace good software engineering practices. Make it easy for users to deploy services from revision control with a vendor branch and republish changes from their revision control system.
| |
