Live data from Hacker News

Red Hat cutting back RHEL source availability

lwn.net

261–270 of 339 posts

Re: Red Hat cutting back RHEL source availability

#261
post #259
post #255

Earlier quoted context omitted.

It sounds like you're implying that permissive licenses don't count as free software licenses, but that has never been true. FSF has always said that permissive licenses are free software licenses and that permissively licensed software is free software. However, they advocate the position that this might not be the best way to protect all downstream users' freedom.

I do, and it has been true (I believe it still is, that's fundamental to the notion of freedom): https://www.gnu.org/philosophy/open-source-misses-the-point.... > When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of “free speech,” not “…

Right, so you might have, for example, FreeBSD, which as distributed by the FreeBSD developers is free software, but which can also potentially be used in a proprietary downstream product, which is not free software. The FreeBSD developers did not deny users any of the four freedoms. They just allowed other people to potentially do so.

This Venn diagram is FSF's view of the taxonomy:

https://www.gnu.org/philosophy/categories.en.html

Re: Red Hat cutting back RHEL source availability

#263
post #258

Earlier quoted context omitted.

MIT, BSD, Apache, anything that is open source but allows you to make the code proprietary. > When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of “free speech,” not “free beer.” https://www.gnu.org/philosophy/open-source-misses-the-poi…

You are wrong according to the FSF. They consider all the licenses you mentioned to be free software licenses. https://www.gnu.org/licenses/license-list.en.html#apache2 https://www.gnu.org/licenses/license-list.en.html#X11License https://www.gnu.org/licenses/license-list.en.html#FreeBSD

Right, my bad.

Permissive licenses are "free" in the sense that they allow to distribute free software (e.g. I can distribute a binary together with its sources even if they are MIT-licensed, and that would be free), but they also allow to distribute non-free software (e.g. I can take MIT code and distribute a proprietary binary).

Copyleft licenses enforce the freedom downstream.

I guess my original point is that I don't understand why people don't like copyleft, because copyleft enforces free binaries.

Does that make sense? Thanks for the correction.

Re: Red Hat cutting back RHEL source availability

#264
post #261
post #259

Earlier quoted context omitted.

I do, and it has been true (I believe it still is, that's fundamental to the notion of freedom): https://www.gnu.org/philosophy/open-source-misses-the-point.... > When we call software “free,” we mean that it respects the users' essential freedoms: the freedom to run it, to study and change it, and to redistribute copies with or without changes. This is a matter of freedom, not price, so think of “free speech,” not “…

Right, so you might have, for example, FreeBSD, which as distributed by the FreeBSD developers is free software , but which can also potentially be used in a proprietary downstream product, which is not free software . The FreeBSD developers did not deny users any of the four freedoms. They just allowed other people to potentially do so. This Venn diagram is FSF's view of the taxonomy: https://www.gnu.org/philosophy/…

I was wrong indeed, thanks for the precision :-). So:

Permissive licenses are free in the sense that they allow making free software (but they also allow making non-free software).

GPLv3 enforces the complete derived work to be free. LGPLv3 says that the particular library should stay free.

GPLv2, LGPLv2 and MPLv2 say that the source code (either of the whole derived work or just the library) should stay free, but tivoization allows making the product non-free.

Is that about right?

Re: Red Hat cutting back RHEL source availability

#265
post #263

Earlier quoted context omitted.

You are wrong according to the FSF. They consider all the licenses you mentioned to be free software licenses. https://www.gnu.org/licenses/license-list.en.html#apache2 https://www.gnu.org/licenses/license-list.en.html#X11License https://www.gnu.org/licenses/license-list.en.html#FreeBSD

Right, my bad. Permissive licenses are "free" in the sense that they allow to distribute free software (e.g. I can distribute a binary together with its sources even if they are MIT-licensed, and that would be free), but they also allow to distribute non-free software (e.g. I can take MIT code and distribute a proprietary binary). Copyleft licenses enforce the freedom downstream. I guess my original point is that I d…

Yes, that sounds right to me. “Free Software” and “open source” are synonyms, with the FSF preferring to use one term over the other, despite recognizing they’re synonyms, because they are ideologues who are obsessed with language use. Permissive and copyleft are two different types of free software/open source licenses, with the FSF preferring copyleft.

To answer your underlying question: I like permissive licenses because I am not ideologically opposed to unfree software, and I’d rather software be used by a company than not at all.

Re: Red Hat cutting back RHEL source availability

#266

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

I don't really agree. RHEL is nothing special. Important for Enterprise and thus free availability is handy for people having an interest in becoming a sysadmin to learn it. Dogfooding work stuff is the only reason I'd consider using it or its derivatives at home. But I don't care even about that and my stuff all runs BSD :P But other distros are much better IMO. There's good reasons that a totally free distro like D…

[deleted]

Re: Red Hat cutting back RHEL source availability

#267
post #264
post #261

Earlier quoted context omitted.

Right, so you might have, for example, FreeBSD, which as distributed by the FreeBSD developers is free software , but which can also potentially be used in a proprietary downstream product, which is not free software . The FreeBSD developers did not deny users any of the four freedoms. They just allowed other people to potentially do so. This Venn diagram is FSF's view of the taxonomy: https://www.gnu.org/philosophy/…

I was wrong indeed, thanks for the precision :-). So: Permissive licenses are free in the sense that they allow making free software (but they also allow making non-free software). GPLv3 enforces the complete derived work to be free. LGPLv3 says that the particular library should stay free. GPLv2, LGPLv2 and MPLv2 say that the source code (either of the whole derived work or just the library) should stay free, but ti…

That matches my understanding. Some people might potentially only say "tivoized" (or a more explicit "incorporated in a product that prevents the user from modifying it in practice" or "incorporated in a locked-down product" or something) rather than "non-free" for a hardware product, but I guess "non-free" could also make sense for a hardware product.

Re: Red Hat cutting back RHEL source availability

#268
post #50

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

I thought that was well known, it's not like they were secretive about it, in fact they openly advertised it. Their sales pitch, I think was, that many customers ran Oracle software on RHEL, and this way they would have a single provider of support for both the OS and the software running on it. Given Oracle's rather well-earned reputation, that does not sound like an attractive proposal to me, but there's a chance o…

As an employee, I dont think anyone can. I'd make speculation here, but we all know how that ends up being twisted into misunderstanidng. The current kernel source is available on gitlab though (centos-streams) because now centos streams is upstream of rhel kernel.

Re: Red Hat cutting back RHEL source availability

#269
post #222
post #206

Earlier quoted context omitted.

> The "Unbreakable Enterprise Kernel" includes full btrfs, extensive device support (that is removed from the stock kernel), is tuned for the eponymous database, and is always more current. There are several scenarios where it is very attractive. I'd never go for btrfs in anything enterprise. But it does annoy me how RHEL moves normal open source software to the separate repos that are available with extra support pa…

It also annoys me to great extents when Red Hat removes support for SAS raid cards that are perfectly usable. Oracle fixes that.

Removed it midstream or between releases ?

Re: Red Hat cutting back RHEL source availability

#270
post #201

Earlier quoted context omitted.

> Rocky and Alma are doing exactly what CentOS pre-Stream did for _six_ years. Now they're frustrated that their decision to kill the CentOS idea didn't stick? CentOS wasn't selling support contracts tho. Not that I think anything they are doing is in any way wrong mind you.

To be fair, neither is Rocky.

https://sam.gov/opp/2e0365ce1e3c4c179b50fb15573d68e4/view
Post reply on HN