Re: Are Web-API packages need to be in the 'main' repo ?
Alexey Eromenko wrote: Hello Debian People ! Debian 6.0 (Squeeze) ships packages [2] that integrate with web services (called in modern term 'Cloud Computing' or SaaS, 'Software-as-a-Service' if you will), such as the Facebook API. What if Facebook decides to close down it's APIs tomorrow ? Will Debian drop those packages from 6.0-stable release ? I'm not saying such packages must not exist in Debian. They should. But (!) those packages interface non-free web services, which is politically no different than non-free software. Technically even worse, because web-software is likely to break at any moment, change APIs, or close down free access to it, and demand either NDA contracts or fee-based licensing. Perhaps they should be moved to 'contrib' category, because they interface non-free web-services. Debian's 'main' repository seems not the right place for any such web APIs. As a concrete example of such breakage, xfce's weather widget turns out to use a hardcoded weather.com API key, which stopped working. #647749 It remains broken in stable so far, although a quick fix was put into unstable while upstream changes it to, I hope, use a weather service without API keys. There's a spectrum of dependancy on network services, something like this: * No dependance on specific servers. (Example: general purpose web browsers[1]) * Default servers, open protocols. (Examples: root DNS servers, TOR, DHT's, RBLs, web browser search UIs) * Clients for accessing a particular proprietary service. (Examples: facebook and twitter clients, youtube-dl) * Clients that rely on a proprietary service without making that explicit. (Examples: weather widgets, possibly some web browser features) How far down this line until it belongs in contrib or non-free? I don't know. But .. The distinction between the last two is that it's not really unexpected for a twitter client to not work if there is no longer a twitter.com, while the weather widget gives very little indication that it depends on a service provided by a particular company, that can break at any time. In other words, in one the network dependency is clear and in the other it's hidden. I think Debian should, at a minimum, find a way to make that network dependency information available, so a user can choose not to install and rely on such stuff. A user is already making that choice when they choose to install a facebook client (unless the client's description doesn't say it uses facebook!) -- but if we had a way to represent network dependencies, it could be used all the way up the stack to DNS servers if we wanted to. -- see shy jo signature.asc Description: Digital signature
Re: a Free Platform License?
- Original message - From: Clark C. Evans c...@clarkevans.com To: license-disc...@opensource.org Date: Sun, 04 Dec 2011 13:38:20 -0500 Subject: a Free Island Public License? Please find for your amusement and hopeful commentary a different take on what it means to be Free Software. FREE ISLAND PUBLIC LICENSE This software is licensed for any purpose excepting the right to make publicly available derived works which depend exclusively upon non-free software. So long as this copyright and license are included in all substantial copies of this work you may: 1. Publicly copy and use verbatim copies of this work including public distribution and performance. 2. Privately deal with this work in any way you wish, including internal usage, copying, and modification of this work. You may also make publicly available via distribution or public performance any Derived Work only if the following conditions are met: 1. the preferred source code for the Derived Work must be made freely available under this license; 2. the Derived Work must pass the Free Island test. By Derived Work we mean a modified copy or adaptation of this work or a separate work such as a plug-in, protocol adapter, or wrapper which is designed to have intimate interactions with this work's operational details, or interfaces. A Derived Work passes the Free Island test if it could be prepared, modified, compiled, tested, installed, and operated in a manner advertised or expected using only commodity hardware, Free Software, this software, and the Derived Work itself. In particular, the Derived Work fails the test if it in any way depends upon remote network interaction or interfaces to works that do not have a Free Software implementation. By Free Software we mean any software which is readily available to the public without fee and this license, any license approved by the Open Source Initiative or any license considered free by the Free Software Foundation. A safe harbor for passing the Free Island test is if the Derived Work is fully usable as intended when compiled installed on a Debian virtual machine using software only from its 'free' distribution and KVM. If the Derived Work was created for interaction with other works, then it must be fully testable in conjunction with a Free Software alternative of this work as available on this virtual machine. THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, AGAINST INFRINGEMENT, TITLE AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1323030084.24974.140661007301...@webmail.messagingengine.com
Re: On using the name Kinect, and fetching a binary firmware
On Fri, 30 Sep 2011 17:18:22 +0200 Josselin Mouette j...@debian.org wrote: [...] 2) For the audio to work a binary firmware is needed; it can be taken from the Micosoft Kinect for Windows SDK[4] but since that is not re-distributable I decided to use a script[5] which downloads and extracts the firmware, the script is going to be called at installation time, is that OK? It is OK but on 2 conditions: * it needs to check the integrity of the firmware using a secure hash or equivalent technology; * the package will need to go in contrib. OK thanks, I've made the required changes, me and my sponsor are almost ready to upload, but we would like to have the last doubt sorted out, should the script which download the firmware be interactive and ask the user to explicitly accept the Microsoft Kinect for Windows SDK license? Even if we are only taking a single binary file out of it? This is the text of the license: http://www.kinectforwindows.org/download/EULA.htm Most of the restrictions are in the 1. INSTALLATION AND USE RIGHTS. section, but we are not really installing the SDK, just downloading and accessing it to extract a firmware blob, are we safe because of that? I am not a native English speaker so I could have taken the legal text too naively. Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgptnCu6dMA02.pgp Description: PGP signature
Re: Are Web-API packages need to be in the 'main' repo ?
On Sunday, December 04, 2011 3:55ser PM, Joey Hess jo...@debian.org wrote: Perhaps they should be moved to 'contrib' category, because they interface non-free web-services. Debian's 'main' repository seems not the right place for any such web APIs. ... How far down this line until it belongs in contrib or non-free? I don't know. I'd say that any dependency on non-free remote service fails Debian's Desert Island Test [1] and as such, even if the remote access is free-of-charge and functional, the code using it should be limited to contrib. Software which has a configurable end-point and which access an implementation that is free software is free. Best, Clark [1] http://wiki.debian.org/DesertIslandTest -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1323046941.19489.140661007379...@webmail.messagingengine.com
Re: Are Web-API packages need to be in the 'main' repo ?
Le 04/12/2011 21:02, Clark C. Evans a écrit : I'd say that any dependency on non-free remote service fails Debian's Desert Island Test [1] Nothing prevents people to distribute the code inside a desert Island. The fact that the program would be useless if it depends on a remote service is another matter : are we going to pretend that apt is non-free because we can't use it on a desert Island, since there is no ftp.desertisland.debian.org official mirror available? Regards David signature.asc Description: OpenPGP digital signature
