If it's not practical to redistribute, it's not free software in practice
lwn.net
lwn.net
Canonical's relationship with the rest of the FOSS community always seemed a bit screwed up to me. They try to make Ubuntu the best Linux distro while ignoring what all the other ones are doing. All other distros seem much more friendly towards integration between projects, to benefit from the shared work, while Ubuntu most of the time paves its own way - there's a lot of Ubuntu only software, such as Unity, Mir, etc. that you just dont see in other distros.
Other distros could try to port Ubuntu projects, but why would Canonical accept their patches upstream?
Though I dislike Unity and Mir, I think RedHats understanding of "Open" Source is a lot more disturbing.. https://lwn.net/Articles/432012
Not that I disagree with your comments on Red Hat, but let's get our facts right.
The person you responded to is correct though; a large factor in starting systemd was the CLA of Upstart. Above even highlights this; you cannot really say that RHEL6 used upstart in any way.
Cf. the effort necessary to get Unity running on Arch: https://github.com/chenxiaolong/Unity-for-Arch
You have to rip out and replace a lot of software, all the way down to GTK itself, just to make it work.
Unity, on the other hand, is a bloody desktop environment. You can install dozens of those (or could, if there were that many) in parallel without any modifications… with the sole exception of Unity.
But then again, you don't think that there are dozens of desktop environments. Arch supports nearly two dozen by itself (https://wiki.archlinux.org/index.php/Desktop_environment), and that list doesn't include things like fvwm, or tiling desktops like xmonad or i3.
Edit: To clarify, the point being made is "if you have to modify a bunch of stuff, then the software is not free". Systemd requires a lot of modifications - it's not a 'drop in' replacement. Using the same argument, systemd is 'not free'. It doesn't matter how 'invasive' the component is, the argument is about modification effort.
I think the argument is wrong - Canonical patches a lot of things for Unity, but those patches are publicly available and are not done to obfuscate the code. Basically the argument here is that no-one should be allowed to publish free software if it can't be simply dropped into $RANDOM_YAHOO's system.
From my own experience, migrating machines from sysvinit to systemd is trivial. Systemd does not need all those optional bits and is happy to work with syslog, ntpd, cron, etc. pp., can pass through sysvinit init files, and so on. If you actually use it instead of relying on fudy reports, it's a breeze to work with.
Recompiling half my desktop, and then recompiling all userspace programs using any of the involved libraries, is much more invasive compared to that.
Another approach is looking at what you have to do when building a system from scratch: Here, systemd's "modification needs" are obviously close to zero (because the system is built around it, you can use journald/timesyncd/etc. from start, or set up rsyslog/ntpd interoperability for systemd). Userland software might, at most, need unit files to use them. Desktop environments et. al. work without dedicated logind support or anything. Unity, however, still requires me to scrape together patches out of Canonical forks of various programs and libraries to get it to work. It's still massively invasive and requires far, far too much effort.
As a result, rather than working towards a united goal of empowering users with the power of FOSS tools, we started having these ego battles of "mine vs your distro", "gnome vs unity", "systemd vs upstart", etc.
Its true that Linux has choice and FOSS is all about having choice. But that has gained quite a negative reputation now. Earlier, choice meant: "If you need more features, use X package instead of Y".
Now it means: "Since I have got choice, I'll keep switching my distro every couple years, and since I'm a unity fanatic, why should I keep it compatible with other distros? Everyone should use unity and ubuntu."
Unity and Mir are no doubt open-source, but if you build a automobile engine that fits ONLY to your car and call that engine open-source, what use is it!
Ubuntu is still heavily based on Debian and still reuses most of the packages. There has been a gradual move towards systemd and systemd is default in Ubuntu 15.10.
To me, mjg59 comes out as a bitter person. He used to work for Canonical in the early days of Ubuntu. He shared the vision for a usable open-source desktop.
Then came the new GNOME 3 and the particular way that GNOME development works. It was not workable to offer to the users a stable and distinct user experience. So, Unity was created and all hell broke loose.
Now, when Mark farts, they scream "Terrorist gas attack!". A couple of days ago there was some open-source appreciation day by the Ubuntu community and it looks very suspicious that mjg95 coincided his rant with this. I think the previous rant was also coinciding with some similar positive Ubuntu announcement.
It looks even more difficult to get an open-source desktop. mjg59's attitude is like "if it is not ours, let's f* their efforts anyway".
With Ubuntu and any other software, you get the source and it is up to you to deal with the replacement of any trademark strings. What packages are included in Ubuntu, changes all the time and the code changes as well. How can a policy document be explicit when there is no infrastructure yet in place to deal with those code changes? CentOS was in this same position and they did the work without bitching to Redhat.
> With Ubuntu and any other software, you get the source and it is up to you to deal with the replacement of any trademark strings.
(Emphasis mine)
That's not true of any other software!
I'm not sure how things are for RHEL, but I imagine they're basically similar to Fedora. Fedora doesn't fuzzily require you to "remove and replace all trademarks". It explicitly requires you to remove the branding -- i.e. repository information, change logs and logos. They even provide a nice list of what you have to remove. Everything that you must replace is in three packages.
Now, I'd normally just suspect mjg59 of bitterness, were it not for Canonical's PR dance around the issue.
The accusation is clear: mjg59 thinks that Canonical is intentionally keeping the wording vague so that they can have a word to say in who is developing products based on Ubuntu. Anyone who wants to use something based on Ubuntu has to ask for approval. Otherwise you might end up in court because you didn't remove "Removed spurious call to foo_frobnicate() to fix crashes on Xubuntu" from an upstream changelog.
Canonical has been handing out these approvals for free so far, but I don't think any requests came from current or future competitors. There's no reason to believe that Canonical would be as eager to approve a direct Ubuntu Phone competitor.
Yes yes, it's in their interest to not be as eager, but if this was such a big problem, they should have thought twice before basing their business around a bunch of GPLd products.
It's hard to suspect Canonical of good intentions when every single answer they handed out managed to answer another question. The dialog so far has basically been:
Q: Oh hi guys, look... I'd like to make an Ubuntu derivative, can you tell me what I have to remove?
A: All trademarks.
Q: What do you mean by all trademarks?
A: Or you can ask us for approval instead.
Q: I get it, but I'd rather just remove all trademarks... what exactly do you mean by that? Do I have to remove e.g. mentions of Ubuntu from an upstream changelog, or the @ubuntu.com e-mail address of a contributor listed in an about dialog or a CONTRIBUTORS file?
A: Look, we get this is important, but we have to make sure Evil Hackers don't impersonate Ubuntu so we have to ask you to either remove all trademarks, or ask us for approval.
Q: But I'm not an evil hacker!
A: Then we'll approve your request.
Q: BUT I DON'T WANT TO ASK YOU, I JUST WANT TO KNOW WHAT TO REMOVE!
A: Look, we get this is important, but we have to make sure Evil Hackers don't impersonate Ubuntu so we have to ask you to either remove all trademarks, or ask us for approval.
It kind of gets in an infinite loop at this point.
Canonical could clarify the wording without opening themselves up to Evil Hackers. Their unwillingness to do so is (somewhat insultingly) veiled in arguments that are about as childish as they're trying to imply mjg59's are. It's hard to suspect them of good intentions under these conditions.
Not at all. RMS isn't philosophically pro-trademark, but he has said that trademark and free software are separate issues (meaning that 'free software' doesn't confer on the user the ability to rip off a trademark).
> but now if anyone wants to do binary redistribution of their product
You CAN redistribute Ubuntu, but only in its whole form. You just can't rip out/add pieces to it and still call it Ubuntu, because then it infringes trademark. If you want to change it, you can, but then it can't be "Ubuntu".
> He criticized Ubuntu for unwillingness to clarify the trademark issue.
Which is stupid, because trademark is a legal term, defined by the laws of the land. Canonical can't change the way a country interprets 'trademark'.
No, he just wanted them to clarify, what specifically are the things which should be removed from Ubuntu distribution, so it can be then declared as completely stripped from Ubuntu trademark. (other Linux distributions mentioning in the article do provide such information).
I decided to take Ubuntu 15.04 out for a ride a few months ago. I haven't really used Ubuntu since 7.something (but I liked 4.10 a lot), but I did occasionally work with it (e.g. helping out colleagues who used it).
I desperately tried to like Unity, but nope: its development seems to be done pretty much the same way that Gnome development is done. A lot of effort goes into creating a distinct experience. Very little seems to go towards listening to users, and options are basically non-existant.
Changing the GTK theme, for instance, is no longer easy (you need unity-tweak-tool). Changing the buttons on the titlebar is outright impossible because now they're hardcoded.
This is... very much against the spirit of people who were involved in the open source movement a while ago. A lot of us switched to Linux because we wanted more control over our systems.
Free software that locks down your options is... missing the point a little.
I have no clue who you mean with "they scream". You mean GNOME contributors? Then again on history: Canonical committed to developing Wayland. Then changed direction, didn't communicate and came out with Mir 6 months later. This included all kinds of incorrect statements plus left out that they committed to develop some things for Wayland. The backlash has been documented many times, was pretty logical, was not limited to GNOME and mostly: it could've been avoided!
I quite appreciate Canonical, but there's a fair bit of "wtf" that went on over the years.
You seem to like speaking on GNOME's behalf; you're so terribly incorrect that I ask you to stop it. Further, mjg59 doesn't do much at GNOME. In his own words: https://mail.gnome.org/archives/membership-committee/2014-Ma....
Now on Unity: to package Unity for many years you had to apply lots of big patches to various other components. Unity was pretty much a Ubuntu-only thing and not meant to be shared easily across distributions (I asked).
I posted it the day after I got a reply from Canonical telling me that they wouldn't be answering my questions about the rights of downstream recipients.
> mjg59's attitude is like "if it is not ours, let's f* their efforts anyway".
I'm willing to do the technical work required to split the trademarks into separate packages as long as Canonical are willing to accept that.
SuSE before it went enterprise, Mandrake before it lost support were the only real alternatives to Ubuntu in terms of consumer desktop experience.
Nowadays I only care it works as it is supposed to be, as I don't have the patience any longer to fiddle with configurations, and even Ubuntu has its own quirks that lead to weekend projects.
EDIT: Extra words due to copy-paste.
I seriously can't see any other Distro going out of its way to be easily distributed OS with the https://susestudio.com/ and https://build.opensuse.org for packages for SUSE, Ubuntu, Fedora, etc...
How is the overall OpenSuSE experience nowadays?
Since I spend most of my time on Windows anyway, I ended up settling with Ubuntu for my netbook and VMs.
The ability to install packages with https://build.opensuse.org is such a better system than ppa.
For the last three years I use i3 (Tiled Window Manager) and works great on in VM at my Windows machines. Still sad to see so many people left due to the Microsoft deal and haven't come back to give it a try again.
EDIT: If you use a command line package manager zypper is best in class. Fedora actually incorporated zypper features and code into its yum replacement.
Fedora(Redhat) has picked out two of OpenSUSE's best features, zypper and obs (https://opensuse.org). OBS (Open Build Service) was considered instead of re-inventing the wheel that is copr https://lists.fedoraproject.org/pipermail/devel/2013-Septemb...
IMO, the best that Canonical can _realistically_ do is to provide a list of trademarks and to not obfuscate trademarks. No funny escaping just to evade grep. Doing more would be nice, but anyone who forks has to search-and-replace anyway.
The FOSS obsession with "community" and "integration" is myopic and abhorrent. As if everyone must converge on one approach, one vanguard. There are scantly any problem domains where only one solution applies.
Now, Canonical keeping to themselves has a very crucial advantage: they leave everyone else alone. They stay in their corner, they don't bother, they don't intervene. They don't start a massive integration effort to drag everyone else in every time they devise something new.
We should be commending Canonical for this.
That is why I watch its progress with a certain degree of suspicion (disclaimer: I am a user of Apple and Canonical products.)
There is no obsession over "community" or "integration" as you stated. It is a valid concern that if others can not contribute freely, we are killing the essential of what made Ubuntu possible.
I certainly get why it would be in their interest to not have much collaboration. But if that's a problem for them, they should not have based their business around GPLd products. All these problems could very easily go away if Ubuntu were a FreeBSD distribution, not a Linux one.
This "stay in their corner, don't bother, don't intervene" does bother developers who increasingly have to code for Windows, OS X, Linux and, separately, Ubuntu. It's very unpleasant, and they're getting a lot of hate because users are suffering just because Canonical's business plan was shit.
Canonical depends on their community for everything from the very OS (Debian) to marketing to support.
Yet, they're crippling their community at the same time with their IP policy and their general refusal to integrate with software projects they depend on for survival.
This is, simply, unsustainable. Canonical cannot fork everything and do their own thing (not without quickly going bankrupt – unlike Apple, which has no problem with say, developing their own SMB stack if needed); and they cannot continue alienating potential (and current) users and upstream sources.
Why are you treating this as zero-sum?
It then becomes the problem of its users, and rapidly the problem of userland developers, because users expect their software to just work in Ubuntu.
Developers can now go and waste effort just to comply to Canonical's de facto walled garden, or lose all Ubuntu users (furthering the "Linux is too complicated and fragmented!" narrative).
Everybody loses, nobody wins.
Assuming source distribution, I do not see any special effort required.
This is a protectionist, anti-choice argument.
No special effort to support Mir/Unity/upstart? Other Ubuntu-only APIs, standards, UX, Kernel/Library versions not employed by other distributions, …?
(Upstart was killed when even Canonical realized it was impossible to demand of everyone else to support their special snowflake init system.)
It's also funny how people routinely bitch about Upstart when it predated systemd.
Would you be able to elaborate on this a little bit? It seems like a contradiction to me but it's more likely that I'm not understanding properly.
It is insulting from you to call the demand for inclusion and giving back as "myopic" and "abhorrent".
Like with social interaction, we don't need everybody to be the same, but we very much demand some core principles to be followed. Would you call that myopic and abhorrent?
Most complaints about Canonical's exclusivity underpin a utopian fantasy that everyone in the Linux community must converge towards one holy solution. Any deviation is considered "fragmentation" and brutally discouraged.
One way is that, by having a "one holy solution", you avoid fragmentation and get more stuff working on end-user's systems with minimal hassle. This is why, for example, Steam targets Ubuntu. They're the 800lb gorilla of the Linux world, and if someone is a desktop Linux user, odds are high they're using Ubuntu rather than anything else. They target the most users with the least hassle.
The end user doesn't want to mess with dependencies, compilation, desktop environments, and so forth. They want their shit to work. Fragmentation is an impediment to this from a usability standpoint, and that's before we even talk about security (e.g. Android).
The other way is that by these tightly integrated, non-interoperable stacks like Unity and Systemd make life miserable for every other Linux user in the world who values the ability that they can sample this init system, that window manager, etc, and build a system that fits their needs much more closely than any of the tightly integrated one-size-fits-all solutions.
This isn't a false dichotomy either - there are no companies out there nowadays that make good software that works really well for end users with minimal hassle, while allowing the degree of customization and interchangeability that power users demand.
So pick your poison, I guess.
Canonical comes up with a replacement for sysvinit called Upstart. Everyone agrees sysvinit is a dumpster fire on wheels careening around at high speed, so a new init system is welcomed as a Good Thing. Some people from Red Hat wanted to contribute improvements to Upstart, but Canonical insisted on a Contributor Licensing Agreement that would allow Canonical to relicense the work however they wanted, including commercially. Shockingly, Red Hat employees couldn't get clearance to do uncompensated labor for a Canonical project like that, so rather than contribute to Upstart, we got systemd.
Eventually, systemd became so [PICK ONE OF SUCCESSFUL OR BELIGERENT] that Debian adopted it. And at that point... game over for Upstart. Ubuntu uses systemd now. Because they don't have the resources to package everything for Upstart if Debian is moving to systemd.
The thing is, Canonical isn't that well resourced. Look at who contributes to the Linux kernel.[1] Looking at the top 10 sponsors of contributors, we see some of the usual suspects -- Intel, Red Hat, Linaro, Samsung, IBM, SuSE. We see "Vision Engraving Systems," weirdly. Going out of the top 10, a lot of hardware vendors, spits Oracle, FOSS Outreach Program for Women, Pengutronix... I mean, look at the homepage for Pengutronix. [2] It's some 90s era HTML 4.01 they've got going on there. But they're able to make significant contributions to the Linux kernel. Canonical isn't on the list. Canonical has NEVER been on the list, so far as I can tell. You can look all up and down the stack, there's a handful of Canonical-only projects they contribute to, but they're a rounding error in overall Linux development.
Which is their right, of course -- the GPL doesn't insist upon contributing back. And I would agree that shaming Canonical about community isn't productive. At the same time, Apple isn't what they are, it's what they want to be but are failing at being. Apple can get away with incorporating BSD code into their OS but still writing vast swaths of it themselves because Apple doesn't need any of the BSDs to adopt launchd to make it feasible for them to keep running it. Apple has money and can pay people to write code. And on the desktop, OS X has twice the market share of every Linux distro combined, so they can get developers to write applications for their OS even though it doesn't follow the lead of the rest of the BSD-derived OSes. (And yes, I know that OS X resembles a BSD distro far, far less than Ubuntu resembles Debian.) You're right that Canonical wants to be the Apple of the Linux world. But they're not succeeding at it and they're not GOING to succeed without some way of becoming profitable that has yet eluded them. And developers don't want the burden of having to support Canonicals quixiotic insistence that they are the Apple of the Linux world.
[1] http://www.linuxfoundation.org/publications/linux-foundation... (Also, why do I have to tell the Linux Foundation who I work for in order to read this report?)
Canonical comes up with a replacement for sysvinit called Upstart.
Actually a replacement for both sysvinit and sysv-rc, along with some overlap for hotplug and other demand-based/lazy operations.
Everyone agrees sysvinit is a dumpster fire on wheels careening around at high speed, so a new init system is welcomed as a Good Thing.
Hah. I wish.
In fact, the painful truth of the matter is few people really cared. There was lots of prior art (and indeed, Canonical themselves chose to write Upstart instead of adopting the emerging initng at the time for largely handwaving/wish-wash reasons [1]), but not a lot of interest in seriously tackling the problem domain beyond introducing a host of band-aids on top of sysv-rc like LSB dependency headers and startpar.
Some people from Red Hat wanted to contribute improvements to Upstart, but Canonical insisted on a Contributor Licensing Agreement that would allow Canonical to relicense the work however they wanted, including commercially. Shockingly, Red Hat employees couldn't get clearance to do uncompensated labor for a Canonical project like that, so rather than contribute to Upstart, we got systemd.
In fact, "some people from Red Hat" already had deeper architectural failings with Upstart (which I agree with, but absolutely not with how they decided to "solve" them) and its event model. The beginnings of systemd (prototyped under the name of Babykit) were lying around for several years on Lennart Poettering's machine.
And at that point... game over for Upstart. Ubuntu uses systemd now. Because they don't have the resources to package everything for Upstart if Debian is moving to systemd.
Which, ironically, is a form of cooperation. And look what cooperation gets you: homogenization towards a Red Hat solution.
The thing is, Canonical isn't that well resourced. Look at who contributes to the Linux kernel.
I'm well aware of the massive corporate contribution, and Canonical's low activity there.
But they're not succeeding at it and they're not GOING to succeed without some way of becoming profitable that has yet eluded them. And developers don't want the burden of having to support Canonicals quixiotic insistence that they are the Apple of the Linux world.
Again, Canonical are at a loss, true. This is their loss, not developers'. There is no "burden" placed on them unless they decide to ship their software in binary form only, in which case the problems already exist for any distro with its own packaging infrastructure.
> In fact, "some people from Red Hat" already had deeper architectural failings with Upstart (which I agree with, but absolutely not with how they decided to "solve" them) and its event model. The beginnings of systemd (prototyped under the name of Babykit) were lying around for several years on Lennart Poettering's machine.
Here's Kay Sievers, one of the originators of systemd[1]:
> True statement. And yeah, without the CLA, we would very likely have worked on upstart, instead of starting the systemd project. Four years ago we talked to lawyers and tried pretty hard to convince them to give it up, but there was no way to negotiate.
In the comments, from Scott James Remnant, who wrote Upstart for Canonical:
> I don't think we ever disagreed enough for me to refuse patches from them - it was very much a case of they had different ideas to me, and couldn't contribute them because of the CLA
> If the CLA wasn't there, we'd've just tugged and pulled and fought about patches like normal projects, and Upstart would have turned out much like systemd - I'd've been okay with that :)
And another comment from SJR:
> you'd be surprised how little of Upstart's code is the "event system". It could have quite easily evolved into what systemd looks like today, with an active community working on it.
> Indeed, systemd today doesn't look much like systemd back then either, it's evolved over time - the dependency system has taken a greater forefront than the socket system it was designed around, etc.
> systemd had the benefit of an active developer community, because it didn't put barriers up to contribution.
People who wrote for systemd and Upstart at the time both claim that if it weren't for the CLA, Upstart would've been contributed to by the people who eventually wrote systemd instead of systemd being its own project. I see no reason to disbelieve them.
Now, there's a case to be made that the public statements of intent did not necessarily correspond to the actual function, or strategy that made systemd emerge.
Quoting from Lennart Poettering's Linux Voice interview [1]:
> We, at that time, thought: OK, Upstart is the future! Scott understood how init systems work – it needs to be dynamic, it needs to react to events, and it’s not the static thing that Sysvinit was. So we thought that was the way of the future, but as it progressed, we realised it probably wasn’t the future, because we realised that conceptually, it was the wrong design.
Now, furthermore, the goal of systemd became "universal GNU/Linux middleware," a massively increased scope relative to what Upstart was intended to be. Though it may have been the case that Upstart could have evolved into something similar to systemd-the-PID1, it appears to me that systemd's emergence would nevertheless have been determined by the desire for a homogeneous catch-all userland suite. The Upstart architecture, relying on so-called "bridges" at the time to marshall external events to and from the internal format, would likely not have been as desirable.
LP's testimony starkly contrasts with Kay and SJR.
No it doesn't. There is no reason that "conceptually, it was the wrong design" has to contradict with "they had different ideas to me, and couldn't contribute them because of the CLA" and "it could have quite easily evolved into what systemd looks like today, with an active community working on it." It is quite easy to read those statements as being in agreement -- Lennart decided that Upstart wasn't conceptually correct, SJR is amenable to discussing merging changes that would bring Upstart in line with Lennart's ideas, but the CLA is a roadblock so Lennart goes off to form his own project. Why not adopt the principle of charity and take everyone at their word?
Discussing historical counterfactuals like this based on limited public testimony is a difficult matter, but my input here is that the ultimate breadth of changes envisioned by the systemd developers would have triggered a split anyway.
SJR's comments concern systemd-the-PID1.
Is there any reason, any at all, that you've provided to think that Lennart wouldn't have abandoned that project to contribute to Upstart, if the CLA issue had been able to be overcome? Because the testimony of people who would actually know this indicates that he would have. I mean, I'm happy to drop this argument if you find it a "difficult matter," but it seemed to matter to you enough to bring it up in the first place, and you seem to be focusing on trivialities that you think support your point rather than some pretty unambiguous statements from people who would know (and it seems hard to accuse SJR of some sort of pro-Red Hat bias ehre).
Something that can make a guy wonder if the root of the issue is Suse, as apparently that distro has always been "weird". Something that may well be a outcome of a corporate culture that former employees are now bringing with them to others.
As for LP's story not lining up with others. Not surprised. Best i can find the guy has never told a consistent account of things. The goal posts are forever moving.
https://lwn.net/Articles/507651/
> A newcomer to the top 20 companies is Vision Engraving Systems, thanks to the Comedi development work from H. Hartley Sweeten. With his work, hopefully this subsystem can move out of the staging area of the kernel in a future release.
> The Comedi project develops open-source drivers, tools, and libraries for data acquisition.
> Comedi is a collection of drivers for a variety of common data acquisition plug-in boards. The drivers are implemented as a core Linux kernel module providing common functionality and individual low-level driver modules.
> Comedilib is a user-space library that provides a developer-friendly interface to Comedi devices. Included in the Comedilib distribution is documentation, configuration and calibration utilities, and demonstration programs.
> Kcomedilib is a Linux kernel module (distributed with Comedi) that provides the same interface as Comedilib in kernel space, suitable for real-time tasks. It is effectively a "kernel library" for using Comedi from real-time tasks.
> [1] http://www.linuxfoundation.org/publications/linux-
> foundation... (Also, why do I have to tell the Linux
> Foundation who I work for in order to read this report?)
Frankly i see a bunch of beats fighting each other for old school territory, with the Linux ecosystem caught in the middle. None of the corporations involved with Linux are white knights, none.
I'm not sure why would anyone think this is a good thing
Even RMS supports commercial use of free software, and has stated before that binaries don't need to be free of cost, or that it needs to be easy to distribute, only that the source is available for modification and 'free' redistribution.
Canonical has every right to protect its brand. Firefox does this, as do many others. This doesn't change the fact that you can use their code as you wish.
If I release software under a BSD-style license with an additional proviso that you must demonstrate p=np before being able to redistribute it, we'd probably agree that it was non-free. If I release software under a BSD-style license with an additional proviso that you must replace a single file containing my trademark, we'd agree that it was free. Canonical's requirements are somewhere between these two things, but they won't tell us where. If it's impossible to determine whether a requirement is feasible, it's difficult to figure out what your practical ability to make use of those freedoms is.
Your responsibility is to abide by the terms of the license, and trademark law. It's not about what Canonical considers an infringement, but what the law considers infringement based on the interpretation of the license you implicitly agreed to and trademark law.
Canonical doesn't have the final word on things, but they do have a word on things: they can clarify their own position. If what they claim as trademarks goes beyond what trademark law allows, then it's true that they would be unable to enforce that in court, so it's ultimately not their call. But they could simplify the situation and reduce the risk to all parties of needing to resolve disagreements in court by explicitly stating their position on acceptable uses of their trademark, i.e. what they would not consider to be a violation of their protected interest. This would give downstream users at least a better understanding of Canonical's interpretation, which is key to avoiding expensive lawsuits: if you're using Canonical's trademarks only in ways that Canonical itself considers proper, then there's no disagreement that needs to be resolved in court.
This is the heart of the argument between the FSF and Canonical over whether the policy was GPL compatible or not. If it was merely a restatement of trademark law, it would have been. If it was an additional copyright-based restriction, it wouldn't. As https://www.fsf.org/news/canonical-updated-licensing-terms shows, Canonical chose to add a "trump clause" rather than clarifying their stance.
This kind of (intentional?) legal ambiguity ends up having a chilling effect.
What does trademark law say on the issue? I assume there are some differences between using a trademark and merely mentioning it, because if not then this post would be illegal due to having the words "Canonical" and "Ubuntu" in it.
> What do they consider trademarks, what do you need to remove?
They don't define trademarks, because it's a legal term that depends on the laws in your country, and not up to them to define.
Canonical's Q&A is merely clarification. At the end of the day, you're subject to whatever licenses you implicitly agree to, as interpreted by the laws in your jurisdiction (and maybe some international laws that your country recognizes).
It is up to the trademark holder to decide what they consider their trademark to be. That's why when defending a trademark you have to say "so-and-so is a registered trademark of so-and-so", and that's why when people defend trademarks they use a trademark symbol. People defending their trademark also have to decide what is or is not an acceptable use of their trademark. Furthermore, trademarks that are not defended are lost.
Copyright licenses also are completely irrelevant as regards to trademarks. These are different sets of laws. What is in effect here is what Canonical confusingly calls its "intellectual property policy", which is in effect only about trademarks, not any other law that people confusingly call "intellectual property".
That sounds more like "taking the work of others and trying to pass it off as their own" rather than "protecting their brand."
No one involved has a problem with branding guidelines that require replacing graphics, strings, and other branding information that shows up in user-visible locations. The problem is the weird and vague rules that Canonical imply to mean that anyone who redistributes packages from Ubuntu have to rebuild all binary packages (with an exception for GPL'd packages if that requirement would conflict with the GPL licensing which doesn't allow adding extra restrictions).
Because of restrictions like this, third parties who create forks of Ubuntu are left in a weird legal limbo. It can be solved by doing a full rebuild of all packages, but it is a lot of work and very error prone to set up a build system and rebuild every package. Rebuilding only the ones necessary for removing user-visible branding and whatever local changes are necessary is much simpler.
The other problem is that this policy was imposed relatively recently (in 2013). The previous trademark policy did not mention needing to rebuild all binary packages. So people who were relying on the earlier trademark policy are left in the lurch.
It's basically just clarification concerning the GPL and trademark law. Software licenses are legal documents, they're binding as far as the interpretation of the laws of the jurisdiction.
That's not what Canonical's policy says. What you described sounds like a perfectly sensible policy. However, Canonical's policy instead says you must remove all of Canonical's trademarks. Canonical's policy also does not limit itself to functioning under trademark law alone; as written, it functions under any mechanism Canonical has to add restrictions, which would include copyright law.
Which is perfectly acceptable. Red Hat and SUSE apply similar restrictions, hence why CentOS is a thing...
It's perfectly legal, which is a different thing. The entire premise of this article is that it isn't "perfectly acceptable", and causes serious practical problems.
> Red Hat and SUSE apply similar restrictions, hence why CentOS is a thing...
CentOS goes further than trademark law requires, and the nature of their project means they need to rebuild everything anyway.
While I don't know anything about SUSE's trademark policy, Red Hat has a far less restrictive one.
Red Hat merely requires that you remove the trademarks in the actual branding packages; they even explicitly state which packages those are, to make it very clear. From their trademark guidelines (https://www.redhat.com/f/pdf/corp/RH-3573_284204_TM_Gd.pdf):
You must modify the files identified as REDHAT-LOGOS
and ANACONDA-IMAGES so as to remove all use of
images containing the “Red Hat” trademark or Red
Hat’s Shadowman logo. Note that mere deletion of
these files may corrupt the software.
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. This does not affect
your rights under any open source licence applicable to any of
the components of Ubuntu. If you need us to approve, certify
or provide modified versions for redistribution you will
require a licence agreement from Canonical, for which you may
be required to pay. For further information, please contact us
(as set out below).
The Free Software Foundation and Software Freedom Conservancy have put out statements on this matter, criticizing Canonical for this vague policy:
https://www.fsf.org/news/canonical-updated-licensing-terms https://sfconservancy.org/news/2015/jul/15/ubuntu-ip-policy/
Whether this requirement is actually enforceable is another question. Given that Canonical ships copyright notices saying that the software may be distributed in source or binary form, and the only use of the trademarks is in some ancillary metadata on the packages rather than included in the packages themselves, it's unclear if this would actually be considered infringing on their trademark. But the FUD caused by their refusal to clarify this point means that it's a risk for anyone to try doing so; it's possible that a court could decide that it is likely to cause confusion, even in just the form of ancillary metadata in binary packages.
If what you said were true, whence the GPLv3? Tivoization, impossible build systems, etc., absolutely can defeat the purpose and spirit of free software. When they do, we are right to call projects hobbled by such practices 'virtually unfree' or 'practically proprietary' or whatever.
Compliance with free licenses makes the software free (legally). And of course, licenses are legal documents, subject to the laws in the jurisdiction that applies.
But I can't use the code as I wish. If I want to make a modification to it and then redistribute it, I then have to go through the entire codebase and remove trademarks. I wish to do the first step without doing the second step, and I can't.
Then most of Ubuntu, with the exception of the bits under copyleft licenses like the GPL that prevent Canonical from relicensing, is not Free Software, as Canonical have effectively placed another license over the top of it that makes it non-free.
(Note that while the FSF, Debian, and OSI definitions allow licenses to require renaming a product, mostly because of old TeX licenses, that doesn't mean they allow licenses to require extensive or functional changes of a non-specific nature throughout a codebase.)
Even the GPL licence has a "no warranty clause". The software is "as is", it is your problem to keep the pieces when it breaks. You can imagine a person spinning this into "you cannot trust open-source because they do not offer just a bit of warranty".
And Linux Mint also recompiles and replaces the trademarks no?
Sure, but presumably that took a lot of effort.
This is apparently why CentOS takes so long to track new RHEL releases: https://lwn.net/Articles/417849/
I'm not an expert, but to be honest this sounds pretty similar to what Garrett is complaining about:
"You may not name or brand your product “Red Hat” or use the Red Hat trademarks in any way, either on your product or in related advertising."
"You must use a different trademark for your product that will not cause confusion with the trademarks of Red Hat, will not indicate or imply that your product originates from or is sponsored or approved by Red Hat, and which otherwise complies with applicable trademark laws."
"You may not state that your product contains Red Hat Linux or Red Hat Enterprise Linux."
I do agree that Canonical haven't been clear enough on this issue but, in my humble opinion, their policies don't seem all that different from Red Hat's.
But... try getting patches in. Unless you're a paying member of the ISC consortium, you can't. There are performance problems going back a decade which are firmly in the "won't fix" category.
OpenSSL is similar.
TFA is about ubuntu making forking difficult.
"Free software" also means source-code being distributed under an FSF approved license. Unfortunately English doesn't have an equivalent for "libre", like romance languages do, with "free" being overloaded. So of course, usage of "free" has a long history of being overridden depending on context, going back to freemium/freeware/shareware. This is why context is important and why people then feel the need to be precise about the kind of free we are talking about - free as in beer or as in speech. You're talking about free as in beer and in our context Free Software really refers to FSF approved licensing. And Wikipedia does agree. Of course, the set of licenses that are FSF approved and OSI approved does overlap, though in theory you could have some differences, because the definitions are different. For example I think AGPL should not be OSI approved. But I digress.
Back to the point I want to make - source code being able does not make a software open source and having the binaries free as in beer does not make it free software.
It's MIT licensed. If you want to setup your own CI servers, you're free to fork the code.
I don't known your experience, but as soon you have a well known OpenSource project with binary distribution, you are going to see it available in a lot of scam download sites.
In fact, the OpenSource licenses allow it, and the author is going to have a hard time taking them down. In this regard, OpenSource licenses are too permissive, and are doing a disservice in being too easily abused.
Imposing additional restrictions to binaries, seems a good approach to have legal arguments to prevent that in the first place.
I don't understand why the hell anybody would want to fork Ubuntu to begin with. There are already enough linux distros that provide nothing but a thin veneer of look-and-feel over Debian.
If you want a high quality alternative to Ubuntu, use Mint. If you want something that's more open-source friendly, build on top of Debian.
Canonical is clearly trying to commercialize Ubuntu but does that really matter? It's not like they slapped Linus Torvalds with an gag order.
We see this all the time in online communities and we see it again with all this "hatred" against the Ubuntu community.
Here is Mark Shuttleworth replying to Garret: http://mjg59.dreamwidth.org/38467.html?thread=1474883#cmt147...
So Garret contacted Ubuntu for some unspecified project that he claimed he wanted to start. In reality, he was mining for quotes to misinterpret. Sad git.
> So Garret contacted Ubuntu for some unspecified project that he claimed he wanted to start. In reality, he was mining for quotes to misinterpret. Sad git.
Trying to create some legal security around derivatives of Ubuntu, he asked for clarification in general, not about any particular project, but about any possible project started by anyone. The question is really quite clear: "What precisely does one need to change for Canonical to be comfortable that one isn't trying to pass it off as Ubuntu". Their answer was "we won't tell you".
It looks to me like you're trying to spin this somehow to make Matthew Garrett look bad, accusing him of spinning it to make Canonical look bad. While the whole exchange could have been handled better on both sides, I don't see how Matthew Garret is to blame for Canonical's unwillingness to clarify their IP policy.