distribution of go executables

[R Srinivasan]

what if any are the licensing requirements to distribute a "go" produced executable?

are there any "commercial" products built with go?

thanks for any info, srini

[Ian Lance Taylor]

On Tue, Feb 26, 2019 at 10:59 AM R Srinivasan <s...@srin.me> wrote:
>
> what if any are the licensing requirements to distribute a "go" produced executable?

See https://go.googlesource.com/go/+/refs/heads/master/LICENSE . The
requirements are minimal.

> are there any "commercial" products built with go?

Yes, quite a few. You may want to look at https://golang.org/wiki/GoUsers.

Ian

[David Golden]

(IANAL; this is not legal advice)

Generally, the historic principle has been that your source code transformed by an open source compiler to produce your binary is unrestricted.  (Interesting historical note, the Perl Artistic License is one of the few licenses that was explicit that the output of your program belongs to you.)

The tricky bit is that your compiled Go program isn't *just* your source, it's the Go runtime as well, plus any other core Go libraries that you import.  Because those are open source, your are required to distribute a list of such third party copyrights & licenses either with your documentation or in some UI with your program.

If you've ever delved into, say, an Android phone's "Settings -> About Phone -> Legal Information -> Third Party Licenses" menu, you can see how that might appear.  In the case of MongoDB, for instance, along with the binaries in a tarball we ship a THIRD-PARTY-NOTICES text file with a list of all open source packages and licenses used.  Either approach satisfies the requirements of open source licenses.

Regards,

David

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Space A.]

Mentioned license doesn't cover binaries produced by compiler, "binary form" there means go tools themselves, and stdlib only when redistributed separately as a whole in binary form. When stdlib is used to compile regular binary, it's not "redistributed", and there are no restrictions or special requirements at all.

Correct answer: if you are using only stdlib and Go compiler to compile a binary - there are no requirements. If you are using 3rd parties libs / binaries / sources - read their licenses.

среда, 27 февраля 2019 г., 2:18:45 UTC+3 пользователь Ian Lance Taylor написал:

[Ian Denhardt]

Quoting Space A. (2019-02-26 20:58:40)

> and stdlib only when redistributed separately as a whole in binary
> form. When stdlib is used to compile regular binary, it's not
> "redistributed"

This is not my understanding; in general static linking constitutes
distribution (though you are correct re: compiler output of your own
code).

> Correct answer

The "correct answer," really, is to ask someone actually qualified to
give you legal advice.

-Ian

[Space A.]

You are wrong.

среда, 27 февраля 2019 г., 5:22:12 UTC+3 пользователь Ian Denhardt написал:

[Dan Kortschak]

Probably not. The executable is a derivative work under most
understandings (this is the basis for the GPL to require that source
code be provided if the executable is distributed to an end user).

Any work writen in Go, using the stdlib (which includes runtime, so all
Go programs) is derivative of the stdlib. This means that the Go
license pertains.

[Space A.]

Executable is not derivative work to stdlib or anything. Go's repo license covers only repo. Stdlib is not redistributed when you compile binary. It has nothing to do with GPL. Go's license is simple and clear.

ср, 27 февр. 2019 г., 6:00 Dan Kortschak <d...@kortschak.io>:

[Dan Kortschak]

In-line

On Wed, 2019-02-27 at 06:31 +0300, Space A. wrote:
> Executable is not derivative work to stdlib or anything.

I think you'll find this is not the case in most jurisdictions. It is
certainly not true here, and probably also not in the US.

From https://www.copyright.gov/circs/circ14.pdf

"A derivative work is a work based on or derived from one or more
already existing works."

> Go's repo license covers only repo.

No.

Point 2:

"Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution."

Note that redistribution is based on the notion of derivative works
above. The binary is a derivative of the source code, which is, in this
case the standard library.

> Stdlib is not redistributed when you compile binary.

Yes it is, in a derivative form.

> It has nothing to do with GPL.

The licenses are different. In this sense you are absolutely correct,
this has nothing to do with the GPL. However, in another, far more
correct sense, it is indeed related. Both the GPL and the BSD3 are
based on the notions that make copyright work. The licensing of the
work is based on that fact that the copyright owner has a sole right to
distribute the work. This is licensed to the recipient under a set of conditions based on well established definitions of "derivative" and "redistribute". Those two terms are shared by the GPL and BSD3.

Note that the LGPL goes to lengths to distinguish between the binary of
the licensed work and items that are derivative, but dynamically
linked, purely because of the connection between the original source
and the binary that is the resulting executable (i.e. not the binary
representation of the library).

> Go's license is simple and clear.

And yet, here we are. The short answer to this question is that a
lawyer should be consulted.

[Space A.]

You have very poor understanding of the subject, messing everything up.

