[1] https://www.joyent.com/blog/samsung-acquires-joyent-a-ctos-p...
Please, please continue to develop your public cloud offerings. Having options other that the myopic, me-too, feature-matching, monoculture that is AWS/GCE/Azure is incredibly important.
That said, for my use profile, you guys need to work on your price competitiveness. Hopefully Samsung will inject the necessary cash for economies-of-scale.
I'm sure they will. They are a top contributor to open source:
Which means the larger companies* are probably on schedule for development to start slowing because of technical debt. And therefore solving that (modern development practices and open source involvement!) will become a competive advantage.
* Sadly, the smaller companies will probably always be hacked-together-MVP stacks on top of whatever release they started dev on
It's starting to feel like I need to consult a lawyer before I could ever publish an open source project, and that's never going to happen. I'd rather just stop publishing.
The amendment is actually the first paragraph of the COPYING file. If you modify any of the terms of the license directy, you have to remove the preamble and refer to it as something other than the GPL.
The other option for modifying the GPL is to distribute a separate LICENSE file alongside it stating something like "this software is released under the GPL, except for <specific changes>". When this happens, there's almost always an FAQ somewhere on the internet describing what the changes are intended to mean.
So, basically - check the source files to see if they mention a license, then check if there's a file named LICENSE, then check if there's a file named COPYING. One of these should always point you to the right license.
Additionally, as a point, it's not actually a modification of the license, merely a clarification - see section 9 of the GPLv2, which states that the program must explicitly state that it is usable under later versions of the GPL to be usable under later versions of the GPL. The boilerplate text that GNU give you to put at the top of each source code file does that by default, but, it's not required.
That is a good, honest question, but there is a different standard of expectations for some random programmer doing a project and one of the biggest, most powerful multinational corporations on the planet with business operations (and legal advisors) in most of the world's countries.
If Samsung has the legal muscle to go up against Apple and others in the courtrooms of the world, and the technical muscle to customize multiple operating systems for countless products, they have the resources to read and understand the Linux license. While inept bungling is always a possible explanation for any party, a more likely explanation for a license violation for something as fundamental as an operating system by any party with that level of resources (if one were to ever occur) would be that they examined the issue, understood the situation, and decided that they could probably get away with it.
* ... apparently Linux has a modified version of the GPLv2? I would never notice that,*
From the point of view of a personal project it doesn't matter that much. If you accidentally breach a license and someone notices they'll tell you and you'll fix the issue.
It gets much hairier once money is involved (i.e. OS code used by a company like Samsung) but the process they need to go through is no different from the due diligence that they have to do when licensing non-OS code from other bodies (commercial or otherwise).
When transitioning from pet project to commercial interest things are a bit more muddy. In the case of an individual or small company making the transition there may be some pain as they are not initially setup for this, but in the case of a commercial interest taking over (buying the project, taking over the smaller company, employing the individual specifically to work on the project, just negotiating non-OS use of the code etc.) this is again covered by the same due diligence requirements they follow when dealing with commercial code.
> I'd rather just stop publishing.
This only affects making modifications to other projects or taking some of their code to supplement your's (in both cases you are creating a derivative work), and even then only if you subsequently publish the work (i.e. it isn't purely a personal or in-house project). It shouldn't stop you publishing work that is definitely your own, just chose a license that you do understand.
If in doubt, write it yourself. For bringing in libraries (as "write it yourself" is seldom completely practical for all but the smallest projects) keep to the "soft" licenses that you understand (in no particular order this for me is: BSD, MIT, CC, LGPL, ASL) and avoid the "hard" OS licenses (GPL proper) & non-OS licenses unless you intend to stay GPL or accept the limitations of commercial/other licensing, and ignore code under other licenses unless you have time to read and understand them. Also avoid code with no clear license.
So, if you "know must mainstream licenses", you should be aware of this.
Source: I applied for the job. I didn't get it ;-)
I can't say I know either way, however I do recall their Tizen SDK licensing not being accepted as open source due to it only granting the right to use certain components on 'Tizen Certified Platforms'.
"In February 2014, Joyent announced a partnership with Canonical to offer virtual Ubuntu machines."
Wiki: "In journalism, lede is an alternative spelling for lead paragraph."
We use Joyent for nodejs microservices, chiefly any server side DOM manipulations (using jsdom), and it's been solid! Currently evaluating docker container management and will give Triton a go...
Just saying, there's a bit of bias that's probably worth recognizing.