Go, LGPL and static linking pitfalls

[LRN]

LGPL (at least LGPLv3) is mostly used for shared libraries, but you
can do static linking as well, you just need to provide object files
(not source files) for the whole program, so that end user can re-link
it with a different version of the library. I've asked FSF to clarify
that, should hear back from them in a couple of months.

Meanwhile, here's a HelloWorld program i've used:
---------------main.go------------------
package main

import (
"fmt"
"libhelloworld"
)

func main() {
fmt.Printf(libhelloworld.GetRandomHello ())
}
---------------------------------
---------------libhelloworld.go------------------
package libhelloworld

import (
"rand"
"fmt"
"time"
)

var langs = []string {
"en_US",
"ru_RU",
"gr_GR",
"jp_JP"}

var hellos = map[string]string {
"en_US" : "Hello, World",
"ru_RU" : "Здравствуй, Мир",
"gr_GR" : "Καλημέρα κόσμε",
"jp_JP" : "こんにちは 世界",
}

func GetRandomHello () string {
rand.Seed (time.Nanoseconds ())
n := rand.Intn (len (langs))
return hellos[langs[n]]
}
---------------------------------
You can run:
8g libhelloworld.go
8g main.go
8l -L . main.8
then run main.out a few times and see [mostly] different helloworld
printed every time.

Then modify libhelloworld.go (for example, remove all map pairs,
except for "en_US" one), run
8g libhwlloworld.go
8l -L . main.8
and run main.out again to see that now you only get English
helloworld, and you didn't need to re-compile main.8 to make the
change (hence, you don't need main.go, only main.8).

Ok, this is a bit silly, but you never know.
But what if main.8 was compiled with older/newer version of the
compiler (or a different compiler)? Are there any other problems with
this scheme?

[Kyle Lemons]

Ok, this is a bit silly, but you never know.
But what if main.8 was compiled with older/newer version of the
compiler (or a different compiler)? Are there any other problems with
this scheme?

Currently you can only link object files created with an identical build of the compiler.

~K

[Gustavo Niemeyer]

> LGPL (at least LGPLv3) is mostly used for shared libraries, but you
> can do static linking as well, you just need to provide object files
> (not source files) for the whole program, so that end user can re-link
> it with a different version of the library. I've asked FSF to clarify
> that, should hear back from them in a couple of months.

The text of the LGPLv3 is very clear in that regard: only shared
linkage is accepted if you intend to use a different license in the
rest of the code, which excludes the way Go links them.

At Canonical we're talking to our lawyers right now and are writing
down a specific exception for all of the Go-related libraries exactly
because of that (there's no intention to force linked packages to buy
into the same license).

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.

[Russ Cox]

There's an easier solution here.

Russ

[Gustavo Niemeyer]

> There's an easier solution here.

I know.. all my personal libraries are licensed under Simplified BSD
(e.g. mgo, etc).

The detail is that LGPL is the standard open source license at
Canonical for libraries.. we're having some success introducing a new
language in the company.. and managed to get a +1 on introducing a
static-linkage exception too now. I'll try to pick one battle at a
time, and the most valuable ones first.

[LRN]

On Wed, Oct 5, 2011 at 9:09 PM, Gustavo Niemeyer <gus...@niemeyer.net> wrote:

> LGPL (at least LGPLv3) is mostly used for shared libraries, but you
> can do static linking as well, you just need to provide object files
> (not source files) for the whole program, so that end user can re-link
> it with a different version of the library. I've asked FSF to clarify
> that, should hear back from them in a couple of months.

The text of the LGPLv3 is very clear in that regard: only shared
linkage is accepted if you intend to use a different license in the
rest of the code, which excludes the way Go links them.

This is quoted from LGPLv3:

d) Do one of the following:

• 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
• 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

IANAL, but (0) appears to be saying that you need to provide the source code (MSC explicitly means the source code, not just any form of code) for the library, and the CAC (which could be source OR binary code, as long as it is sufficient for re-linking or re-combining, and as long as it is provided under a license that permits re-linking/re-combining) of the program, so that users can combine a different version of the library with the program.

On Wed, Oct 5, 2011 at 9:24 PM, Russ Cox <r...@golang.org> wrote:

There's an easier solution here.

Which is ...? Because i can't think of anything other than implementing dynamic linking for Go. Which doesn't seem to be happening.

[André Moraes]

> This is quoted from LGPLv3:
>
>> d) Do one of the following:
>>
>> 0) Convey the Minimal Corresponding Source under the terms of this
>> License, and the Corresponding Application Code in a form suitable for, and
>> under terms that permit, the user to recombine or relink the Application
>> with a modified version of the Linked Version to produce a modified Combined
>> Work, in the manner specified by section 6 of the GNU GPL for conveying
>> Corresponding Source.

Applying to this specific case: As long as the developer of the application,
provide the main.8, main.6, main.5 for one release of the gc compiler, he
will be compliant with the LGPL clause?

--
André Moraes
http://andredevchannel.blogspot.com/

[Gustavo Niemeyer]

> IANAL, but (0) appears to be saying that you need to provide the source code
> (MSC explicitly means the source code, not just any form of code) for the

