4 ms·

Sharing source code and binary-only packages are not mutually exclusive.

andrewstuart2 10y ago
Of course they're not. I just had hoped that this would be something that the Go team/community would purposefully decide not to support, as they've tended to lean toward open solutions and processes like most modern projects. 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. [1] https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md https://github.com/golang/proposal/blob/master/design/2775-b...
- pjmlp 10y ago
  Then Go would stay out from any vendor selling commercial desktop software or tooling for other developers. Those vendors will just keep using tools whose vendors are more understanding of businesses needs, like C and C++.
  - Matthias247 10y ago
    That's true. In my company we are basically living from licensing libraries and frameworks to commercial customers. Complete applications often make no sense in our domain (and SAAS even less). It's good to see that we could now also offer Go libraries to our customers (which means they could build Go applications) instead of being limited to the old C/C++ choices.
- BinaryIdiot 10y ago
  > 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 10y 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 10y 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 10y 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 10y 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.
- _ph_ 10y ago
  For the Go team it is beneficial if more people/companies are using Go and possibly contributing back. Trying to force someone into a specific usage pattern (here, open sourcing of all components) can be detrimental to it. Even if parts of your product might be open sourced, there often are good reasons for commercial software providers (either by selling software or the software being part of a sold product) not to open source their whole stack. Even GCC clearly states that programs compiled with it are not covered automatically by the GPL.

Of course they're not. I just had hoped that this would be something that the Go team/community would purposefully decide not to support, as they've tended to lean toward open solutions and processes like most modern projects. 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. [1] https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md https://github.com/golang/proposal/blob/master/design/2775-b...

pjmlp 10y ago
Then Go would stay out from any vendor selling commercial desktop software or tooling for other developers. Those vendors will just keep using tools whose vendors are more understanding of businesses needs, like C and C++.
- Matthias247 10y ago
  That's true. In my company we are basically living from licensing libraries and frameworks to commercial customers. Complete applications often make no sense in our domain (and SAAS even less). It's good to see that we could now also offer Go libraries to our customers (which means they could build Go applications) instead of being limited to the old C/C++ choices.
BinaryIdiot 10y ago
> 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 10y 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 10y 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 10y 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 10y 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.
_ph_ 10y ago
For the Go team it is beneficial if more people/companies are using Go and possibly contributing back. Trying to force someone into a specific usage pattern (here, open sourcing of all components) can be detrimental to it. Even if parts of your product might be open sourced, there often are good reasons for commercial software providers (either by selling software or the software being part of a sold product) not to open source their whole stack. Even GCC clearly states that programs compiled with it are not covered automatically by the GPL.