Hi Ian, Good question. I don't have an answer.
But this raises some questions: Should Go be anticipating many such possibilities today and tomorrow? Or shut them off? With this limitation, doesn't it look like Go is best suited for building end products or service but one cannot build on top of some other's work (with direct API access) without having access to source code? Are we indirectly making Go well suited for (a) building end products or service (as mentioned above) or (b) specific areas (typically research, education, non-commercial) where we can create building blocks inside/outside the company and the code will be shared as well. One problem I see is we have a better chance of knowing who adopted Go for what but not quite on who could not adopt for what reason. Regards dharani On Thu, Oct 18, 2018 at 4:28 PM Ian Lance Taylor <i...@golang.org> wrote: > On Thu, Oct 18, 2018 at 4:02 PM, Tharaneedharan Vilwanathan > <vdhar...@gmail.com> wrote: > > > > This means source-code is the only way to share the work. When it > companies > > to sharing/selling their work on top of which others can build their > > app/solution, this won't work. Doesn't this seem like a big restriction? > > Particularly, computer industry being heavily dependent on IP rights (and > > where trust is low)? Wouldn't this deter such companies from adopting Go? > > For contrast, I have heard of providing binary only distribution even > within > > the same company. > > The question is: is anybody actually doing this? Is anybody seriously > thinking about it? > > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