FWIW, (0) says:

"(...) the user to recombine or relink the Application with a modified

version of the
Linked Version to produce a modified Combined Work, in the manner specified
by section 6 of the GNU GPL for conveying Corresponding Source."

Section 6 of the GNU GPL starts with:

"You may convey a covered work in object code form under the terms of sections
4 and 5, provided that you also convey the machine-readable Corresponding
Source under the terms of this License, in one of these ways: (...)"

I'm not and have zero intention of being a lawyer, though, and will
let you dig into it.

[LRN]

On Oct 5, 10:10 pm, Gustavo Niemeyer <gust...@niemeyer.net> wrote:
> > IANAL, but (0) appears to be saying that you need to provide the source code
> > (MSC explicitly means the source code, not just any form of code) for the
>
> FWIW, (0) says:
>
> "(...) the user to recombine or relink the Application with a modified
> version of the
> Linked Version to produce a modified Combined Work, in the manner specified
> by section 6 of the GNU GPL for conveying Corresponding Source."
>
> Section 6 of the GNU GPL starts with:
>
> "You may convey a covered work in object code form under the terms of sections
> 4 and 5, provided that you also convey the machine-readable Corresponding
> Source under the terms of this License, in one of these ways: (...)"

Ouch.
Well, that seems to rule out the static linking :(

Although it is not entirely clear (to me), which portions of GPL
Section 6 apply, and which do not. And it's not entirely clear why
LGPL would permit dynamic linking, but not this kind of static linking
(which allows re-linking).

Also, you can use an LGPL with special exception that explicitly
allows this kind of static linking. Currently i don't see too many
problems with that approach (you won't be able to derive this ExtLGPL-
covered code from LGPLed code, but with Go you are hardly able to do
so anyway, and linking to LGPLed libraries at run time is permissible,
as always). But it's hardly something new.

[Ian Lance Taylor]

André Moraes <and...@gmail.com> writes:

Yes. It is limiting because the end user will only be able to use the
exact version of the gc compiler which was used to compile main.6. But
it would suffice to meet the requirements of the LGPL.

Ian

[Ian Lance Taylor]

Gustavo Niemeyer <gus...@niemeyer.net> writes:

>> IANAL, but (0) appears to be saying that you need to provide the source code
>> (MSC explicitly means the source code, not just any form of code) for the
>
> FWIW, (0) says:
>
> "(...) the user to recombine or relink the Application with a modified
> version of the
> Linked Version to produce a modified Combined Work, in the manner specified
> by section 6 of the GNU GPL for conveying Corresponding Source."
>
> Section 6 of the GNU GPL starts with:
>
> "You may convey a covered work in object code form under the terms of sections
> 4 and 5, provided that you also convey the machine-readable Corresponding
> Source under the terms of this License, in one of these ways: (...)"
>
> I'm not and have zero intention of being a lawyer, though, and will
> let you dig into it.

The LGPL is not referring to the start of section 6, but rather to the
list of ways permitted to convey code which are enumerated in section 6.

Ian

[Gustavo Niemeyer]

>> I'm not and have zero intention of being a lawyer, though, and will
>> let you dig into it.
>
> The LGPL is not referring to the start of section 6, but rather to the
> list of ways permitted to convey code which are enumerated in section 6.

I thought that was clear from my message. I do not intend to copy the
whole LGPL here, or to explain its meaning really.

[Ian Lance Taylor]

Gustavo Niemeyer <gus...@niemeyer.net> writes:

>>> I'm not and have zero intention of being a lawyer, though, and will
>>> let you dig into it.
>>
>> The LGPL is not referring to the start of section 6, but rather to the
>> list of ways permitted to convey code which are enumerated in section 6.
>
> I thought that was clear from my message. I do not intend to copy the
> whole LGPL here, or to explain its meaning really.

Sorry about that, I misunderstood what you were saying.

Ian

[Bobby Powers]

On Wed, Oct 5, 2011 at 1:46 PM, LRN <lrn...@gmail.com> wrote:

On Wed, Oct 5, 2011 at 9:24 PM, Russ Cox <r...@golang.org> wrote:

There's an easier solution here.

Which is ...? Because i can't think of anything other than implementing dynamic linking for Go. Which doesn't seem to be happening.

Use a permissive license, like MIT or BSD

[LRN]

On Oct 6, 3:12 am, Bobby Powers <bobbypow...@gmail.com> wrote:

> On Wed, Oct 5, 2011 at 1:46 PM, LRN <lrn1...@gmail.com> wrote:
>
> > On Wed, Oct 5, 2011 at 9:24 PM, Russ Cox <r...@golang.org> wrote:
>
> >> There's an easier solution here.
>
> >> Which is ...? Because i can't think of anything other than implementing
> > dynamic linking for Go. Which doesn't seem to be happening.
>
> Use a permissive license, like MIT or BSD

Using a permissive license means that LGPL won't be used, so it's not
really a solution.
You might just as well suggest me to use C + shared libraries. That
would have allowed LGPL to be used for libraries, but the point was to
have both Go AND LGPL.