There is no "derivatives" in Go's license terms at all. There is only redistribution in binary and source form and it covers only what's in the repo (https://github.com/golang/go/blob/master/LICENSE).

Compilation is not redistribution.

PS: Don't want to spend to much time on this, but just to point out -  derivative is NOT a kind of sophistic mess when something is just based on something. You can fork stdlib, add some extra changes and distribute it as "stdlib v.2 improved" - in this case this would become derivative. If you just use stdlib for your work, your work is not derivative from stdlib. And if you want to talk in copyright laws terms, lets start from the point that programming languages can't be protected by copyright at all (like "idea", "concept", etc - same).

The short answer to this question is that a
lawyer should be consulted.

This is 100% clear case and you can distribute your compiled binaries free, without any additional requirements, restrictions, giving or not credits, or binding yourself to some specific license, what so ever.

C'mon guys.

ср, 27 февр. 2019 г. в 07:24, Dan Kortschak <d...@kortschak.io>:

[David Golden]

On Wed, Feb 27, 2019 at 9:20 AM Space A. <reexi...@gmail.com> wrote:

There is no "derivatives" in Go's license terms at all. There is only redistribution in binary and source form and it covers only what's in the repo (https://github.com/golang/go/blob/master/LICENSE). 

Compilation is not redistribution. 

For a C compiler that could be true.  For Go's compiler, it also compiles the source code in the repo for the runtime -- e.g. memory allocation, garbage collection, concurrency management, etc.  If a program uses any of the core Go libraries, the same applies.  That source code is being "redistributed in binary form" by being statically compiled into the final executable.

Thus, distribution of a Go executable requires including third party notices to cover the redistribution of the runtime and core libraries compiled into that executable.

Regards,
David

[Jan Mercl]

On Wed, Feb 27, 2019 at 3:20 PM Space A. <reexi...@gmail.com> wrote:

> This is 100% clear case and you can distribute your compiled binaries free, without any additional requirements, restrictions, giving or not credits, or binding yourself to some specific license, what so ever. 

That's not correct. Quoting from https://go.googlesource.com/go/+/refs/heads/master/LICENSE

=================================================
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

...

* Redistributions in binary form must reproduce the above

copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.

...

=================================================

By distributing a program compiled by the Go compiler, one is distributing the binary form of some parts of the run time library and also possibly the binary form of some parts of the standard library, all of which are covered by the said LICENSE.

The LICENSE mandates that this can be legally done only while satisfying the conditions highlighted above.

--

-j

[Manlio Perillo]

On Wednesday, February 27, 2019 at 2:58:40 AM UTC+1, Space A. wrote:

Mentioned license doesn't cover binaries produced by compiler, "binary form" there means go tools themselves, and stdlib only when redistributed separately as a whole in binary form. When stdlib is used to compile regular binary, it's not "redistributed", and there are no restrictions or special requirements at all.

Correct answer: if you are using only stdlib and Go compiler to compile a binary - there are no requirements. If you are using 3rd parties libs / binaries / sources - read their licenses.

No, **there is**  a requirement:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

This requirement does not only apply when you redistribute a (possibly) modified version of the Go compiler, but also to the standard library.

So you have to link the Go License in your documentation, when you redistribuite a Go program, since **every** Go program implicitly imports the runtime package.

But I'm not really sure.

Manlio Perillo

[Space A.]

Jan, good that you read my link, however I already answered on this (quoting myself):

Mentioned license doesn't cover binaries produced by compiler, "binary form" there means go tools themselves, and stdlib only when redistributed separately as a whole in binary form. When stdlib is used to compile regular binary, it's not "redistributed", and there are no restrictions or special requirements at all.

What you're saying

By distributing a program compiled by the Go compiler, one is distributing the binary form of some parts of the run time library and also possibly the binary form of some parts of the standard library, all of which are covered by the said LICENSE.

No, No, and yet one time No. You are wrong. By distributing your compiled binary you are not "distributing" anything from the repo and it's not the LICENSE's covered case. You are not restricted in any way.

ср, 27 февр. 2019 г. в 17:41, Jan Mercl <0xj...@gmail.com>:

[Jan Mercl]

On Wed, Feb 27, 2019 at 3:47 PM Space A. <reexi...@gmail.com> wrote:

> Mentioned license doesn't cover binaries produced by compiler, "binary form" there means go tools themselves ...

That would mean that once a copyrighted source code is compiled to binary form, the source code copyright holders LICENSE terms no more apply.

That's not the case in most jurisdictions. Proof by contradiction is left as an exercise...

--

-j

[Space A.]

Regarding runtime - it's interesting (and separate question maybe), and I would argue that runtime IS part of language itself because language is not only a syntax. It also a garbage collector, a goroutines, etc, as you mentioned. You just can't write Go program without having runtime. It's not possible. So, that means that being part of the language, according to copyright laws, runtime can't be covered by copyright and restricted by a license.

ср, 27 февр. 2019 г. в 17:36, 'David Golden' via golang-nuts <golan...@googlegroups.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/6cNpXIE_18c/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.

[Space A.]

No that means that it will depend on what's written in this particular license given by creator of this source codes. It's case by case. For example they can say that compilation is not allowed at all. Go's repo license is clear without any "derivatives" "commercial" or "personal" complex use cases, etc.

ср, 27 февр. 2019 г. в 17:55, Jan Mercl <0xj...@gmail.com>:

--

[Ian Lance Taylor]

On Wed, Feb 27, 2019 at 6:56 AM Space A. <reexi...@gmail.com> wrote:
>
> Regarding runtime - it's interesting (and separate question maybe), and I would argue that runtime IS part of language itself because language is not only a syntax. It also a garbage collector, a goroutines, etc, as you mentioned. You just can't write Go program without having runtime. It's not possible. So, that means that being part of the language, according to copyright laws, runtime can't be covered by copyright and restricted by a license.

As others have said, if this really matters to you, you should consult
a lawyer who deals with copyright issues, and you should look into the
relevant laws and cases in the jurisdiction that applies to you.
Personally I do not think the statement above is correct in the U.S.,
but I am not a lawyer.

In any case you cannot go wrong by following the requirements in the
Go license, which are simple enough, and are an instance of the widely
used BSD license.

Ian

[Manlio Perillo]

You may look at https://www.gnu.org/licenses/gcc-exception-3.1-faq.html for a reference.

Manlio Perillo

[Louki Sumirniy]

There is one place where derivative is irrelevant, that would be where a patent sticks to the algorithm, and this patently idiotic situation is not universally applicable, some jurisdictions never added this kind of lunacy to copyright law (unfortunately, not all).

As I understand it, the licence on the Google official Go compiler makes absolutely no restrictions on *your* source code, nor the binaries the compiler creates from them, regardless of the fact it imports the standard library. Specifically, and in practise, the library links your code to the *compiled* binary objects created from the source of the stdlib. Besides, that would be quite inefficient anyway.

I think it should be obvious that a programmer's studio should not feel like a courtroom, or one has quite misplaced priorities on the whole business of facilitating development of new software.

I could say more about my opinions on copyright but I'll let the licences I put on my stuff speak for me.

[Louki Sumirniy]

This would only be true if *derivatives* were specified. Go links everything static by default, so in *very* broad terms, the binaries are derivative of the stdlib in the distributed go compiler package. I think really the proper way to look at this is this exact subject is simply not mentioned, only distantly implied in a specific way of interpreting it, and it would not be open-and-shut in a law court. 

Since the compiler produces static binaries by default, I think it should be explicated in the licence that embedding the unmodified binary objects does not qualify as 'derivation' and licence terms do not apply. It's no problem right now, but it seems to me the licence does give wiggle room to Google to play silly buggers on the margins of this.

And on the other side, what about when I build the binaries of stdlib using gcc or some other mostly complete not-google implementation? Seems to me the licence would cover this, and thus require the distribution of that licence.

So I'm just going to quietly suggest that the licence needs to be revised.

[Robert Engels]

You are not correct. There are current cases where apis are being claimed to be copyrighted. It is under active litigation. 

--

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Robert Engels]

That is incorrect thinking. And again, it is all subject to litigation. Whether you are right or wrong is up to the courts to decide. 

You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Space A.]

