Re: bash completion script licensing
In message 87iqomapdk@mid.deneb.enyo.de, Florian Weimer f...@deneb.enyo.de writes * Anthony W. Youngman: The GPL requires more than just source code. In particular, further restrictions are not allowed. So having source code is not sufficient for compliance. Yes, but if I'm a DISTRIBUTOR, I don't have the power to change the licence, so if I receive source-code and pass it on, then the GPL is irrelevant, other than it gives me permission to copy what I have. Being a distributor does not exempt you from copyright violations. If all I do is copy it (for which the GPL gives me permission) and distribute the copies UNCHANGED, then I have not added further restrictions and I am not in breach of the GPL. This assumes that the copyright holder of the GPLed part gives you the work. You could construct implicit permission from that. But if someone else gives you the work. Most of the GPL enforcement to date has been against distributors. Please give me just ONE example of the GPL being enforced against people who were distributing SOURCE. Please note the subject of this thread is bash ... script ... - I thought bash scripts were simultaneously source and executable. Personally, I would be COMPLETELY happy, as author, distributor, OR end-user, to use GPL libraries with proprietary programs IF those proprietary programs were distributed AS SOURCE. I've actually used a couple of libraries like that (although they didn't link to GPL stuff - this was when Free Software was just beginning to take off). Reverse engineering tools for compiled code are nowadays good enough that they can compete, in terms of usability, with badly written source code. Combined with your argument, we should allow people to use GPLed code from their code, irrespective of their own licensing. This would be the end of copyleft. Let's say I write a program that uses loads of GPL software, and I licence it under a proprietary licence. If I distribute MY code, as source, and leave it to the user to do the compiling, linking etc, where is any copyright violation? Some people want it to be a copyright violation, to make copyleft stronger. I personally find it a difficult position to take if your end goal is abolition of all copyright. However, something similar is needed if you want the GPL have legal teeth (without making it a contract), and be more than just an elaborate statement of a preferred software distribution policy. While I think copyright may have over-reached itself, I'm not in favour of total abolition. I think the American social contract behind copyright is a very good idea. It's just that the law doesn't abide by the contract :-( But, as I said, in my scenario where is the copyright violation? How are you going to make it a violation? And actually, I think my scenario fufills THREE of the GPL's four freedoms. The only one it doesn't fulfil is to give *you* the right to share *my* code with other people. In other words, the only freedom you're not given is the freedom to ignore the american social contract. I'm fine with that! 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
Re: bash completion script licensing
* Anthony W. Youngman: Is the interpreter interpreting source or pseudocode? Pseudocode? Do you mean compiled code or bytecode? 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. The GPL requires more than just source code. In particular, further restrictions are not allowed. So having source code is not sufficient for compliance. And when the script is run, it is the end-user doing the linking, so the GPL is irrelevant. The same argument applies to dynamic linking. Some people do not accept it because it is the end of the GPL for libraries (and of royalties for component software). -- 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 871vvbv5st@mid.deneb.enyo.de, Florian Weimer f...@deneb.enyo.de writes * Anthony W. Youngman: Is the interpreter interpreting source or pseudocode? Pseudocode? Do you mean compiled code or bytecode? I meant bytecode - along the lines of basic is interpreted code, but sometimes it's pre-processed. 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. The GPL requires more than just source code. In particular, further restrictions are not allowed. So having source code is not sufficient for compliance. Yes, but if I'm a DISTRIBUTOR, I don't have the power to change the licence, so if I receive source-code and pass it on, then the GPL is irrelevant, other than it gives me permission to copy what I have. If all I do is copy it (for which the GPL gives me permission) and distribute the copies UNCHANGED, then I have not added further restrictions and I am not in breach of the GPL. So source code IS sufficient for compliance, if I am a DISTRIBUTOR who is just passing on copies. And when the script is run, it is the end-user doing the linking, so the GPL is irrelevant. The same argument applies to dynamic linking. Some people do not accept it because it is the end of the GPL for libraries (and of royalties for component software). Maybe. But life is shades of grey, not black-and-white. And imho, when applied rigidly (in *either* direction) that argument leads to idiocy. Personally, I would be COMPLETELY happy, as author, distributor, OR end-user, to use GPL libraries with proprietary programs IF those proprietary programs were distributed AS SOURCE. I've actually used a couple of libraries like that (although they didn't link to GPL stuff - this was when Free Software was just beginning to take off). Let's say I write a program that uses loads of GPL software, and I licence it under a proprietary licence. If I distribute MY code, as source, and leave it to the user to do the compiling, linking etc, where is any copyright violation? You can't do me, because I haven't distributed any GPL code (and the GPL lets me use it on MY computers). You can't do the user, for the same reasons. And you can't do the distributors, because they've never been near GPL code. 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
Re: bash completion script licensing
* Anthony W. Youngman: The GPL requires more than just source code. In particular, further restrictions are not allowed. So having source code is not sufficient for compliance. Yes, but if I'm a DISTRIBUTOR, I don't have the power to change the licence, so if I receive source-code and pass it on, then the GPL is irrelevant, other than it gives me permission to copy what I have. Being a distributor does not exempt you from copyright violations. If all I do is copy it (for which the GPL gives me permission) and distribute the copies UNCHANGED, then I have not added further restrictions and I am not in breach of the GPL. This assumes that the copyright holder of the GPLed part gives you the work. You could construct implicit permission from that. But if someone else gives you the work. Most of the GPL enforcement to date has been against distributors. Personally, I would be COMPLETELY happy, as author, distributor, OR end-user, to use GPL libraries with proprietary programs IF those proprietary programs were distributed AS SOURCE. I've actually used a couple of libraries like that (although they didn't link to GPL stuff - this was when Free Software was just beginning to take off). Reverse engineering tools for compiled code are nowadays good enough that they can compete, in terms of usability, with badly written source code. Combined with your argument, we should allow people to use GPLed code from their code, irrespective of their own licensing. This would be the end of copyleft. Let's say I write a program that uses loads of GPL software, and I licence it under a proprietary licence. If I distribute MY code, as source, and leave it to the user to do the compiling, linking etc, where is any copyright violation? Some people want it to be a copyright violation, to make copyleft stronger. I personally find it a difficult position to take if your end goal is abolition of all copyright. However, something similar is needed if you want the GPL have legal teeth (without making it a contract), and be more than just an elaborate statement of a preferred software distribution policy. -- 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
Re: bash completion script licensing
On Fri, Jan 02, 2009 at 09:53:06PM +, Matthew Johnson wrote: 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. I'd add that require or import in perl, python, ruby, etc. fall under the GPL linkage clause. Why would bash's source not ? Mike -- 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
On Sat Jan 03 09:22, Mike Hommey wrote: On Fri, Jan 02, 2009 at 09:53:06PM +, Matthew Johnson wrote: 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. I'd add that require or import in perl, python, ruby, etc. fall under the GPL linkage clause. Why would bash's source not ? Yes, but they aren't linking with _perl itself_ but rather with the other perl script they are imported to. Now, you might not be able to use such a bash completion script if your ~/.bashrc is licenced under the GPL (-; Also, rereading the OP, the licence of other bash completion scripts _might_ be an issue, but I don't think the licence of bash itself is an issue. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: bash completion script licensing
On Sat, Jan 03, 2009 at 10:06:53AM +, Matthew Johnson wrote: On Sat Jan 03 09:22, Mike Hommey wrote: On Fri, Jan 02, 2009 at 09:53:06PM +, Matthew Johnson wrote: 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. I'd add that require or import in perl, python, ruby, etc. fall under the GPL linkage clause. Why would bash's source not ? Yes, but they aren't linking with _perl itself_ but rather with the other perl script they are imported to. Now, you might not be able to use such a bash completion script if your ~/.bashrc is licenced under the GPL (-; Also, rereading the OP, the licence of other bash completion scripts _might_ be an issue, but I don't think the licence of bash itself is an issue. Well, actually the license of bash itself may be an issue because if I'm not mistaken, /etc/bash_completion that sources all other bash completion scripts and has already quite a lot of completions already implemented, comes with bash. Anyways, even if it didn't come with bash, the /etc/bash_completion script is still under the GPL (cf. its header). Now, independently of licenses for any script in /etc/bash_completion.d, there may be a problem with /etc/bash_completion, so my original question comes back: does that make a problem? Mike PS: Note that if we do have valid arguments, we may well be able to have the original script be relicensed under a non conflicting license. -- 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
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. Matt -- Matthew Johnson signature.asc Description: Digital signature
