Most commercial work these days leverage several open source libraries. And once a library becomes part of your core product, it is in your interest to support further development of that library by contributing code, time, money, etc.
Unlike other OSS licenses like BSD, Apache, LGPL, etc, GPL makes it impossible to utilize the library in any way in a commercial product. My current company works on some video related stuff, and we use OpenCV, ffmpeg etc but we completely steered clear of libVLC due to the GPL licensing (even though we think it's a fantastic piece of software). We will however be revisiting this now due to this excellent work by jbk.
"GPL makes it impossible to utilize the library in any way in a commercial product"
That's not strictly true. You could license your commercial product as GPL, or (more likely) contact the library's authors and negotiate usage of the code under another license.
I'ts not just "not strictly true," it's not true at all. Nothing in the GPL prohibits GPL'd code from being used in commercial products. What is prohibited is using it in proprietary, closed-source products. You can have a product which is both F/OSS and commercial. Ask Red Hat, for example.
You are right, of course. "commercial" was the wrong terminology; I meant proprietary, closed-source products as you said.
However, whatever your views on closed source products, they are still quite prevalent. IMO LGPL is a great license to get support from companies that sell these products, while ensuring that your software fundamentally remains free.
With JavaScript and the GPL it is very unclear what "linking" is. Probably your entire website becomes GPL including content. Who knows as the language was written for system libraries. So I can see lawyers having an issue.
If you are not intending to modify Mongo then AGPL is not restrictive, which may be OK. The database API is not usually considered as "linking" as it is a wire protocol.
As the OP has demonstrated, "Contact the library's authors and negotiate usage of the code under another license" is EXTREMELY difficult for a project maintainer and would thus be near impossible for anyone else.
It is much better if the price and terms are simply public up front. For instance, we were worrying about PyQt (GPL + commercial option) vs. PySide (LGPL) for a project, where PySide didn't support certain things that we needed. But then we realized that the PyQt commercial license comes with reasonable terms, and costs only £350, and it wasn't even worth the time worrying over it any more.
So yeah, "contact the authors" can be hard, but an up-front agreement and price can make it pretty easy.
This is how the x264 developers do it IIRC, they offer x264 under GPL and if you want to use it in a proprietary manner you need to buy a licence from them in order to do so.
Will do, thank you for the offer jbk. Again, great work. I can't begin to imagine how painful it must've been to get everything relicensed! Sometimes it's such "non-technical" work that ensures the continued success of a product.
It looks like you're trying to do the right thing here, even though there is no boss or peer who understands exactly what you're doing and can appreciate that fact. Kudos for that :)
To echo tinco's comment, do not try to explain the intricacies of what you're doing to your customers. Put yourself in their shoes and think about what is important to them. Explain just the "end results" of your tooling, emphasizing the points that are important to them and leaving out everything else.
For example, you could say that the caching rework will improve the performance of the system, software-defined infrastructure will ensure minimal downtime in case there's a hardware failure, etc. These are all benefits your customers will understand, even though they may not care or understand how exactly you will achieve them.
It is incredibly important to get your tools right so you can operate as efficiently as possible. At my company we didn't get around to this till much later, partly due to the dilemma you mentioned abt focusing on customer-facing software vs. internal tools, and partly due to the fact that the people who would benefit the most from automation (e.g. finance folks, inventory managers, etc) don't have the same obsession with automating away mundane tasks like us engineers do.
This lack of tools hurt us quite a bit once we started scaling, in ways that impacted some customer relationships (because occasionally we didn't invoice or ship correctly, etc). We have since invested significantly in tools, but we should've done this to begin with.
To make the customer vs. internal tools compromise easier, you may even want to get some basic tools in place via contract work/offshoring and then revisit these later once you have the time/resources. The hard part really is determining what to automate, and how much, and those are decisions that you should make. The development itself can be done by someone else.
Great comment. We're in the enterprise space and we also see many competitors do the tech blog rounds and then fall off the face of the earth after a few months.
To add to your morale point, I look at tech blog coverage as great for recruiting engineers, as that's where engineers tend to hang out to find the next "hot" company (vs. websites specific to your vertical, where your customers hang out).
Not a big fan of the article either, but I think there is some benefit to at least trying to develop some skills outside of your core skill set. This is not necessarily to get good at those skills, but to develop empathy for others who've decided to specialize in those skills.
For example, I've personally realized that management is not really my thing, but having done it for a while I understand better now where my ex-managers were coming from and feel that I'm now a better employee because of that. Same for design work, etc.
And frankly I wish other people did that too. Wouldn't it be great if your manager understood your explanation of why that "tiny" feature will actually take weeks, or the designer keeps potential code complexity in mind when designing something? I think this advice applies to everyone, not just programmers.
Yeah for the closest possible comparison in your scenario, you want to do a 3 year reserved with heavy utilization.
When you reserve an instance, you are committing to a higher upfront in order to get a lower hourly for the reservation period. The low/medium/high utilization is sort of a knob that allows you to further control this upfront vs. hourly cost. With high utilization you have the highest upfront, but also the lowest hourly cost. If you are planning to run the server 24x7, this will also give you the lowest total cost.
Exactly. This was an attack on the new "Uber X" service which will more directly compete with regular cabs. (Frankly the only reason I even take cabs anymore is the cost of the regular Uber service.)
Also, "Why is it free?" is another way of asking "What's the catch?". It's important to understand this before you put in a bunch of work...