...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license issues on string routines, the upcoming 2010.10 release, the lifecycle of Linaro GCC 4.4, potential Windows builds, and the blueprints for next cycle.
-- Michael
On Wed, 6 Oct 2010, Michael Hope wrote:
...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license issues on string routines, the upcoming 2010.10 release, the lifecycle of Linaro GCC 4.4, potential Windows builds, and the blueprints for next cycle.
From the minutes:
| * ARM wish to keep rights for anything ARM produces, perhaps | through back grant | * Future code will be done by Linaro, so by others | * Issue is with copyright instead of license | * MIT/X11 does allow relicensing | * ACTION: Does BSD allow relicensing? | * GLIBC is a interesting case | + GLIBC prefers copyright assignment to FSF and re-licensing | under the LGPL | + This assignment may inhibit Linaro from re-granting back to | ARM
Isn't the FSF copyright assignment non exclusive, i.e. the original copyright holder still keeps a right to do anything with his own copy?
Nicolas
On 10/05/2010 06:35 PM, Nicolas Pitre wrote:
From the minutes:
| * ARM wish to keep rights for anything ARM produces, perhaps | through back grant | * Future code will be done by Linaro, so by others | * Issue is with copyright instead of license | * MIT/X11 does allow relicensing | * ACTION: Does BSD allow relicensing? | * GLIBC is a interesting case | + GLIBC prefers copyright assignment to FSF and re-licensing | under the LGPL | + This assignment may inhibit Linaro from re-granting back to | ARM
Isn't the FSF copyright assignment non exclusive, i.e. the original copyright holder still keeps a right to do anything with his own copy?
I put on the audio of this conference call in the background today, because intellectual property is a topic that interests/infuriates me. If I understood the current situation correctly, the principle point of contention relates to the FSF's position on patents, which translates into "ARM's lawyers will not sign the standard FSF assignment."
During this part of the discussion, it was revealed that the existing assignment agreements for GCC and GDB involve confidential terms which address those problems. They have not worked out such details for GLIBC. Personally, I am intensely curious about those exact terms, though we are unlikely to ever discover the details.
Thus, there exist assignment issues that go beyond simple copyrights. Speculatively, I believe the wording of the FSF assignment basically requires all patents to be assigned along with the copyrights. If you think about the wording of the GNU licenses, that language appears to be strictly necessary for the FSF. Simultaneously, that would give good reason for ARM's lawyers to be recalcitrant. Or so I imagine.
I am eager to see how this soap opera gets resolved, but it will be entirely anticlimactic if more undisclosed terms cut through the red tape.
Ah, there's all types of things going on here. It's an unusual one as string routines such as memcpy() are fundamental and self contained and pointless to reimplement. I want to share them almost as a gift, usable by anyone under any terms and, ideally, to allow third party improvements to be freely shared. We want the same routines to end up in Newlib, Bionic, and proprietary projects.
Copyright Linaro under the MIT/X11 license allows this, but the GLIBC steering committee prefers copyright FSF under the LGPL. MIT/X11 allows re-licensing but doesn't handle the copyright assignment.
I'm writing this up at the moment at: https://wiki.linaro.org/WorkingGroups/ToolChain/StringLicensing
Don't think of this as a ARM Inc. problem. There's many considerations involved here.
-- Michael
On Wed, Oct 6, 2010 at 2:35 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 6 Oct 2010, Michael Hope wrote:
...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license issues on string routines, the upcoming 2010.10 release, the lifecycle of Linaro GCC 4.4, potential Windows builds, and the blueprints for next cycle.
From the minutes:
| * ARM wish to keep rights for anything ARM produces, perhaps | through back grant | * Future code will be done by Linaro, so by others | * Issue is with copyright instead of license | * MIT/X11 does allow relicensing | * ACTION: Does BSD allow relicensing? | * GLIBC is a interesting case | + GLIBC prefers copyright assignment to FSF and re-licensing | under the LGPL | + This assignment may inhibit Linaro from re-granting back to | ARM
Isn't the FSF copyright assignment non exclusive, i.e. the original copyright holder still keeps a right to do anything with his own copy?
Nicolas
On Wed, 6 Oct 2010, Michael Hope wrote:
Ah, there's all types of things going on here. It's an unusual one as string routines such as memcpy() are fundamental and self contained and pointless to reimplement. I want to share them almost as a gift, usable by anyone under any terms and, ideally, to allow third party improvements to be freely shared.
They should be put into the public domain then.
We want the same routines to end up in Newlib, Bionic, and proprietary projects.
... which public domain would allow.
Copyright Linaro under the MIT/X11 license allows this, but the GLIBC steering committee prefers copyright FSF under the LGPL. MIT/X11 allows re-licensing but doesn't handle the copyright assignment.
Public domain is effectively uncopirighted, so no more copyright assignment issues.
Nicolas
Sorry, I should clarify my earlier post. I did not mean to insinuate that ARM (or their lawyers) have created this problem.
However, they are the author's and copyright holders of the code in question. Nico asked specifically about the FSF assignment, and my answer was aimed at that specific situation. I just tried to make the facts as I understood them pleasant to read, but I apologize if my wording was in any way offensive to ARM. As you have correctly pointed out, the situation is far more complex than that singular facet.
No, this problem derives from the mess of intellectual property laws that must be respected in order to preserve the integrity of the myriad of projects that want to be using this code, while still allowing all future improvements to flow seamless between them. It's a complicated situation fraught with legal pitfalls, and I seriously doubt that anyone involved meant to create it.
I am sure we all wish that these matters would just resolve themselves.
On 10/05/2010 07:47 PM, Michael Hope wrote:
Ah, there's all types of things going on here. It's an unusual one as string routines such as memcpy() are fundamental and self contained and pointless to reimplement. I want to share them almost as a gift, usable by anyone under any terms and, ideally, to allow third party improvements to be freely shared. We want the same routines to end up in Newlib, Bionic, and proprietary projects.
Copyright Linaro under the MIT/X11 license allows this, but the GLIBC steering committee prefers copyright FSF under the LGPL. MIT/X11 allows re-licensing but doesn't handle the copyright assignment.
I'm writing this up at the moment at: https://wiki.linaro.org/WorkingGroups/ToolChain/StringLicensing
Don't think of this as a ARM Inc. problem. There's many considerations involved here.
-- Michael
On Wed, Oct 6, 2010 at 2:35 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Wed, 6 Oct 2010, Michael Hope wrote:
...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license issues on string routines, the upcoming 2010.10 release, the lifecycle of Linaro GCC 4.4, potential Windows builds, and the blueprints for next cycle.
From the minutes:
| * ARM wish to keep rights for anything ARM produces, perhaps | through back grant | * Future code will be done by Linaro, so by others | * Issue is with copyright instead of license | * MIT/X11 does allow relicensing | * ACTION: Does BSD allow relicensing? | * GLIBC is a interesting case | + GLIBC prefers copyright assignment to FSF and re-licensing | under the LGPL | + This assignment may inhibit Linaro from re-granting back to | ARM
Isn't the FSF copyright assignment non exclusive, i.e. the original copyright holder still keeps a right to do anything with his own copy?
Nicolas
On 10/5/2010 8:11 PM, Zach Welch wrote:
No, this problem derives from the mess of intellectual property laws that must be respected in order to preserve the integrity of the myriad of projects that want to be using this code, while still allowing all future improvements to flow seamless between them.
And that "all future improvements" is where this gets really tricky. You can put BSD code into GLIBC. (You may not be able to get the FSF to put it into FSF GLIBC without an assignment, but you can ship an Ubuntu GLIBC built this way. Perhaps the EGLIBC members might consider waiving the requirement for FSF assignment for EGLIBC, and you could get the patch in EGLIBC. Etc.)
But, if I'm a downstream GLIBC developer, and I choose to improve your memcpy, and I do so in the context of GLIBC, my changes are quite likely to be LGPL. And you won't get to put those into Bionic, say.
So, if you really want this, the best solution is probably to have an upstream "string routines" project and host the code there, and encourage libc's of all flavors to incorporate that code, and to contribute changes there. But, you probably have better luck if you do not restrict it to ARM; i.e., if you are willing to also accept code for other CPUs, and even share algorithmic infrastructure that's common across various CPUs. You also want to design for some of the differences between a statically linked libc and a dynamic libc.
On 10/06/2010 05:38 AM, Michael Hope wrote:
...are available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-10-04
A recording of the call is available here: http://tc.seabright.co.nz/toolchainwg/
Interesting topics include a discussion on the copyright and license issues on string routines, the upcoming 2010.10 release, the lifecycle of Linaro GCC 4.4, potential Windows builds, and the blueprints for next cycle.
In the minute,
| Open sessions: | We have a few at Linaro@UDS
Where can I find them? http://summit.ubuntu.com/uds-n/ doesn't give me much information on Linaro@UDS. I assume that sessions or topics are listed somewhere, but I can't find it.
On Wed, Oct 6, 2010 at 4:56 PM, Yao Qi yao@codesourcery.com wrote:
On 10/06/2010 05:38 AM, Michael Hope wrote: | Open sessions: | We have a few at Linaro@UDS
Where can I find them? http://summit.ubuntu.com/uds-n/ doesn't give me much information on Linaro@UDS. I assume that sessions or topics are listed somewhere, but I can't find it.
The open sessions are for us to cover any topics we are interested in. I'd be interested in everyone's suggestions.
-- Michael
linaro-toolchain@lists.linaro.org
-
Mark Mitchell -
Michael Hope -
Nicolas Pitre -
Yao Qi -
Zach Welch