Your Ubuntu-based container image is probably a copyright violation
mjg59.dreamwidth.org
mjg59.dreamwidth.org
No, it's not. The relevant language (which this post cites) from the Canonical IP policy deals with trademarks, not copyrights:
Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries.
Canonical is trying to prevent third parties from passing off forks as genuine versions of Ubuntu. (Not that I agree with its approach, but that's what this language does.) Distributing a Docker image to your own web server doesn't "associate it with the Trademarks."
(edit: formatting)
> (...) Whether either case stands any chance in court is not clear at all, though, but that's the point: There's a non-zero chance of success for Canonical. Thus, unless you have a large legal department and a budget to match, it's now just no longer a sane business decision to have this doubt looming over your product. You'll want to stay clear of this risk. (...) I believe Debian should take action.
[1] http://mjg59.dreamwidth.org/36312.html?thread=1419480#cmt141...
So, as usual, GPL software, with its strong user protections, is more practical for "business" use.
GPL also introduces the other fun elements, chief among them being the "viral" nature, and I'm sure we opinionated HN folks could debate for weeks on whether the GPL as a whole is "more practical for business use".
I've never understood the appeal of Ubuntu on the server, and stuff like this just reinforces that opinion.
Also, since I don't distribute any images, the IP issue does not effect me at all. So why exactly would this issue matter in regards to using Ubuntu on the server?
It's also the (ime) best supported server distro in terms of third party packages.
In addition the LTS versions work well with vagrant and spinning up a dev box from a bash script is trivial (it's a couple of hundred lines of bash script most of which is reusable across projects).
If we where a massive shop I'd probably look at CentOS but so far I've not had the need.
But with how rapidly PHP/Ruby/Python/Java/etc advance, I prefer an OS that mostly keeps up with their latest versions. And Ubuntu's PPA system makes that a lot easier if you can find a PPA you trust.
When I first started, my predecessor had been fighting with upgrading PHP so that we could run Drupal on CentOS... 'Course he was still on hardware blades, not VM's. So he couldn't easily switch OS's. I got to move everything to VM's, and that's when I switch everything over to Ubuntu. After figuring out that CentOS wasn't the direction I wanted to go.
If you're hosting your own web apps on commodity servers, more into VMs and containers, or you are more concerned with tracking current versions of languages, kernels, and other software than you are with long-term stability, then Ubuntu can work well.
The 2 year LTS release cycle combined with 5 year support means you can either stay in step lock with LTS or skip every other version and still have a year to upgrade, I retired my last 10.04 earlier this year, that thing ran in production for five years with less than 10 hours downtime :).
Personally I prefer Debian because the extras Ubuntu ships usually get disabled / deinstalled on production servers, so it makes more sense to work from a minimal base to begin with.
I do remember that I had planned on fully switching to Debian (it seemed odd to me to use a distro based on Debian instead of just Debian), but ran into enough issues that it was better to just stick with Ubuntu.
Reevaluating Debian is on my todo list for when I have time. It's been long enough that the issues I ran into before will hopefully be gone. Or maybe I'll have changed how I do things in a way that avoids those issue.
Ubuntu encourages derivation, but there has to be balance in protecting users and the reputation of the Ubuntu project. One of the objectives for Ubuntu has always been to enable people to build on it - that's why it's always encouraged and supported derivatives. But, but there are effects are what causes this part of the policy:
* Someone providing a version of "Ubuntu" for specific hardware, but which broke various bits of user-experience * Someone customising Ubuntu for a specific server load but replacing PHP with their own version that wasn't in the package system - consequently no more security updates to this component.
This area of the policy solely covers publicly distributing:
* If you're distributing Ubuntu without any alterations then there aren't any issues: for example people create CD's in countries with low-bandwidth. * If you're using Ubuntu for internal use then you can do whatever you want: including changing configuration, altering components etc etc etc.
If you make alterations to the OS and present to the external world (distribute it publicly) as 'Ubuntu' then you need a bit of care. It's hard to write all the permutations, but in practise it's pretty easy. Just watch for things that fundamentally alter the OS as provided: changes to kernels, system packages, default installs or system configurations. In my experience adding things is unlikely to be problematic. If you're doing things like installing applications from the archives, or generally configuring things then there's unlikely to be an issue.
Dustin wrote a good post: http://blog.dustinkirkland.com/2015/07/appellation-of-origin...
You should read the policy directly and ask Canonical if you're still unsure.
It's like when you install a copy of Debian and look for Firefox, but instead see something called Iceweasel - I assume that still happens? The name is so passive aggressive.
EDITED s/use/enforce/ Thank you lightlyused
https://www.reddit.com/r/linux/comments/3de41m/fsf_statement...
They may also charge for it.
https://twitter.com/marcdeslaur/status/623262991216214016
(both of these people are Canonical employees; unclear if they are speaking officially.)