4 ms·

> The whole rationale given in the proposal [1] is that some users have worked with vendors who do not want to share their source code, since they've purchased

> The whole rationale given in the proposal [1] is that some users have worked with vendors who do not want to share their source code, since they've purchased some sort of library product. In my opinion, that's likely more harmful than beneficial for software as a whole. I'm not sure why that's "likely more harmful". If you're purchasing enterprise software or specialized hardware that comes with libraries that interact with them I can understand companies not wanting to simply hand over the source code to such things (this is how it's done with many existing products outside of the GO ecosystem). There is nothing wrong with giving people the option to deploy either way and it will help the GO ecosystem gain more enterprise like users.

geofft 11y ago
Alternatively, if companies know they can't use Go for libraries unless they're willing to make their source readable, and there's customer demand for Go, maybe they'll give in. A decade or three ago, it was common for all software not to come with source code. If you bought some server software, the client library was closed-source as a rule, if it even existed, regardless of how enterprise or non-enterprise it was. Now it's not uncommon to see even closed-source services have client libraries on GitHub because that's where they're expected and that's how people expect to publish client libraries. That change seems to have been good for the industry and good for the world. The enterprise users will come along eventually. They always have; you can find articles as recently as a decade ago debating whether your company should allow the use of open source software internally, or have a blanket rule against it. The second option is now inconceivable for almost all companies, because you put yourself at such a competitive disadvantage. All Go needs to do is deliver a technically attractive product, and people will figure out how to be comfortable using it.
- pjmlp 11y ago
  I am aware of a few companies that deliver source, alright. But they do so, by delivering it encrypted and decrypting it on the fly when it gets used. Or they hide it on a server that their customers never get to see, besides an incomprehensible junk of minified and encrypted JavaScript. Which companies are doing successful business selling software for embedded, desktop and mobile platforms with source code available?
  - comex 11y ago
    One notable example is Unreal Engine 4: https://en.wikipedia.org/wiki/Unreal_Engine#Unreal_Engine_4 https://en.wikipedia.org/wiki/Unreal_Engine#Unreal_Engine_4
    - pjmlp 11y ago
      Which is given with strings attached, depending on how people use it. Also the commercial games that are sold with it surely don't come with source code.
      - geofft 11y ago
        Strings attached is fine. This PR is about making it technically possible to not ship source with a library. If the policy is "Here's the source, but you can't do anything with it," you don't need this PR; you only need it for "You can't see the source at all." This PR is also not required for executables without source, which Go has supported forever, just for libraries without source.
  - geofft 11y ago
    I'm talking about things like client libraries for closed-source servers, since that's the context where you're most likely to have a library and care about what language it's implemented in. I'm not talking about the core product itself having source available. A number of software-as-a-service companies are making extremely successful businesses with completely proprietary servers and open libraries. Amazon AWS and Slack both come to mind without thinking very hard, but there are a lot of others. If you want to reject software-as-a-service, there are a good number of companies selling proprietary (or at most "open core") desktop/server applications with open-source client libraries. VMware, a bunch of NoSQL companies, a couple of network monitoring tools, etc. also come to mind. Those sorts of companies would have given you a closed-source C library 10-30 years ago. And, of course, there are people who sell hardware (graphics cards, network cards, RAIDs, etc.) who would have released proprietary tools and drivers in the past and are now releasing both as open-source because that's a competitive advantage because their stuff works better.
- jjuel 11y ago
  Would it do what you are saying or would it hinder growth? I mean would a company say well we don't want to ship source code with it so let's choose another language that doesn't force us to do that. I am not saying either way is correct, but I can see a company that was thinking about going with Go use another language because they have to ship source with their binary in Go. Which would actually hinder the growth of the language.

geofft 11y ago

Alternatively, if companies know they can't use Go for libraries unless they're willing to make their source readable, and there's customer demand for Go, maybe they'll give in. A decade or three ago, it was common for all software not to come with source code. If you bought some server software, the client library was closed-source as a rule, if it even existed, regardless of how enterprise or non-enterprise it was. Now it's not uncommon to see even closed-source services have client libraries on GitHub because that's where they're expected and that's how people expect to publish client libraries. That change seems to have been good for the industry and good for the world. The enterprise users will come along eventually. They always have; you can find articles as recently as a decade ago debating whether your company should allow the use of open source software internally, or have a blanket rule against it. The second option is now inconceivable for almost all companies, because you put yourself at such a competitive disadvantage. All Go needs to do is deliver a technically attractive product, and people will figure out how to be comfortable using it.

pjmlp 11y ago
I am aware of a few companies that deliver source, alright. But they do so, by delivering it encrypted and decrypting it on the fly when it gets used. Or they hide it on a server that their customers never get to see, besides an incomprehensible junk of minified and encrypted JavaScript. Which companies are doing successful business selling software for embedded, desktop and mobile platforms with source code available?
- comex 11y ago
  One notable example is Unreal Engine 4: https://en.wikipedia.org/wiki/Unreal_Engine#Unreal_Engine_4 https://en.wikipedia.org/wiki/Unreal_Engine#Unreal_Engine_4
  - pjmlp 11y ago
    Which is given with strings attached, depending on how people use it. Also the commercial games that are sold with it surely don't come with source code.
    - geofft 11y ago
      Strings attached is fine. This PR is about making it technically possible to not ship source with a library. If the policy is "Here's the source, but you can't do anything with it," you don't need this PR; you only need it for "You can't see the source at all." This PR is also not required for executables without source, which Go has supported forever, just for libraries without source.
- geofft 11y ago
  I'm talking about things like client libraries for closed-source servers, since that's the context where you're most likely to have a library and care about what language it's implemented in. I'm not talking about the core product itself having source available. A number of software-as-a-service companies are making extremely successful businesses with completely proprietary servers and open libraries. Amazon AWS and Slack both come to mind without thinking very hard, but there are a lot of others. If you want to reject software-as-a-service, there are a good number of companies selling proprietary (or at most "open core") desktop/server applications with open-source client libraries. VMware, a bunch of NoSQL companies, a couple of network monitoring tools, etc. also come to mind. Those sorts of companies would have given you a closed-source C library 10-30 years ago. And, of course, there are people who sell hardware (graphics cards, network cards, RAIDs, etc.) who would have released proprietary tools and drivers in the past and are now releasing both as open-source because that's a competitive advantage because their stuff works better.
jjuel 11y ago
Would it do what you are saying or would it hinder growth? I mean would a company say well we don't want to ship source code with it so let's choose another language that doesn't force us to do that. I am not saying either way is correct, but I can see a company that was thinking about going with Go use another language because they have to ship source with their binary in Go. Which would actually hinder the growth of the language.