1. 62
  1.  

  2. 10

    I can’t believe a company like SalesForce doesn’t eye licenses like a hawk. That’s really weird, and poor form.

    1. 19

      It doesn’t surprise me at all. The only places I have worked that cared about licences of dependencies were banks. Everywhere else, using a library has been entirely at the programmers discretion and the programmer usually does not care.

      This is how OpenWRT was born.

      1. 3

        Maybe it’s a “software industry” thing? All three telecommnications businesses I’ve worked for have been very stringent about licensing and choosing the right licenses for our code and imported libraries etc.

        1. 7

          I think that mindset of:

          It is available on the internet, so it must be free to use

          Is quite popular outside of the software industry as well. Unfortunately people are quite hard to educate about intellectual property.

          1. 2

            More of a company size thing. At HP unusual license approvals had to come from the legal dept. And that’s for a project which has MIT, Apache2 and a few others pre-approved. I’m sure there were other projects which needed confirmation of everything.

          2. 1

            Google cares very much about licenses.

          3. 10

            I once told a room of OSS policy wonks that my Big Tech Co had no one in charge of licensing or knowing what we use or checking for compliance. They were flabbergasted as though this were not the norm. I have worked at many sizes of company, was always the norm. You want a dependency you add it to Gemfile or whatever and push, the end.

            1. 3

              In my experience unless an engineer makes the company lawyers aware of the risk here they won’t even know to think about it. I make a point of raising it everywhere I work and institute some amount of review on my teams for licensing. But it’s not even on the radar of most company lawyers.

              1. 1

                I worked at a company that had a policy, but there was no formal enforcement mechanism. Devs were supposed to check, but this didn’t happen consistently. As a practical matter, though, it really wasn’t a problem. Just before I left the lawyers started asking questions and I actually built the initial version of an enforcement system. As it turned out, basically all of our dependencies were Apache, BSD, or MIT licensed (IIRC).

              2. 2

                Keep in mind licensing isn’t the only part though.

                However, adding monkey patching to Go is not a reasonable goal while respecting anything close to “best practices.”

                I think if you start out with something non-reasonable, such as working against the very programming language you use, why would you get into thinking about its license?

                If a company like Linksys didn’t care about licensing why would a company like SalesForce?

              3. 8

                This looks misreported.

                The commit introducing monkey into dapr is 27dd856d7ca865a44c35ffe3e592c83182de093d (18 days ago.)

                The commit removing it is 38e66fddeecb73feb53e6fde1cdf277854c831f0 (11 days ago.)

                I don’t think the story here is that “people aren’t reading licenses.” Lasting one week suggests it got noticed pretty quickly, and it’s not clear that big companies picked up the code from that week. The story here is that somebody did a commit into a popular package that was either malicious or moronic - the story is that it’s still possible to “sneak commit” into popular open source packages.

                1. 7

                  The thing that gets me is that not only did they not read the license (fairly expected), they apparently didn’t even read the README! Or at least, they didn’t heed the dire warnings it’s filled with.

                  1. 2

                    Tons of big name Go projects have dependencies on Iris, which is essentially a scam.

                    1. 1

                      Monkey is popular because it fills a real need. […] The feature is useful for tests where, say, a repo that talks to a database is swapped out for a component returning test data. The lack of this feature in Go is a testament to the language’s resistance to adding the trendy latest features that have bloated languages like Python and C#.

                      Not only is monkey patching (a.k.a. guerrilla patching) highly discouraged in Python, but the term was invented in the Python community to disparage the practice. And I’m pretty sure C# devs aren’t fond of the practice too. OTOH, Ruby devs seem to love it, mainly due to its prevalence in Rails.

                      The author should be careful where he takes potshots.

                      1. 3

                        Ruby inherited it from Smalltalk, which is one of the few pure imperative languages in existence. You create a class in Smalltalk by sending it a message that creates a new subclass and then sending it messages to replace method implementations with blocks that you provide. The ability to do monkey patching is inherent to such a language, because there’s no declarative definition of a class to override, classes are just data structures that you can modify and the canonical way of creating a new one is identical to the ‘monkey patching’ method.

                        This has been part of Smalltalk since Smalltalk-71, from 1971. Calling it a ‘trendy latest feature’ is displaying a huge amount of ignorance (unless the author has been in a coma for the last 50 years).