AMQP license
I would like to ask if the following license meets the DFSG. Clause ii of the license says that the license is terminated if you sue any author. The license appears at the top of the amqp specification downloaded from: https://jira.amqp.org/confluence/download/attachments/720900/amqp0-8.xml?version=1 I am not subscribed to this list John Leuner Copyright Notice © Copyright JPMorgan Chase Bank, Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA� Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. 2006. All rights reserved. License === JPMorgan Chase Bank, Cisco Systems, Inc., Envoy Technologies Inc., iMatix Corporation, IONA� Technologies, Red Hat, Inc., TWIST Process Innovations, and 29West Inc. (collectively, the Authors) each hereby grants to you a worldwide, perpetual, royalty-free, nontransferable, nonexclusive license to (i) copy, display, and implement the Advanced Messaging Queue Protocol (AMQP) Specification and (ii) the Licensed Claims that are held by the Authors, all for the purpose of implementing the Advanced Messaging Queue Protocol Specification. Your license and any rights under this Agreement will terminate immediately without notice from any Author if you bring any claim, suit, demand, or action related to the Advanced Messaging Queue Protocol Specification against any Author. Upon termination, you shall destroy all copies of the Advanced Messaging Queue Protocol Specification in your possession or control. As used hereunder, Licensed Claims means those claims of a patent or patent application, throughout the world, excluding design patents and design registrations, owned or controlled, or that can be sublicensed without fee and in compliance with the requirements of this Agreement, by an Author or its affiliates now or at any future time and which would necessarily be infringed by implementation of the Advanced Messaging Queue Protocol Specification. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no plausible non-infringing alternative for implementing the required portions of the Advanced Messaging Queue Protocol Specification. Notwithstanding the foregoing, Licensed Claims shall not include any claims other than as set forth above even if contained in the same patent as Licensed Claims; or that read solely on any implementations of any portion of the Advanced Messaging Queue Protocol Specification that are not required by the Advanced Messaging Queue Protocol Specification, or that, if licensed, would require a payment of royalties by the licensor to unaffiliated third parties. Moreover, Licensed Claims shall not include (i) any enabling technologies that may be necessary to make or use any Licensed Product but are not themselves expressly set forth in the Advanced Messaging Queue Protocol Specification (e.g., semiconductor manufacturing technology, compiler technology, object oriented technology, networking technology, operating system technology, and the like); or (ii) the implementation of other published standards developed elsewhere and merely referred to in the body of the Advanced Messaging Queue Protocol Specification, or (iii) any Licensed Product and any combinations thereof the purpose or function of which is not required for compliance with the Advanced Messaging Queue Protocol Specification. For purposes of this definition, the Advanced Messaging Queue Protocol Specification shall be deemed to include both architectural and interconnection requirements essential for interoperability and may also include supporting source code artifacts where such architectural, interconnection requirements and source code artifacts are expressly identified as being required or documentation to achieve compliance with the Advanced Messaging Queue Protocol Specification. As used hereunder, Licensed Products means only those specific portions of products (hardware, software or combinations thereof) that implement and are compliant with all relevant portions of the Advanced Messaging Queue Protocol Specification. The following disclaimers, which you hereby also acknowledge as to any use you may make of the Advanced Messaging Queue Protocol Specification: THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION IS PROVIDED AS IS, AND THE AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF THE ADVANCED MESSAGING QUEUE PROTOCOL SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE, IMPLEMENTATION OR DISTRIBUTION OF
Re: AMQP license
On 06/12/2007, John Leuner [EMAIL PROTECTED] wrote: I would like to ask if the following license meets the DFSG. Clause ii of the license says that the license is terminated if you sue any author. I don't think that in itself makes the licence non-free (the CDDL includes a similar provision relating to patent claims). Can't comment on the rest of the licence: it's a pretty horrible piece of drafting, but it seems to allow people to produce free software implementations of the specification. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of AGPL v3
On Mon, 19 Nov 2007 23:35:35 +0100, John Halton [EMAIL PROTECTED] wrote: For now, as regards the interaction issue my inclination is to assume that it is implicit in this that (a) we are talking about some level of direct input/output interaction from the user's point of view. i.e. software providing user interface-level interaction, not software further down the stack, and (b) we are talking about interaction for the purposes of exercising the intended functionality of the program, not 403 errors. That still leaves us hanging wrt. a web-server or network driver that is under the AGPL3. For a web-server, serving a 403 error is (part of) its intended functionality, as is sending the packages for the network driver. Also, the web server is clearly interacting with the user (receiving input originating from the user and responding to it). The web server might be able to prominently offer access to the source, but the network driver surely can't. So, the prominently offer part suggests that interaction means that the user must *see* output from the program *itself*, not just something it conveys. So an interactive AGPL program *must* have a prominent way of giving information to the user. This breaks for any server where the return format is restricted (web servers should not insert content on delivered pages, so unless the HTTP headers are prominent enough, an AGPL3 web server is in trouble) The problem here is still that interaction isn't defined. And probably can't be without being either too narrow or too broad. /L 'some categories are best defined by their perimeter, others by their center.' -- Lasse R. Nielsen - [EMAIL PROTECTED] 'Faith without judgement merely degrades the spirit divine' Reproduction of this message, or parts thereof, is allowed if proper attribution is given. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of AGPL v3
On Thu, Dec 06, 2007 at 06:44:52PM +0100, Lasse Reichstein Holst Nielsen wrote: So an interactive AGPL program *must* have a prominent way of giving information to the user. This breaks for any server where the return format is restricted (web servers should not insert content on delivered pages, so unless the HTTP headers are prominent enough, an AGPL3 web server is in trouble) The problem here is still that interaction isn't defined. And probably can't be without being either too narrow or too broad. From the previous discussion, I gather the FSF's interpretation is a broad one. As regards the AGPL web server and other similar hypotheticals, I think this would come down to user/community pressure: i.e. if someone chooses a licence that is impractical then either the software won't find many users, or the licensor will come under pressure to move to a better licence. That makes the AGPL a bad licence in some circumstances, but I'm not convinced it makes it non-free. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Review-request for Mugshot Trademark Guidelines
On Wed, Dec 05, 2007 at 04:40:43PM -0500, Joe Smith wrote: John Halton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 3. If they charge a fee for the CD-ROM or other media on which they deliver the Mugshot™ code, they warranty the media on which the Mugshot™ code is delivered, thus ensuring that the recipient receives a usable copy. Paragraph 3 may be the first problem. It basically prevents cheap CD vendors from selling copies of Debian on an as is basis. I'm not sure this is a real concern. are they really selling the media as-is? So If the cd comes scratched so bad it does not work, or is warped, the buyer has no recourse? I can see no warrenty on data being useable for anything, but I'm not aware of anybody who sells Disc's who does not have at least a limited warrenty covering manufactiong defects on the media. (As opposed to data defects) I agree this is probably more of a theoretical concern than an actual problem. Anyone who refused to replaced defective CDs would go out of business very quickly! Including that notice in the package long description would certainly cover the packages.debian.org and downloading via aptitude/synaptic. But I don't think out ftp architecture is set up such as to allow us to include a README file in the same directory. My guess is that including the statement in the package's long description is would be considered by RedHat as sufficient, but we should really get clarification. I'd be amazed if this approach was a problem, but I agree a clarification is worthwhile. Presumably the notice could also be included in the copyright file? The distribution media thing is likely something the ftpmasters would need to decide. It not really so much a freeness problem, as potential practical problem should an organization unwilling to place a limited warrenty on the physical media exist and desire to destribute Debian. The notice requirement can be solved, if Red Hat agrees that including the notice in the package's long description is sufficient. (Which I expect they will, but we really need offical clarification on.) I agree. So overall it sounds like this will be OK, subject to that point about the distribution media and the clarification from Red Hat. John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some questions about eaccelerator-package
Hello there. I ask for advise. PHP uses its own OpenSource license which is incompatible with GPL for some reasons. eAccelerator[1] is a PHP extension which speeds up php scrips at 10 times and do some more things (content caching, session handling etc.) But it is licensed under GPL and unfortunately it could not be changed[2]. So binary distribution of eAccelerator would be GPL violation. I made wrapper package which contains make-eaceelerator-package script and some other stuff which allow end-user to make binary package in one command. Now I have some questions: 1st. Where should such script go? main or contrib? from one point of view, my script, eAccelerator and PHP are all free software, but from the other one there are some restriction which makes eaccelerator not 100% free. 2nd. Is it possible to have eaccelerator-src package with eaccelerator's sources in main? If not, could it enter non-free? PS Yes, I know about pine, which is available only as source package, but I think, that it's not easy for end-user to make binary packages by hand. And I prefer script which do all this stuff for them. PPS You can take a look at this package at [3]. For now it has eaccelerator sources inside and creates two binary packages: eaccelerator-package and eaccelerator-src, but this could be changed if we decide to put this binary packages in separate sections. Any suggestion are welcomed. [1] http://eaccelerator.net [2] http://lists.debian.org/debian-legal/2005/01/msg00130.html [3] http://vice.gq.net.ru/staff/eaccelerator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final text of AGPL v3
On Thu, 6 Dec 2007 18:46:57 + John Halton wrote: [...] As regards the AGPL web server and other similar hypotheticals, I think this would come down to user/community pressure: i.e. if someone chooses a licence that is impractical then either the software won't find many users, or the licensor will come under pressure to move to a better licence. That makes the AGPL a bad licence in some circumstances, but I'm not convinced it makes it non-free. IMHO the problem is: it seems that I cannot modify an AGPLv3'ed program into a web server without adopting contorted and unpractical (or even unfeasible) technical solutions or otherwise failing to comply with the license. This definitely smells as non-free, from my standpoint. As usual: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpqcosiRgKZT.pgp Description: PGP signature
Re: AMQP license
On Thu, 6 Dec 2007 23:48:42 + John Halton wrote:
On Fri, Dec 07, 2007 at 12:36:53AM +0100, Francesco Poli wrote:
I think that the original question was more about the DFSG-freeness
of the AMQP specification itself, rather than about the possibility
of developing DFSG-free programs which follow the specification...
I'm not sure how one would apply the DFSG to a specification as such.
Well, the specification is a document (right?).
A document is a copyright{ed|able} work and hence (with the current sad
laws) does not comply with the DFSG, unless it is released under the
terms of a license which is permissive enough.
Is the license included in the original message permissive enough?
I think the original question can be rephrased as above...
At least, that is how I read it.
For instance: from a quick glance, I couldn't find any permission to
distribute modified versions of the specification (even under a
different name).
If there's no such permission, then the specification fails
DFSG#3/DFSG#4 ...
If implementation of the specification would require the spec. itself
to be incorporated into the relevant package then the inability to
modify the spec. clearly makes it non-free.
OTOH, if it is just a case of making a program that meets the spec.,
and the program itself is free and does not contain the spec. itself,
then I don't see that's a problem. (See the recent discussion here
concerning a program that implemented a non-free RFC.)
Unless you want to distribute the specification itself (in main)!
I know you all remember that, but anyway:
IANAL, TINLA, IANADD, TINASOTODP.
--
http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html
Need to read a Debian testing installation walk-through?
. Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpvag6TABcrR.pgp
Description: PGP signature
Re: AMQP license
On Fri, Dec 07, 2007 at 12:36:53AM +0100, Francesco Poli wrote: I think that the original question was more about the DFSG-freeness of the AMQP specification itself, rather than about the possibility of developing DFSG-free programs which follow the specification... I'm not sure how one would apply the DFSG to a specification as such. If implementation of the specification would require the spec. itself to be incorporated into the relevant package then the inability to modify the spec. clearly makes it non-free. OTOH, if it is just a case of making a program that meets the spec., and the program itself is free and does not contain the spec. itself, then I don't see that's a problem. (See the recent discussion here concerning a program that implemented a non-free RFC.) John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMQP license
On Thu, 6 Dec 2007 11:08:36 + John Halton wrote: On 06/12/2007, John Leuner [EMAIL PROTECTED] wrote: I would like to ask if the following license meets the DFSG. Clause ii of the license says that the license is terminated if you sue any author. I don't think that in itself makes the licence non-free (the CDDL includes a similar provision relating to patent claims). Please don't get me started on the unpleasant CDDL: I don't have the entire night available for discussions on debian-legal! ;-) Can't comment on the rest of the licence: it's a pretty horrible piece of drafting, Agreed (it's contorted and almost unreadable). but it seems to allow people to produce free software implementations of the specification. I think that the original question was more about the DFSG-freeness of the AMQP specification itself, rather than about the possibility of developing DFSG-free programs which follow the specification... (IANAL, TINLA, IANADD, TINASOTODP) -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgppUr5qT9KFK.pgp Description: PGP signature
Re: AMQP license
On Fri, Dec 07, 2007 at 01:04:43AM +0100, Francesco Poli wrote: For instance: from a quick glance, I couldn't find any permission to distribute modified versions of the specification (even under a different name). If there's no such permission, then the specification fails DFSG#3/DFSG#4 ... Agreed, but it wasn't 100% clear to me that OP was simply asking whether the specification itself as a text met the DFSG. If that was the question then the answer is pretty straightforward: no. It doesn't allow you to modify the specification, let alone distribute a modified version. OTOH, if it is just a case of making a program that meets the spec., and the program itself is free and does not contain the spec. itself, then I don't see that's a problem. (See the recent discussion here concerning a program that implemented a non-free RFC.) Unless you want to distribute the specification itself (in main)! Well, quite. But in the case of the RFC, the consensus seemed to be that there was no problem including the program that implemented it in main, provided the actual RFC text was removed from the source. But in the case of an XML specification, perhaps implementation inevitably involves including the text of the specification itself, i.e. the XML code (unlike the RFC, which was just an English text document). This is where I shrug and go, But I'm not a programmer, so I dunno. ;-) John (TINLA) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