Same again, messing everything. It's not API, we are talking about distributing compiled executables.

ср, 27 февр. 2019 г. в 21:36, Robert Engels <ren...@ix.netcom.com>:

[Space A.]

It's very clear case. It will never become a case in a court. Otherwise, if it ever will, I mean, compiling own program and distributing a binary which used stdlib e.g. without kissing someone's ass - language is dead.

ср, 27 февр. 2019 г. в 21:39, Robert Engels <ren...@ix.netcom.com>:

[Robert Engels]

You are not correct. You might wish to read this https://en.m.wikipedia.org/wiki/GPL_linking_exception which covers many of the same issues, and how they think they resolved it. 

[Dan Kortschak]

Pull your head in and stop being rude to people here.

[Space A.]

GPL is another license with different terms, I would say offtopic.

ср, 27 февр. 2019 г. в 21:55, Robert Engels <ren...@ix.netcom.com>:

[Space A.]

Sorry? You have poor understanding and mess things, so what's wrong? Being dilatant is not crime, it's okay unless you start convincing yourself that false is true.

ср, 27 февр. 2019 г. в 22:41, Dan Kortschak <d...@kortschak.io>:

[Dan Kortschak]

You're claiming expertise in copyright law in at least two
jurisdictions, and claiming greater understanding of Australian
copyright legislation than a person who has had training in Australian
copyright legislation as part of their employment.

I'm done here.

[Space A.]

I could, of course, however I never did. And I'd like to keep myself out of the scope of discussion. If you re-read my messages, you'll find they were focused on topic, not shifting to persons. Thank you for your participation, it's always good to hear different opinions, even if they are not correct.

ср, 27 февр. 2019 г. в 23:35, Dan Kortschak <d...@kortschak.io>:

[Dan Kortschak]

Please read https://golang.org/conduct

Your comments here have been in my view contrary to this document.