Re: FSF Policy re. inclusion of source code from other projects in GCC
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: Mark> I would prefer it go on savannah, which is more clearly unaffiliated Mark> with any particular commercial entity. Ok, I submitted a request there. Tom
Re: FSF Policy re. inclusion of source code from other projects in GCC
Tom Tromey wrote: > I am leaning toward putting it into the rhug repository on > sourceware.org, simply because then we (the gcj hackers) won't have to > go through some long project registration process. Speak up if you > have a particular problem with this. Thanks! I would prefer it go on savannah, which is more clearly unaffiliated with any particular commercial entity. The discussion on the SC list did mention moving it to savannah, but I don't think we specifically said it had to be savannah; we were using that as an example. I don't think I have any special authority to make this call, though, and I'm not trying to accuse anyone of anything whatsoever, so please don't interpret that request as some kind of dig. Nor do I in any way fail to appreciate Red Hat's support of free software by donating the machine. So, this is definitely in the my-two-cents category. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: Mark> The FSF and GCC SC have decided to move fastjar to savannah, and Mark> stop including it in future GCC releases, which will clarify Mark> this situation. Will someone please volunteer to migrate Mark> fastjar out of our repository? I'll take it out later this week. I am leaning toward putting it into the rhug repository on sourceware.org, simply because then we (the gcj hackers) won't have to go through some long project registration process. Speak up if you have a particular problem with this. Tom
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark Mitchell wrote: My guess is that it's OK to include the Sun code, since it's in the public domain. This may just be nit-picking, but the above notice doesn't put the code into the public domain. Sun still owns the copyright of the software. Actually notices at the start of files have very little legal significance and are surely not sufficient to put something in the public domain (if someone swiped the Microsoft Power Point sources, and posted them with public domain headers, that would not put them in the public domain!) THe only way to be sure on something like this is to get a written release from Sun, signed by an appropriate corporate officer.
Re: FSF Policy re. inclusion of source code from other projects in GCC
> Joe Buck writes: Ben> Please specify exactly what you want, and who at the FSF I talk to. Joe> If you have messages giving past discussions of the issue, all the better. If you have a message from the FSF approving the current situation, it would be extremely helpful if you either included that in the "Upstream Packages" stanza of the Coding Conventions page, provided a link to the public email message, or summarized the agreement and provided a point of contact who has the original message. The GCC SC needs to be able to find out the disposition of pieces of GCC to answer questions from RMS, the FSF, and others. The best way to avoid this type of confusion in the future is to keep the information in Upstream Packages up to date so that the GCC SC and everyone can answer these types of questions definitively. We need the cooperation of GCC maintainers and reviewers to ensure that this all runs smoothly. Thanks, David
Re: FSF Policy re. inclusion of source code from other projects in GCC
Ross Ridge wrote: > Richard Guenther wrote: >> /* >> * >> * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. >> * >> * Developed at SunPro, a Sun Microsystems, Inc. business. >> * Permission to use, copy, modify, and distribute this >> * software is freely granted, provided that this notice >> * is preserved. >> * >> */ > > Mark Mitchell wrote: >> My guess is that it's OK to include the Sun code, since it's in the >> public domain. > > This may just be nit-picking, but the above notice doesn't put the code > into the public domain. Sun still owns the copyright of the software. True! I believe I relied on Richard's words, but you're definitely correct. I still believe use of this code should be non-problematic, though. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
On Fri, Mar 17, 2006 at 05:09:17PM -0600, Benjamin Kosnik wrote: > > > As previously stated, if there is contrary information from FSF lawyers, > > then please gather it and present it to the FSF. > > Please specify exactly what you want, and who at the FSF I talk to. I am not Mark, but I suggest that you talk to RMS. If you have messages giving past discussions of the issue, all the better. I suggested off-list so we don't waste time on-list with a flame war when we can probably get the problem solved. I would prefer to have the current situation blessed, so we don't have to do anything.
Re: FSF Policy re. inclusion of source code from other projects in GCC
Benjamin Kosnik wrote: >> As previously stated, if there is contrary information from FSF lawyers, >> then please gather it and present it to the FSF. > > Please specify exactly what you want, and who at the FSF I talk to. I don't want anything in particular. I can assure you that my idea of a good time is not to spend hours drafting and redrafting emails about license issues. I volunteered to do that because RMS asked someone on the SC to do it, and nobody else volunteered. You will have to ask the FSF what they need to confirm the situation as you understand it. I would imagine that the ideal piece of evidence would be email from the FSF saying "It's OK to consider the STL files as part of GCC, you can modify them as you see fit, and it's OK to put FSF copyright notices on them." The right person to contact is RMS directly: [EMAIL PROTECTED] He generally responds to email within forty-eight hours, as the outside. I would suggest copying the GCC SC, since as the SC is the official maintainer of GCC, the SC needs to understand the outcome. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
Richard Guenther wrote: > /* > * > * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. > * > * Developed at SunPro, a Sun Microsystems, Inc. business. > * Permission to use, copy, modify, and distribute this > * software is freely granted, provided that this notice > * is preserved. > * > */ Mark Mitchell wrote: >My guess is that it's OK to include the Sun code, since it's in the >public domain. This may just be nit-picking, but the above notice doesn't put the code into the public domain. Sun still owns the copyright of the software. Ross Ridge
Re: FSF Policy re. inclusion of source code from other projects in GCC
> As previously stated, if there is contrary information from FSF lawyers, > then please gather it and present it to the FSF. Please specify exactly what you want, and who at the FSF I talk to. Please do so on-list. -benjamin
Re: FSF Policy re. inclusion of source code from other projects in GCC
On Fri, Mar 17, 2006 at 03:05:17PM -0800, Mark Mitchell wrote: > Benjamin Kosnik wrote: > >>> The STL files in libstdc++-v3 need to be clearly marked as not part of > >>> GCC. Benjamin, will you please take care of that, by modifying the > >>> libstdc++-v3/README to indicate that the files originally from HP are > >>> not part of GCC, and specifically list those files? > > > > Huh? What are you smoking dude? > > Nothing; I don't smoke. > > As already stated, all I am doing is passing along information from the > FSF. RMS personally approved the message that I sent, including the > discussion of the STL files. > > As previously stated, if there is contrary information from FSF lawyers, > then please gather it and present it to the FSF. Please, no one panic yet. I recall the facts as Ben stated them, but I can't lay hands on the old emails. I think that we can convince RMS that the STL usage in libstdc++ isn't a problem, and it's best to do that offline.
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark Mitchell wrote: > Benjamin Kosnik wrote: The STL files in libstdc++-v3 need to be clearly marked as not part of GCC. Benjamin, will you please take care of that, by modifying the libstdc++-v3/README to indicate that the files originally from HP are not part of GCC, and specifically list those files? >> Huh? What are you smoking dude? > > Nothing; I don't smoke. To be clear: in the case of the STL files, I specifically noted that we do not have to move them out of our repository. However, it is also clear that RMS believes (now) that these files should not have been treated as they were. I don't have permission to quote his messages on the topic, so I don't think I should, but I think it's clear that your understanding of the situation does not match his. So, I think you need to find the evidence of the permission that was obtained, so that we can resolve the situation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
Benjamin Kosnik wrote: >>> The STL files in libstdc++-v3 need to be clearly marked as not part of >>> GCC. Benjamin, will you please take care of that, by modifying the >>> libstdc++-v3/README to indicate that the files originally from HP are >>> not part of GCC, and specifically list those files? > > Huh? What are you smoking dude? Nothing; I don't smoke. As already stated, all I am doing is passing along information from the FSF. RMS personally approved the message that I sent, including the discussion of the STL files. As previously stated, if there is contrary information from FSF lawyers, then please gather it and present it to the FSF. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
> > The STL files in libstdc++-v3 need to be clearly marked as not part of > > GCC. Benjamin, will you please take care of that, by modifying the > > libstdc++-v3/README to indicate that the files originally from HP are > > not part of GCC, and specifically list those files? Huh? What are you smoking dude? Doing this would contradict past legal advice, given from actual lawyers no less, both at the FSF and Red Hat. I believe there has been a simple mistake here, or perhaps a generalization drawn too loosely. The current GNU libstdc+ + STL sources started diverging from the SGI sources (who had taken over maintainer-ship of the HP sources) as of 3.13, seven years ago. Since that time, there has been nothing to merge back to, and those source are unmaintained. This can be considered a permanent fork. All changes since then have been contributed under the GPL and copyright FSF, for which the FSF has assignments on file. -benjamin
Re: FSF Policy re. inclusion of source code from other projects in GCC
Richard Guenther wrote: > I'll try my best. And I take it as granted that I can turn to RMS in the case > we only get the usual reactions like > http://sourceware.org/ml/libc-alpha/2005-07/msg8.html Yes, I think RMS would like FSF maintainers to behave civilly. He did explicitly indicate in this case that the GLIBC maintainers should be willing to accommodate reasonable requests, although obviously reasonableness is in the eye of the beholder. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark Mitchell <[EMAIL PROTECTED]> writes: | Richard Guenther wrote: | | > Remembering the patches from Joseph these were from a different part | > of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and | > dbl-64 which contain C implementations of C99 math intrinsics such as | > sin and cos. The flt-32 parts are public domain as in | > | > /* | > * | > * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. | > * | > * Developed at SunPro, a Sun Microsystems, Inc. business. | > * Permission to use, copy, modify, and distribute this | > * software is freely granted, provided that this notice | > * is preserved. | > * | > */ | > | > while the dbl-64 parts are LGPL and so subject to the change to GPL | > + exception. I don't know if these parts of GLIBC are covered by RMS's | > permission, it is probably advisable to ask. | | I think that we need to ask RMS specifically about this. Would you | please send a message to RMS, and copy the SC list (is that address | public? I'm not sure if I'm supposed to give it out, ask me privately | if you don't know it) on the mail. Explain the situation, including | what code you're importing and why you want an exception. | | My guess is that it's OK to include the Sun code, since it's in the | public domain. My guess is also that, without explicit permission from | RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't | sound like that is covered by "software floating-point emulation". That | means that people who linked with this library would find that the LGPL | applies, which is contrary to our general policy that binaries produced | by GCC are not subject to GPL/LGPL issues. So, I think you should | remove the dbl-64 code until this is resolved, or at least prevent it | from being compiled by removing whatever Makefile bits compile it. My | experience is that it usually takes some time for RMS to grant a license | exception, and that he may not choose to do it. That even further clarify the issue for me. I believe, without the change of license, libgcc-math wouold not be as useful (to libstdc++-v3) as I understood it the previous place :-( -- Gaby
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 17 Mar 2006 23:27:35 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > | Gabriel Dos Reis wrote: > | > | > I am confused. My interest in libgcc-math is that it helps solve > | > thorny issues with libstdc++-v3 and my expectation is that we can make > | > modification to libgcc-math so that we can't advantage of it. Now, I > | > understand that we cannot make modification to libgcc-math without > | > modifying GLIBC? Is that correct. > | > | Yes, that is correct. It would take additional special dispensation > | from the FSF to modify the GLIBC code. RMS wants such modifications to > | be submitted upstream first, to avoid forks. You could ask RMS for that > | additional permission, if you want. > > Thanks for the clarification. > > | Please do not ask me to interpret or justify all of the rules; I don't > | understand the issues sufficiently well. I am just passing along the > | results of a long discussion with RMS on the SC list. > > I understand :-) > > Did I know this implication, and given past difficulty to communicate > with GLIBC people, I'm not sure I did the right thing (e.g. being > enthousiastic about libgcc-math). I'll try my best. And I take it as granted that I can turn to RMS in the case we only get the usual reactions like http://sourceware.org/ml/libc-alpha/2005-07/msg8.html (not that I didn't try to avoid creating libgcc-math in the first place...) Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark Mitchell <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | | > I am confused. My interest in libgcc-math is that it helps solve | > thorny issues with libstdc++-v3 and my expectation is that we can make | > modification to libgcc-math so that we can't advantage of it. Now, I | > understand that we cannot make modification to libgcc-math without | > modifying GLIBC? Is that correct. | | Yes, that is correct. It would take additional special dispensation | from the FSF to modify the GLIBC code. RMS wants such modifications to | be submitted upstream first, to avoid forks. You could ask RMS for that | additional permission, if you want. Thanks for the clarification. | Please do not ask me to interpret or justify all of the rules; I don't | understand the issues sufficiently well. I am just passing along the | results of a long discussion with RMS on the SC list. I understand :-) Did I know this implication, and given past difficulty to communicate with GLIBC people, I'm not sure I did the right thing (e.g. being enthousiastic about libgcc-math). -- Gaby
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 3/17/06, Mike Stump <[EMAIL PROTECTED]> wrote: > On Mar 17, 2006, at 2:07 PM, Mark Mitchell wrote: > > So, I think you should remove the dbl-64 code until this is > > resolved, or at least prevent it > > from being compiled by removing whatever Makefile bits compile it > > :-( At the outside, I'd say that in 7 days it should not be in > mainline nor any release branch if permission isn't secured. If there is consensus that the source should be (temporarily) removed then that is fine with me, though I'd prefer to just disable the makefile bits to give RMS some more time than 7 days. Also I won't have much time to dedicate to this problem until in two weeks, apart from emergency stuff like requested. Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > > Remembering the patches from Joseph these were from a different part > > of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and > > dbl-64 which contain C implementations of C99 math intrinsics such as > > sin and cos. The flt-32 parts are public domain as in > > > > /* > > * > > * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. > > * > > * Developed at SunPro, a Sun Microsystems, Inc. business. > > * Permission to use, copy, modify, and distribute this > > * software is freely granted, provided that this notice > > * is preserved. > > * > > */ > > > > while the dbl-64 parts are LGPL and so subject to the change to GPL > > + exception. I don't know if these parts of GLIBC are covered by RMS's > > permission, it is probably advisable to ask. > > I think that we need to ask RMS specifically about this. Would you > please send a message to RMS, and copy the SC list (is that address > public? I'm not sure if I'm supposed to give it out, ask me privately > if you don't know it) on the mail. Explain the situation, including > what code you're importing and why you want an exception. > > My guess is that it's OK to include the Sun code, since it's in the > public domain. My guess is also that, without explicit permission from > RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't > sound like that is covered by "software floating-point emulation". That > means that people who linked with this library would find that the LGPL > applies, which is contrary to our general policy that binaries produced > by GCC are not subject to GPL/LGPL issues. So, I think you should > remove the dbl-64 code until this is resolved, or at least prevent it > from being compiled by removing whatever Makefile bits compile it. My > experience is that it usually takes some time for RMS to grant a license > exception, and that he may not choose to do it. I will do so early next week and send a patch to disable dbl-64 compilation for now. Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
On Mar 17, 2006, at 2:07 PM, Mark Mitchell wrote: So, I think you should remove the dbl-64 code until this is resolved, or at least prevent it from being compiled by removing whatever Makefile bits compile it :-( At the outside, I'd say that in 7 days it should not be in mainline nor any release branch if permission isn't secured.
Re: FSF Policy re. inclusion of source code from other projects in GCC
Richard Guenther wrote: > Remembering the patches from Joseph these were from a different part > of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and > dbl-64 which contain C implementations of C99 math intrinsics such as > sin and cos. The flt-32 parts are public domain as in > > /* > * > * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. > * > * Developed at SunPro, a Sun Microsystems, Inc. business. > * Permission to use, copy, modify, and distribute this > * software is freely granted, provided that this notice > * is preserved. > * > */ > > while the dbl-64 parts are LGPL and so subject to the change to GPL > + exception. I don't know if these parts of GLIBC are covered by RMS's > permission, it is probably advisable to ask. I think that we need to ask RMS specifically about this. Would you please send a message to RMS, and copy the SC list (is that address public? I'm not sure if I'm supposed to give it out, ask me privately if you don't know it) on the mail. Explain the situation, including what code you're importing and why you want an exception. My guess is that it's OK to include the Sun code, since it's in the public domain. My guess is also that, without explicit permission from RMS, you have to leave the LGPL on the dbl-64 code, since it doesn't sound like that is covered by "software floating-point emulation". That means that people who linked with this library would find that the LGPL applies, which is contrary to our general policy that binaries produced by GCC are not subject to GPL/LGPL issues. So, I think you should remove the dbl-64 code until this is resolved, or at least prevent it from being compiled by removing whatever Makefile bits compile it. My experience is that it usually takes some time for RMS to grant a license exception, and that he may not choose to do it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
Joe Buck wrote: > On Fri, Mar 17, 2006 at 01:23:36PM -0800, Mark Mitchell wrote: >> Richard Guenther wrote: >>> Do I understand this correctly that the upstream GLIBC versions of the >>> files will get their license changed, or will this happen only in the GCC >>> copy? >> Only in the GCC copy. > > Maybe we should check that question with RMS. After all, RMS is the one > who doesn't want us to fork imported code; aren't we talking about forking > at least the license? There would be two distinct copies of certain > files, differing only in the license text. Yes, but they will have to differ anyhow so that they can proclaim that they are not part of GCC. So, I think it is clear what the files should say in the GCC repository. I will ask RMS if the files should change in the GLIBC repository as well, but it doesn't need to affect Joseph's (as of yet unreviewed) patch. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
Richard Guenther wrote: > I understand it in the way that we should modify the imported parts > upstream (or not), while we can for sure add glues and wrappers or > other thinks to libgcc-math. Yes, you can add glue/wrappers. > So this discussion only affects flt-32 > and dbl-64 directories. I don't think this will make the libstdc++-v3 > issues impossible - maybe a little harder. If there will be a point where > a true fork is inevitable, we can politely ask again. Indeed. However, RMS has indicated the first approach should be to approach the GLIBC folks, and that they should be willing to accomodate reasonable changes, even if those changes aren't directly beneficial to GLIBC itself. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
Gabriel Dos Reis wrote: > I am confused. My interest in libgcc-math is that it helps solve > thorny issues with libstdc++-v3 and my expectation is that we can make > modification to libgcc-math so that we can't advantage of it. Now, I > understand that we cannot make modification to libgcc-math without > modifying GLIBC? Is that correct. Yes, that is correct. It would take additional special dispensation from the FSF to modify the GLIBC code. RMS wants such modifications to be submitted upstream first, to avoid forks. You could ask RMS for that additional permission, if you want. Please do not ask me to interpret or justify all of the rules; I don't understand the issues sufficiently well. I am just passing along the results of a long discussion with RMS on the SC list. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 17 Mar 2006 22:44:37 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > Mark Mitchell <[EMAIL PROTECTED]> writes: > > [...] > > | >> Because RMS has approved the use of GLIBC's software floating-point code > | >> in GCC's runtime libraries, using GPL + exception, the correct thing for > | >> Joseph Myers to do with his recent patch is to mark those files as not > | >> part of GCC, but rather as part of GLIBC, and adjust the copyright > | >> notice to be GPL + exception. Joseph should also document (in a README > | >> or similar) that these files are not to be changed, except by import > | >> from upstream GLIBC. > | > > | > Do I understand this correctly that the upstream GLIBC versions of the > | > files will get their license changed, or will this happen only in the GCC > | > copy? > | > | Only in the GCC copy. > | > | I don't understand enough about libgcc-math to know what should happen > | there; I don't even know what bits of GLIBC you used. RMS has given > | explicit permission to use GPL + exception for the software > | floating-point emulation code, but not for any other part of GLIBC. > > I am confused. My interest in libgcc-math is that it helps solve > thorny issues with libstdc++-v3 and my expectation is that we can make > modification to libgcc-math so that we can't advantage of it. Now, I > understand that we cannot make modification to libgcc-math without > modifying GLIBC? Is that correct. I understand it in the way that we should modify the imported parts upstream (or not), while we can for sure add glues and wrappers or other thinks to libgcc-math. So this discussion only affects flt-32 and dbl-64 directories. I don't think this will make the libstdc++-v3 issues impossible - maybe a little harder. If there will be a point where a true fork is inevitable, we can politely ask again. Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
Mark Mitchell <[EMAIL PROTECTED]> writes: [...] | >> Because RMS has approved the use of GLIBC's software floating-point code | >> in GCC's runtime libraries, using GPL + exception, the correct thing for | >> Joseph Myers to do with his recent patch is to mark those files as not | >> part of GCC, but rather as part of GLIBC, and adjust the copyright | >> notice to be GPL + exception. Joseph should also document (in a README | >> or similar) that these files are not to be changed, except by import | >> from upstream GLIBC. | > | > Do I understand this correctly that the upstream GLIBC versions of the | > files will get their license changed, or will this happen only in the GCC | > copy? | | Only in the GCC copy. | | I don't understand enough about libgcc-math to know what should happen | there; I don't even know what bits of GLIBC you used. RMS has given | explicit permission to use GPL + exception for the software | floating-point emulation code, but not for any other part of GLIBC. I am confused. My interest in libgcc-math is that it helps solve thorny issues with libstdc++-v3 and my expectation is that we can make modification to libgcc-math so that we can't advantage of it. Now, I understand that we cannot make modification to libgcc-math without modifying GLIBC? Is that correct. -- Gaby
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >> Because RMS has approved the use of GLIBC's software floating-point code > >> in GCC's runtime libraries, using GPL + exception, the correct thing for > >> Joseph Myers to do with his recent patch is to mark those files as not > >> part of GCC, but rather as part of GLIBC, and adjust the copyright > >> notice to be GPL + exception. Joseph should also document (in a README > >> or similar) that these files are not to be changed, except by import > >> from upstream GLIBC. > > > > Do I understand this correctly that the upstream GLIBC versions of the > > files will get their license changed, or will this happen only in the GCC > > copy? > > Only in the GCC copy. > > I don't understand enough about libgcc-math to know what should happen > there; I don't even know what bits of GLIBC you used. RMS has given > explicit permission to use GPL + exception for the software > floating-point emulation code, but not for any other part of GLIBC. Remembering the patches from Joseph these were from a different part of GLIBC than I imported. I imported parts of sysdeps/ieee754/flt-32 and dbl-64 which contain C implementations of C99 math intrinsics such as sin and cos. The flt-32 parts are public domain as in /* * * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. * * Developed at SunPro, a Sun Microsystems, Inc. business. * Permission to use, copy, modify, and distribute this * software is freely granted, provided that this notice * is preserved. * */ while the dbl-64 parts are LGPL and so subject to the change to GPL + exception. I don't know if these parts of GLIBC are covered by RMS's permission, it is probably advisable to ask. Modifications local to GCC happened to fix issues with the build environment, namely that the glibc files assume they are built in an environment which has glibc available, while GCC needs to build on hosts with other C89 conforming environments. I think these changes are safe to be included upstream and I will try to get them accepted. Thanks, Richard.
Re: FSF Policy re. inclusion of source code from other projects in GCC
On Fri, Mar 17, 2006 at 01:23:36PM -0800, Mark Mitchell wrote: > Richard Guenther wrote: > > Do I understand this correctly that the upstream GLIBC versions of the > > files will get their license changed, or will this happen only in the GCC > > copy? > > Only in the GCC copy. Maybe we should check that question with RMS. After all, RMS is the one who doesn't want us to fork imported code; aren't we talking about forking at least the license? There would be two distinct copies of certain files, differing only in the license text. > I don't understand enough about libgcc-math to know what should happen > there; I don't even know what bits of GLIBC you used. RMS has given > explicit permission to use GPL + exception for the software > floating-point emulation code, but not for any other part of GLIBC. Maybe the answer, then, should be that only the files involved in floating-point emulation should get the new license. But I guess we need to ask what the FSF wants to do here.
Re: FSF Policy re. inclusion of source code from other projects in GCC
Richard Guenther wrote: > On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> Richard Guenther, would you please add a README to libgcc-math >> explaining that it that the GLIBC code is not part of GCC, as per the >> web page above? Also, please document that all of the GLIBC files are > > I will do so. Thank you. >> Because RMS has approved the use of GLIBC's software floating-point code >> in GCC's runtime libraries, using GPL + exception, the correct thing for >> Joseph Myers to do with his recent patch is to mark those files as not >> part of GCC, but rather as part of GLIBC, and adjust the copyright >> notice to be GPL + exception. Joseph should also document (in a README >> or similar) that these files are not to be changed, except by import >> from upstream GLIBC. > > Do I understand this correctly that the upstream GLIBC versions of the > files will get their license changed, or will this happen only in the GCC > copy? Only in the GCC copy. I don't understand enough about libgcc-math to know what should happen there; I don't even know what bits of GLIBC you used. RMS has given explicit permission to use GPL + exception for the software floating-point emulation code, but not for any other part of GLIBC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 3/17/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Richard Guenther, would you please add a README to libgcc-math > explaining that it that the GLIBC code is not part of GCC, as per the > web page above? Also, please document that all of the GLIBC files are I will do so. > not to be changed, except by reimporting from GLIBC. If any of the > GLIBC files have been changed from their upstream sources, please submit > those changes to the GLIBC maintainers ASAP. I will try to get the (minor) changes accepted upstream. > Because RMS has approved the use of GLIBC's software floating-point code > in GCC's runtime libraries, using GPL + exception, the correct thing for > Joseph Myers to do with his recent patch is to mark those files as not > part of GCC, but rather as part of GLIBC, and adjust the copyright > notice to be GPL + exception. Joseph should also document (in a README > or similar) that these files are not to be changed, except by import > from upstream GLIBC. Do I understand this correctly that the upstream GLIBC versions of the files will get their license changed, or will this happen only in the GCC copy? Thanks, Richard.
