Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If it's not practical to redistribute, it's not free software in practice

lwn.net

Post reply on HN
Print view View original

131–139 of 139 posts

Re: If it's not practical to redistribute, it's not free software in practice

#131

Post by felipeerias »

mjg59 wrote: post #129
felipeerias wrote: post #126

Earlier quoted context omitted.

Are you referring to point D, "modify the files identified as REDHAT-LOGOS and ANACONDA-IMAGES"? Because that doesn't seem sufficient to fully comply with all of the previous points. 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.

It complies with the changes you have to make in the software. You still have to deal with the use of trademark around it, such as the names you associate with the software when you sell it. If you make those changes and then don't claim that what you're selling is RHEL or stick any Red Hat logos on your website, Red Hat won't sue you. It's unclear whether or not that's sufficient for Canonical to be happy.

Can you use RHEL's binaries in a derived product?

Re: If it's not practical to redistribute, it's not free software in practice

#132

Post by mjg59 »

felipeerias wrote: post #131
mjg59 wrote: post #129

Earlier quoted context omitted.

It complies with the changes you have to make in the software. You still have to deal with the use of trademark around it, such as the names you associate with the software when you sell it. If you make those changes and then don't claim that what you're selling is RHEL or stick any Red Hat logos on your website, Red Hat won't sue you. It's unclear whether or not that's sufficient for Canonical to be happy.

Can you use RHEL's binaries in a derived product?

Yes. The Red Hat support contract indicates that sharing RHEL binaries with someone else will result in Red Hat terminating support for you (something that I find incredibly offensive and objectionable), but if you give the binaries to someone else then they can give them to anybody else they want to.

Re: If it's not practical to redistribute, it's not free software in practice

#133

Post by creshal »

vacri wrote: post #114
creshal wrote: post #59

Earlier quoted context omitted.

Init systems are, by nature, highly invasive. Systemd's requirements don't fundamentally differ from modern sysvinit derivatives or upstart or whatnot in that regard. 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.

Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools. Other init systems don't. You can't just drop systemd in and get by just with learning it's config language - you have to change the way you do a number of other things, too. But then again, you don't think that there are dozens of desktop environments. Arch supports nearl…

> Systemd replaces a lot more of the system than other init systems - for example, it has it's own journal format, and also has it's own time tools.

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.

Re: If it's not practical to redistribute, it's not free software in practice

#134

Post by felipeerias »

mjg59 wrote: post #132
felipeerias wrote: post #131

Earlier quoted context omitted.

Can you use RHEL's binaries in a derived product?

Yes. The Red Hat support contract indicates that sharing RHEL binaries with someone else will result in Red Hat terminating support for you (something that I find incredibly offensive and objectionable), but if you give the binaries to someone else then they can give them to anybody else they want to.

In other words, there is no way for you to get continued access to Red Hat's binaries while redistributing them as part of a derived product. So the only sustainable strategy is to recompile the source code to create your own binaries. And if you do that, you must remember to remove and replace the trademarks because you are not allowed to use the Red Hat trademarks in any way on your product. So the difference boils down to Red Hat clarifying what that requires, while Canonical has remained intentionally ambiguous. Is that right?

Re: If it's not practical to redistribute, it's not free software in practice

#136

Post by EvanPlaice »

Or... you know. Don't use Ubuntu.

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.

Re: If it's not practical to redistribute, it's not free software in practice

#137

Post by digi_owl »

cwyers wrote: post #73
vezzy-fnord wrote: post #49

Earlier quoted context omitted.

I'm not sure why you think this is a bad thing. Canonical is a corollary to Apple in the Linux world. They set their own agenda with limited cooperation. 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…

Here's a good example. 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 w…

Then again RH did a 180 on how they packaged patches etc after Oracle did exactly the same as CentOS had done for years.

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.

Re: If it's not practical to redistribute, it's not free software in practice

#138

Post by digi_owl »

cwyers wrote: post #79
vezzy-fnord wrote: post #74

Earlier quoted context omitted.

Your story is factually off, I'm afraid. 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…

Most of your corrections to my story aren't really germane to the point, and mostly involve your constant flogging of a bunch of sysvinit replacements that never caught on, but there's one where I think you move from mere pedantry to being wrong: > 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) a…

Link is going 404...

Re: If it's not practical to redistribute, it's not free software in practice

#139

Post by digi_owl »

vezzy-fnord wrote: post #82
cwyers wrote: post #79

Earlier quoted context omitted.

Most of your corrections to my story aren't really germane to the point, and mostly involve your constant flogging of a bunch of sysvinit replacements that never caught on, but there's one where I think you move from mere pedantry to being wrong: > 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) a…

Kay Sievers was actually a SUSE employee at the time, IIRC. 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 reac…

> Kay Sievers was actually a SUSE employee at the time, IIRC.

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.

Post reply on HN