Re: GPLv3
On Jul 1 08:16, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Brian Dessent on 6/30/2007 10:12 PM: So, what is the consensus - am I allowed to upload tar 1.18, or is cygwin forevermore stuck at tar 1.17 as the last GPLv2 release, because of the fact that building an image of tar 1.18 linked against cygwin1.dll constitutes a license violation? Remember that the Cygwin license includes an OSI exemption, so as long as GPLv3 is eventually OSI certified (as if...) it's fine on the Cygwin side. I don't know about the other direction though. Thanks for the reminder about the exception clause. Since packaging tar 1.18 does not modify the sources to cygwin1.dll, I agree that the GPLv2 exception offered by cygwin is applicable here. I don't think GPLv3 will have any problem achieving OSI exemption, so I went ahead and uploaded tar 1.18. It's still an interesting point since the GPLv3 linked against a GPLv2 lib with excemption. I'll try to get legal advice about Cygwin and the GPLv3. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] perl-5.8.8
On Jun 28 21:32, Reini Urban wrote: Corinna Vinschen schrieb: On Jun 21 20:24, Reini Urban wrote: Yitzchak Scott-Thoennes schrieb: On Tue, June 19, 2007 7:24 pm, Reini Urban wrote: I want to it take over from Gerrit. Thank you so much. If it were up to me, you'd get three gold stars. Please try to test it. It's a really weird build system. But I'm quite happy with this 5.8.8 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1.tar.bz2 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1-src.tar.bz2 http://rurban.xarch.at/software/cygwin/release/perl/perl_manpages/perl_manpages-5.8.8-1.tar.bz2 [...] We had a routing problem this day. Please try again. I'm just looking for the packaging itself. I'm not a perl programmer, so I assume you're looking for creating a actually *working* perl yourself ;) Ok, that's what looks not quite ok to me: - Your package pollutes the /usr/bin directory with two versions of *almost* every tool in the perl package, foo, foo5.8.8, bar, bar5.8.8, etc. The former 5.8.7 package only created a perl5.8.8 parallel to the perl exe, but all other binaries were only available without versioning, same as in the Linux distros I have my hands on, btw. Almost, because there are two variances: - ld2, perlld, ptar and ptardiff only exist in the non-versioned style. - psed and pstruct only exist in the versioned style. - ld2 is not available in the perl package for Linux. Is that binary actually for public consumption? - The directory /usr/lib/perl5/5.8/auto, present in 5.8.7, is missing. Everything else looks ok to me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GPLv3
I'll try to get legal advice about Cygwin and the GPLv3. All this licensing stuff gives me headaches. I gave up trying to understand it long ago. Corinna, whenever you or someone else gets legal advice about this, I'd appreciate it if a policy could be posted stating as clearly as possible for us packagers what we can and can't do, and what traps to watch out for, as regards the various licenses. Thanks, Andrew.
Re: GPLv3
On Jul 2 10:40, Andrew Schulman wrote: I'll try to get legal advice about Cygwin and the GPLv3. All this licensing stuff gives me headaches. I gave up trying to understand it long ago. Unfortunately the wording of the GPLv3 got rather less easy to understand than the GPLv2. I can see why, but it's unfortunate just the same. Corinna, whenever you or someone else gets legal advice about this, I'd appreciate it if a policy could be posted stating as clearly as possible for us packagers what we can and can't do, and what traps to watch out for, as regards the various licenses. Sure. I'm already in internal discussion but this might take a while longer. The GPLv2 vs. GPLv3 issue has a couple of implications for Red Hat so changes will not be made lightheaded. I hope a decision is due soon. In the meantime, treat the http://cygwin.com/licensing.html page as state of the art, especially the open source permission clause. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GPLv3
In the meantime, treat the http://cygwin.com/licensing.html page as state of the art, especially the open source permission clause. Thanks.
Re: [ITP] perl-5.8.8
Corinna Vinschen schrieb: On Jun 28 21:32, Reini Urban wrote: Corinna Vinschen schrieb: On Jun 21 20:24, Reini Urban wrote: Yitzchak Scott-Thoennes schrieb: On Tue, June 19, 2007 7:24 pm, Reini Urban wrote: I want to it take over from Gerrit. Thank you so much. If it were up to me, you'd get three gold stars. Please try to test it. It's a really weird build system. But I'm quite happy with this 5.8.8 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1.tar.bz2 http://rurban.xarch.at/software/cygwin/release/perl/perl-5.8.8-1-src.tar.bz2 http://rurban.xarch.at/software/cygwin/release/perl/perl_manpages/perl_manpages-5.8.8-1.tar.bz2 [...] We had a routing problem this day. Please try again. I'm just looking for the packaging itself. I'm not a perl programmer, so I assume you're looking for creating a actually *working* perl yourself ;) Hmm, that's bad. Feedback from an actual perl programmer would be better. Ok, that's what looks not quite ok to me: - Your package pollutes the /usr/bin directory with two versions of *almost* every tool in the perl package, foo, foo5.8.8, bar, bar5.8.8, etc. The former 5.8.7 package only created a perl5.8.8 parallel to the perl exe, but all other binaries were only available without versioning, same as in the Linux distros I have my hands on, btw. This is intended and current practice for perl developers with a lot of different perl versions around to test their libraries against. perl-5.8.7 didn't have the versioned binaries and scripts, but with 5.10 being very near I wanted to give the opportunity to test with parallel perl installations. The big thing is only cygperl5_8.dll (only one) and a2p, the rest is small. Usage example: cpan5.8.8 installs into different paths than cpan5.9.5. perldoc == perldoc5.8.8 displays the stable doc, while perldoc5.9.5 displays the current doc, which is different. prove5.8.8 tests stable, prove5.9.5 tests blead (the current perl). Almost, because there are two variances: - ld2, perlld, ptar and ptardiff only exist in the non-versioned style. Yes, that's ok. ld2 and perlld intentionally. And ptar, ptardiff due to an upstream bug. Hmm. - psed and pstruct only exist in the versioned style. Hmm. Strange upstream installer. A bug, but not important. - ld2 is not available in the perl package for Linux. Is that binary actually for public consumption? Yes, ld2 is the windows-only ld wrapper. - The directory /usr/lib/perl5/5.8/auto, present in 5.8.7, is missing. Oops! POSIX/SigAction/*.al are needed! A packaging bug. No .packlist picked them up. Everything else looks ok to me. Please wait for -2. -- Reini Urban
Re: [ITP] perl-5.8.8
On Jul 2 19:06, Reini Urban wrote: Corinna Vinschen schrieb: - Your package pollutes the /usr/bin directory with two versions of *almost* every tool in the perl package, foo, foo5.8.8, bar, bar5.8.8, etc. The former 5.8.7 package only created a perl5.8.8 parallel to the perl exe, but all other binaries were only available without versioning, same as in the Linux distros I have my hands on, btw. This is intended and current practice for perl developers with a lot of different perl versions around to test their libraries against. Erm... that's ok for *your* test and build machines, but this is a stable release you're planning, not a test version. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITP] perl-5.8.8
Corinna Vinschen schrieb: On Jul 2 19:06, Reini Urban wrote: Corinna Vinschen schrieb: - Your package pollutes the /usr/bin directory with two versions of *almost* every tool in the perl package, foo, foo5.8.8, bar, bar5.8.8, etc. The former 5.8.7 package only created a perl5.8.8 parallel to the perl exe, but all other binaries were only available without versioning, same as in the Linux distros I have my hands on, btw. This is intended and current practice for perl developers with a lot of different perl versions around to test their libraries against. Erm... that's ok for *your* test and build machines, but this is a stable release you're planning, not a test version. I'm planning to release the test version also. See the thread under [perl-5.9.5]. The package is ready without any testsuite failure, it's just not yet released upstream and we are still finding silly bugs. But if the additional 5.8.8 script suffix is a problem I can pull them out. For me it made things clearer. -- Reini Urban
Re: GPLv3
On Jul 2 11:28, Andrew Schulman wrote: In the meantime, treat the http://cygwin.com/licensing.html page as state of the art, especially the open source permission clause. Thanks. Ok, I got legal advice now. Linking a GPLv3 application against a GPLv2-only library is not ok because this violates the v2-only license of the library. It does not violate the license of the v3 application. This means, the tar package in the Cygwin distro is not ok (but read on) because it violates Cygwin's license. There's no problem from the tar side, however. There are no short-term plans to change the license of Cygwin, rather we just wait until the OSI certifies the GPLv3 as open source license according to the definitions. As Brian already noted, as soon as the OSI certifies the GPLv3, the exemption clause from http://cygwin.com/licensing.html will also cover GPLv3'ed packages. In the meantime, as long as the GPLv3 is not OSI certified (which shouldn't take long), Red Hat will not enforce the GPLv2-only state of Cygwin on the back of GPLv3 packages. So, tar 1.18 can stay in the distro if Eric trusts Red Hat not to sue him. The same applies to every other maintainer of every other package which goes v3. Actually, cpio goes GPLv3 as well http://lists.gnu.org/archive/html/bug-cpio/2007-06/msg00016.html and as the Cygwin cpio maintainer I will provide the cpio 2.9 release under GPLv3 at any rate since, for some reason, I trust myself not to enforce the GPLv2 on my cpio package ;) I hope that clears the situation sufficiently. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: There are no short-term plans to change the license of Cygwin, rather we just wait until the OSI certifies the GPLv3 as open source license according to the definitions. As Brian already noted, as soon as the OSI certifies the GPLv3, the exemption clause from http://cygwin.com/licensing.html will also cover GPLv3'ed packages. IANAL, but I am a stickler for words, so if I may point out the following: There has always been an understanding that a license has to be OSI-approved to fall under the exception clause of the Cygwin license. But the clause doesn't say approved by the OSI, rather it says: ... a license that complies with the Open Source definition ... Complies according to whom? If IMHO, the GPLv3 does comply with the definition as published at the provided URL, who says I need to wait for the OSI to actually certify it as such? I understand that this goes against the general understanding that has existed until now, but as we all have learned through following Groklaw, it's not one's understanding of a contract that decides a case but the actual language therein. Could Red Hat's lawyers take another look at the language and provide their opinion on this? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGiVuHpiWmPGlmQSMRCLYgAJ0cNmz2EDKIKcfXG6bNF+juzzzBPQCgyzAc Sn5F7WnnV568KZ+e41k3gPA= =GIYO -END PGP SIGNATURE-
Re: GPLv3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: Red Hat will not enforce the GPLv2-only state of Cygwin on the back of GPLv3 packages. So, tar 1.18 can stay in the distro if Eric trusts Red Hat not to sue him. I'll trust Red Hat much more than other companies that we're supposed to trust not to sue us. :-) Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGiVzcpiWmPGlmQSMRCC0yAJ9v7zn7vDH+sS4hZrtyT/vexl1WuQCdHtkY PXaQfYPmAlBmdT/kH4kANlY= =Nchc -END PGP SIGNATURE-
RE: GPLv3
On 02 July 2007 21:10, Yaakov (Cygwin Ports) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Corinna Vinschen wrote: There are no short-term plans to change the license of Cygwin, rather we just wait until the OSI certifies the GPLv3 as open source license according to the definitions. As Brian already noted, as soon as the OSI certifies the GPLv3, the exemption clause from http://cygwin.com/licensing.html will also cover GPLv3'ed packages. IANAL, but I am a stickler for words, so if I may point out the following: There has always been an understanding that a license has to be OSI-approved to fall under the exception clause of the Cygwin license. But the clause doesn't say approved by the OSI, rather it says: ... a license that complies with the Open Source definition ... Complies according to whom? By definition: according to the judgement of whoever wrote that paragraph and that license, which is to say, according to RH legal team. If IMHO, the GPLv3 does comply with the definition as published at the provided URL, who says I need to wait for the OSI to actually certify it as such? You don't, as long as you are confident that the licensors will concur with your MHO. Well, technically, you don't have to wait for anything ever: this is a civil matter, there are no restraining injunctions, it would be up to RH legal to decide whether they felt GPLv3 complies, in which case they wouldn't sue your, or whether they felt it doesn't, in which case they would have the option of suing you, in the event of which it would then still be up to a court to decide whether the standards by which they have adjudged whether it 'complies' or not are reasonable under the standards by which civil contracts are judged, and hence enforcable, or not, and hence not. Herein lies both your security - they don't /have/ to sue you if they don't want to, even if something you do doesn't technically live up to the word of the license, because they are at liberty to decide for themselves if it 'complies' or note - and also your risk, because none of it is defined with mathematical rigour, there is an element of judgement to all the phraseology used, and it's a matter of contract law. Note very importantly the difference between whether X 'complies with' Y, which is a subjective judgement, and whether X is *certified as* Y, which is a matter of fact or not according to the decision of the relevant certifying body. Could Red Hat's lawyers take another look at the language and provide their opinion on this? What they say will - by definition - be definitive :-) cheers, DaveK -- Can't think of a witty .sigline today
