RFC: licence of ITP: s3sync-ruby
I hope no-one minds, but I'd like some smart analysis of this software's licence, so I'm asking debian-legal for their views. Please keep the Cc to the ITP report on replies. juanro...@gmail.com wrote: * Package name: s3sync-ruby * URL : http://s3sync.net/ * License : Other The licence shown in http://code.google.com/p/s3sync-s3cmd/source/browse/trunk/s3sync/s3sync.rb is: # This software code is made available AS IS without warranties of any # kind. You may copy, display, modify and redistribute the software # code either by itself or as incorporated into your code; provided that # you do not remove any proprietary notices. Your use of this software # code is at your own risk and you waive any claim against the author # with respect to your use of this software code. # (c) 2007 s3sync.net The whois for s3sync.net says:- Registrant: ServEdge 2605 Farragut Drive Domain Contact Info Springfield, IL 62704 US Meanwhile, the website and code seems pretty clearly to be by ferrix. Questions: 1. does s3sync.net mean ServEdge for copyright or is it a distinct person? 2. if so, do we trust that author ferrix has assigned copyright to ServEdge? 3. is the licence any obstacle to meeting DFSG? 4. does this software meet the DFSG? Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#510493: RFC: licence of ITP: s3sync-ruby
Please, also see the licence for the file http://code.google.com/p/s3sync-s3cmd/source/browse/trunk/s3sync/S3.rb # This software code is made available AS IS without warranties of any # kind. You may copy, display, modify and redistribute the software # code either by itself or as incorporated into your code; provided that # you do not remove any proprietary notices. Your use of this software # code is at your own risk and you waive any claim against Amazon # Digital Services, Inc. or its affiliates with respect to your use of # this software code. (c) 2006 Amazon Digital Services, Inc. or its # affiliates. On Sun, Jan 4, 2009 at 9:00 AM, MJ Ray m...@phonecoop.coop wrote: I hope no-one minds, but I'd like some smart analysis of this software's licence, so I'm asking debian-legal for their views. Please keep the Cc to the ITP report on replies. juanro...@gmail.com wrote: * Package name: s3sync-ruby * URL : http://s3sync.net/ * License : Other The licence shown in http://code.google.com/p/s3sync-s3cmd/source/browse/trunk/s3sync/s3sync.rb is: # This software code is made available AS IS without warranties of any # kind. You may copy, display, modify and redistribute the software # code either by itself or as incorporated into your code; provided that # you do not remove any proprietary notices. Your use of this software # code is at your own risk and you waive any claim against the author # with respect to your use of this software code. # (c) 2007 s3sync.net The whois for s3sync.net says:- Registrant: ServEdge 2605 Farragut Drive Domain Contact Info Springfield, IL 62704 US Meanwhile, the website and code seems pretty clearly to be by ferrix. Questions: 1. does s3sync.net mean ServEdge for copyright or is it a distinct person? 2. if so, do we trust that author ferrix has assigned copyright to ServEdge? 3. is the licence any obstacle to meeting DFSG? 4. does this software meet the DFSG? Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/http://people.debian.org/%7Emjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct
Re: enabling transport and on storage encryption in bacula on debian build
Hello, The current released version (2.4.x) series under an interpretation that OpenSSL is not a system library routine, which is Debian's position, means that they cannot distribute Bacula with OpenSSL enabled (Bacula communications and data encryption). The source code does exist, but is simply not enabled in the Debian binaries. As a consequence, if you want encryption in Bacula, there are two choices: 1. Build it from source yourself (perfectly legal -- only distribution violates the GPL license). 2. Wait for version 3.0.0 (currently in Beta testing as version 2.5.28-b1). This version has no licensing problems (pointer to details for version 2.4.x provided by John) and so Debian will be able to release it with OpenSSL compiled in. Best regards, Kern On Sunday 04 January 2009 00:59:33 Thomas Stegbauer wrote: hello everybody, a happy new year to all. as i figured currently out, bacula on debian is unable to encryption the data. http://lists.debian.org/debian-legal/2007/07/msg00144.html what can be done this get solved within debian 5.0 lenny? greetings thomas -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: bash completion script licensing
* Matthew Johnson: On Fri Jan 02 19:50, Mike Hommey wrote: As the GPL and CDDL are incompatible, as GPL code has some strange interactions with other code (library linkage, etc.), and as I'm not sure how sourced bash scripts are supposed to be considered in this context, I wonder if having such a CDDL bash script would be problematic license-wise. There would be no problem with a CDDL bash script per-se, any more than there would be with a CDDL jpeg or a GPL word document. I suppose you could argue that since it is modifying the behaviour of one of bash's built-in functions it counts under the (already dubious) GPL linkage clause, but I think it would be a stretch. The usual argument is that the program is a derived work of the programming environment; it's not based on linking per se. I don't know if this argument has been made for shell scripts (especially those containing bashisms). The FSF position is reflected in this statement: | If a programming language interpreter is released under the GPL, does | that mean programs written to be interpreted by it must be under | GPL-compatible licenses? | | When the interpreter just interprets a language, the answer is | no. The interpreted program, to the interpreter, is just data; a | free software license like the GPL, based on copyright law, cannot | limit what data you use the interpreter on. You can run it on any | data (interpreted program), any way you like, and there are no | requirements about licensing that data to anyone. | | However, when the interpreter is extended to provide “bindings” | to other facilities (often, but not necessarily, libraries), the | interpreted program is effectively linked to the facilities it | uses through these bindings. So if these facilities are released | under the GPL, the interpreted program that uses them must be | released in a GPL-compatible way. The JNI or Java Native Interface | is an example of such a binding mechanism; libraries that are | accessed in this way are linked dynamically with the Java programs | that call them. These libraries are also linked with the | interpreter. If the interpreter is linked statically with these | libraries, or if it is designed to link dynamically with these | specific libraries, then it too needs to be released in a | GPL-compatible way. | | Another similar and very common case is to provide libraries with | the interpreter which are themselves interpreted. For instance, | Perl comes with many Perl modules, and a Java implementation comes | with many Java classes. These libraries and the programs that call | them are always dynamically linked together. | | A consequence is that if you choose to use GPL'd Perl modules or | Java classes in your program, you must release the program in a | GPL-compatible way, regardless of the license used in the Perl or | Java interpreter that the combined Perl or Java program will run | on. http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL (For particular interpreters, the copyright holder might argue that all non-trivial scripts are derived works of the interpret, so this is less permissive than it seems at first glance.) IMHO, the statement is somewhat incomplete. If you only program to standardized interfaces (for which multiple implementations exist, including non-GPLed ones), your code won't be a derived work of the library. However, this might be just wishful thinking on my part because I think that the FSF has lost its original vision in this particular area, and that the claim that you can create derived works merely by reference to the original work is an expansionist copyright policy, not much different from other forms of copyright extension. -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: bash completion script licensing
In message 87sknziao6@mid.deneb.enyo.de, Florian Weimer f...@deneb.enyo.de writes * Matthew Johnson: On Fri Jan 02 19:50, Mike Hommey wrote: As the GPL and CDDL are incompatible, as GPL code has some strange interactions with other code (library linkage, etc.), and as I'm not sure how sourced bash scripts are supposed to be considered in this context, I wonder if having such a CDDL bash script would be problematic license-wise. There would be no problem with a CDDL bash script per-se, any more than there would be with a CDDL jpeg or a GPL word document. I suppose you could argue that since it is modifying the behaviour of one of bash's built-in functions it counts under the (already dubious) GPL linkage clause, but I think it would be a stretch. The usual argument is that the program is a derived work of the programming environment; it's not based on linking per se. I don't know if this argument has been made for shell scripts (especially those containing bashisms). The FSF position is reflected in this statement: | If a programming language interpreter is released under the GPL, does | that mean programs written to be interpreted by it must be under | GPL-compatible licenses? | | When the interpreter just interprets a language, the answer is | no. The interpreted program, to the interpreter, is just data; a | free software license like the GPL, based on copyright law, cannot | limit what data you use the interpreter on. You can run it on any | data (interpreted program), any way you like, and there are no | requirements about licensing that data to anyone. | | However, when the interpreter is extended to provide “bindings” | to other facilities (often, but not necessarily, libraries), the | interpreted program is effectively linked to the facilities it | uses through these bindings. So if these facilities are released | under the GPL, the interpreted program that uses them must be | released in a GPL-compatible way. The JNI or Java Native Interface | is an example of such a binding mechanism; libraries that are | accessed in this way are linked dynamically with the Java programs | that call them. These libraries are also linked with the | interpreter. If the interpreter is linked statically with these | libraries, or if it is designed to link dynamically with these | specific libraries, then it too needs to be released in a | GPL-compatible way. | | Another similar and very common case is to provide libraries with | the interpreter which are themselves interpreted. For instance, | Perl comes with many Perl modules, and a Java implementation comes | with many Java classes. These libraries and the programs that call | them are always dynamically linked together. | | A consequence is that if you choose to use GPL'd Perl modules or | Java classes in your program, you must release the program in a | GPL-compatible way, regardless of the license used in the Perl or | Java interpreter that the combined Perl or Java program will run | on. http://www.fsf.org/licensing/licenses/gpl-faq.html#IfInterpreterIsGPL (For particular interpreters, the copyright holder might argue that all non-trivial scripts are derived works of the interpret, so this is less permissive than it seems at first glance.) Is the interpreter interpreting source or pseudocode? Maybe I'm being dense, but in the case of something like a bash script, the distributor is distributing source therefore the licence of the interpreter is irrelevant. And when the script is run, it is the end-user doing the linking, so the GPL is irrelevant. Cheers, Wol -- Anthony W. Youngman - anth...@thewolery.demon.co.uk -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
