Licence details of github.com/golang/sync

[Denis Cheremisov]

Hi!

At my job we found these additional patents limitatations https://github.com/golang/sync/blob/master/PATENTS

They makes us impossible to use errgroup (which is, to say, turned to have pretty poor choice of WithContext signature, so our one is different), so we have our custom implementation of it with additonal functionality (errors collector, concurrency limitation), but it is derived from the original implementation.

I guess the repository should be called "github.com/google/sync" after that. Anyway, our product's proprietary licence makes it impossible to use our derived implementation. Is there a way to overcome this somehow? The problem is my own implementation would be really close to this and thus prone to a sue.

[Axel Wagner]

Disclaimer: IANAL.

On Thu, Oct 29, 2020 at 2:53 PM Denis Cheremisov <denis.ch...@gmail.com> wrote:

At my job we found these additional patents limitatations https://github.com/golang/sync/blob/master/PATENTS

They makes us impossible to use errgroup (which is, to say, turned to have pretty poor choice of WithContext signature, so our one is different),

Are you aware that the same patent grant also applies to Go itself?

https://github.com/golang/go/blob/master/PATENTS

I don't understand why you think this patent grant would prevent you from using Go or golang.org/x/sync - in fact, I'd argue that you'd probably have more problems using it *without* it, as you might be infringing on patents unintentionally then. Really, the only situation I can imagine this being a problem, is if you intend to sue Google over violating your patents by implementing Go, while continuing to benefit from that implementation (note that both the grant and the exceptions are specific to the Go implementation). Which… Well, TBH, my sympathies for your case would be fairly limited.

I guess the repository should be called "github.com/google/sync" after that.

It has been well established that Google is the copyright and trademark holder for Go. See also this fairly extensive post by Ian on this list:

https://groups.google.com/g/golang-nuts/c/6dKNSN0M_kg/m/EUzcym2FBAAJ

Anyway, our product's proprietary licence makes it impossible to use our derived implementation. Is there a way to overcome this somehow? The problem is my own implementation would be really close to this and thus prone to a sue. 

-- 

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b50fccd3-a026-4227-82ad-2e41e82cbea6n%40googlegroups.com.

[Ian Lance Taylor]

I don't understand how that patent grant could make it impossible for
you to use your derived implementation. Could you clarify that?

As Axel pointed out, exactly the same patent grant is provided for Go
itself. It was added soon after Go was released
(https://groups.google.com/d/msg/golang-nuts/j4gc6rIs0bc/gTuxjO3qgIMJ,
https://golang.org/cl/194066, https://golang.org/cl/3103042). I can't
find the messages any more, but my recollection is that it was added
at the specific request of the maintainers of the Fedora GNU/Linux
distro.

Ian

[Wojciech S. Czarnecki]

Dnia 2020-10-29, o godz. 06:52:17
Denis Cheremisov <denis.ch...@gmail.com> napisał(a):

> Hi!
> At my job we found these additional patents
> limitatations https://github.com/golang/sync/blob/master/PATENTS
> They makes us impossible to use errgroup (which is, to say, turned to have
> pretty poor choice of WithContext signature, so our one is different), so
> we have our custom implementation of it with additonal functionality
> (errors collector, concurrency limitation), but it is derived from the
> original implementation.

This list is not a proper venue to gather 'common-sense' legal advice, as such
advice will likely be at odds with your real legal standing regarding your software
under each next jurisdiction.

To be clear and a bit assured about your real situation you should hire a good attorneys
in each country of interest or hire a top-tier international law agency then make sure to
be very frank with them about what you did, what you do, and what you plan to do with
your implementation.

Hope this helps,

--
Wojciech S. Czarnecki
<< ^oo^ >> OHIR-RIPE

P.S. My "Common-sense" advice is this: as whole Go ecosystem is under this grant,
if it is stands against your planned deeds, you certainly should abandon Go right now
and switch to Java or Swift ASAP. There you'll be covered by Oracle's or Apple's
voluminouos license agreements that will make the "very close to" problem
disappear, as it will be clearly forbidden ;).

[Denis Cheremisov]

Well, as usual I wrote something in the way, not the real thing.

The case is:

- At my company we are using errgroup from that sync repo in one project,

  sync/errgroup in fact mostly.

- It proved to be error prone with its context shadowing on errgroup.WithContext

  so we took the original and adds context in the group itself via eg.Ctx() + 

  a couple of additional functionality.

Yesterday our attorney wrote us "we can't use sync because of this patents

note" as it works like a virus, and can't use our modification too for the same

reason. It turned out the stdlib is under the same note too, so we will have

fun times :) 

четверг, 29 октября 2020 г. в 20:09:59 UTC+3, ohir:

[Ian Lance Taylor]

On Thu, Oct 29, 2020, 10:48 PM Denis Cheremisov <denis.ch...@gmail.com> wrote:

Well, as usual I wrote something in the way, not the real thing.

The case is:

- At my company we are using errgroup from that sync repo in one project,

  sync/errgroup in fact mostly.

- It proved to be error prone with its context shadowing on errgroup.WithContext

  so we took the original and adds context in the group itself via eg.Ctx() + 

  a couple of additional functionality.

Yesterday our attorney wrote us "we can't use sync because of this patents

note" as it works like a virus, and can't use our modification too for the same

reason. It turned out the stdlib is under the same note too, so we will have

fun times :) 

That makes no sense to me.  And I'm not aware of any other company that sees any problem at all with the patent grant.

But I am not a lawyer, and you will have to make your own decisions.

Ian

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1db53b86-32fd-4a43-9bf4-d39fde9ed96dn%40googlegroups.com.

[Dan Kortschak]

On Thu, 2020-10-29 at 22:54 -0700, Ian Lance Taylor wrote:
> On Thu, Oct 29, 2020, 10:48 PM Denis Cheremisov <
> denis.ch...@gmail.com> wrote:
> > Well, as usual I wrote something in the way, not the real thing.
> >
> > The case is:
> >
> > - At my company we are using errgroup from that sync repo in one
> > project,
> > sync/errgroup in fact mostly.
> > - It proved to be error prone with its context shadowing on
> > errgroup.WithContext
> > so we took the original and adds context in the group itself via
> > eg.Ctx() +
> > a couple of additional functionality.
> >
> > Yesterday our attorney wrote us "we can't use sync because of this
> > patents
> > note" as it works like a virus, and can't use our modification too
> > for the same
> > reason. It turned out the stdlib is under the same note too, so we
> > will have
> > fun times :)
>
>
> That makes no sense to me. And I'm not aware of any other company
> that sees any problem at all with the patent grant.
>
> But I am not a lawyer, and you will have to make your own decisions.
>
> Ian

Maybe they are worried about this, "This grant does not include claims
that would be infringed only as a consequence of further modification
of this implementation." (that's what it sounds like from the previous
response).

If they are, I think they are misreading it (though I am not a lawyer).

[Space A.]

Are you creating your own programming language and tools and going to release it under own license terms? If not, and you're using this lib only to program your projects, there are no restrictions.

четверг, 29 октября 2020 г. в 16:52:17 UTC+3, Denis Cheremisov: