I don't follow it much these days, but nothing really surprises me from Canonical anymore. They leech off free software just like any other corporation.
If there are any SV billionaires out there, can you fund CUDA on OpenBSD please? :-P
Unless I'm remembering it wrong, I'm honestly not surprised that they might just be less worried about licensing in general after that; maybe this is the software licensing equivalent of "too big to fail"?
Or they correctly interpreted the law?
Few of us care to admit how this "legal consensus" is mostly BS. Lots of evidence to the contrary, but, like politics these days, it sure is an appealing fantasy?
If the common consensus was BS, I actually don't think that detracts from the larger point I was trying to make much; I probably distracted from it too much with my over-enthusiastic wordplay at the end, but my original intent was to convey that Canonical might just intentionally have decided that they aren't concerned with the types of licensing issues that people are discussing here with regards to coreutils. If my theory is correct, it's due to sound legal judgment or intentional non-compliance isn't something I have any strong insight into; I mostly just thought it was worth suggesting that what people here think about it might not really matter all that much because it seems unlikely to me that they'll either be convinced to change their plans or suffer significant negative consequences from going forward with what they've decided, regardless of whether it's right or wrong.
I think your recollection here is pretty colored, or else you were only reading stuff from one particular bubble. My own recollection is that there were very compelling arguments to the contrary, ones that I agreed with. Like, foundational to the concept of civil court cases is "standing" which is almost invariably down to a party suffering damages. Courts aren't a venue (at least in the US in general) for solving debates of abstract philosophy, that's what civil society is about, they're for applying the state's general monopoly on violence in order to rectify harms. Party A claims they were damaged by Party B (statutory, actual or both) in a way that violates the law. The remedy if they win is generally that they are made whole via money as best as possible or, rarely, via actual performance by Party B.
But if open source license GPL code is distributed with open source license CDDL code, with full access the source of both available, who is losing money on that? Who is getting damaged? What rights are being lost? Who has standing to sue over it? The idea that it's banned at all isn't tested legally anyway afaik, but more fundamentally if there is no harm then there simply isn't any court case. Say you saghm decided tomorrow that you were really steamed about ZFS being included with Ubuntu and decided to get going on your lawsuit on Monday, when the court asks "how much money did that cost you and what do you want us to do about it" what would your answer be, even putting aside "what's your theory of law on this one".
>and from what I can tell, they basically got away with it?
Well, that would be expected if there just isn't any case there right?
(I don't approve of this system, I am merely describing what I see as the status quo.)
As has been said, being a FOSS "advocate" may put you on many sides of any copyright issue.
> RIAA isn't going to waste time finding out if the recipients were planning to buy CDs otherwise. If you receive software under a license that is too restrictive for you, then there is always the option to pay the rightholder to grant you a more permissive license in exchange for money.
Your comparison fails to understand how different these claims are. First, those CDs have a price on the tin. That is -- this claim would have "actual damages" which can be readily determined. Second, you're speculating a new license for either Linux or OpenZFS is possible, but I don't think anyone imagines either is readily available given the number of rights holders. If Oracle was offering to relicense (BTW only its portion of the ZFS source) for a known and reasonable amount $X, like your CDs, then your comparison might make more sense (but read on, the offer of another license does not preclude a finding of non-infringement).
Thankfully, of course, copyright law provides for statutory damages where actual damages cannot readily be proven, as here. But those nominal/statutory damages divided up among Linux rights holders would be almost insignificant, and therefore this poster above is likely correct -- this may not be a legally cognizable injury.
While I may agree re: this poster's damages analysis, I'm not even sure that's the best form of the ZFS argument. IMHO where anyone creates a functional software interface, whether it be via game console's cart or a kernel module, fair use allows one to create to software and use that interface. Period. Your license can say whatever it wants. Your license can say "all your software now belongs to use" and IMHO it is completely unenforceable. IMHO the courts have favored software interoperability and fair use for years.
For example:
In Sega Enterprises, Ltd. v. Accolade, Inc., the court denied copyright protection for “functional requirements for compatibility with the Genesis console . . . .” Under this approach, the right of the kernel module author to create a compatible module overrides any nominal copyright infringement created when that author creates static or dynamic links to kernel code. Sega’s Genesis console had no public API whatsoever, stable or otherwise, yet the court still denied protection to these functional elements. Regardless of the status of the API or system interface required for compatibility, any parts of a program that a developer must copy — such as kernel headers, definition files, variables, or mandatory Linux kernel function calls — in order to create a Linux-compatible kernel module would not receive copyright protection.[0]
Note, Sega even offered Accolade a license (just as we discussed the potential for an alternative license above) that would have allowed Accolade to create Sega-compatible games. Notwithstanding this offer, the court declined to find copyright infringement in Accolade’s creation of Sega-compatible games without a license.
[0]: https://www.networkworld.com/article/836041/smb-encouraging-...
Who's an advocate here?
> Your comparison fails to understand how different these claims are.
Comparisons don't understand anything. I mean to draw attention to aspects shared by two different things.
> I don't think anyone imagines either is readily available given the number of rights holders
Me neither, but I don't think that's pertinent. Why do you?
Finally, you make an argument about interfaces, but I think the issue here is the use of CDDL licensed code, rather than the (re-)implementation of an interface. To me it seems like the finding in Sega v Accolade aren't relevant here.
Yes, I understand you meant to reason by analogy, and I told you that I think your analogy is flawed. When you reason by analogy, perhaps you should be prepared for someone to say, "That analogy doesn't make sense in this context." Mostly because -- your analogy doesn't make sense in this context. One, is an actual damages case, and the other is statutory damages case. When we are strictly discussing damages, your comparison is an apples to oranges comparison.
You said:
>>> If you receive software under a license that is too restrictive for you, then there is always the option to pay the rightholder (sic) to grant you a more permissive license
You suggest "there is always the option to pay the rightholder (sic) to grant you a more permissive license" and I'm saying that it's impossible in this circumstance? There is no one stop shop for the licensee. There is no 50 stop shop.
In your scenario, where we are to imagine an incompatibility exists, you also imagine a theoretical alternative license would be relevant to a court. And I'm saying, just as relevant, is the actual impossibility of obtaining the consent of either all ZFS licensors or all Linux licensors.
We've created effectively perpetually licensed software via our shared use of FOSS. And now one party we imagine saying -- actually these two works will be incompatible forever. You think a court won't think that's wild?
More significantly, this entire line of argument has an angels on the head of a pin quality. The GPL and the CDDL are the licenses that have already been chosen by Canonical, because Canonical didn't, like you, read an incompatibility into this CDDL-GPL combination. So -- fair enough that Canonical didn't feel the need to cast about for some theoretical alternative license, if it doesn't feel that the CDDL and the GPL are incompatible.
> I think the issue here is the use of CDDL licensed code
As discussed -- I don't think it matters much how the code is licensed. If it makes it easier, imagine the CDDL sourced code is actually a closed source, proprietary filesystem. So -- Linux provides a module interface, but it could be any interface. Just as in Sega, IMHO even proprietary code can use GPL licensed code, which provides an interface, for the purposes of interoperability. Why? Because "fair use".
I think we're really going to miss having the fundamental parts of the system available under strong copyleft, and it will be very hard to go back.
Apart from Clang/LLVM and WebKit you mean?
Ok in fairness the LGPL license of KHTML was a huge reason the WebKit source was available (for ages it was just reluctant tarball dumps) but I don't think that's the case for LLVM.
I don't think the GPL has really meant corporation's have given back significantly to Linux. There are still plenty of closed source drivers. The main motivation to give back is the extremely high cost of maintaining out-of-tree modifications (e.g. Android's binder).
The compiler and toolchain really are going the wrong direction with LLVM in terms of open source.
And hey some of the work does get upstreamed, which is probably a good choice for the vendor anyway if the target in question isn't intended to be immediately thrown in the thrash and forgotten.
It was originally supposed to. https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
In particular:
> I think the GPL has led to fairly noticeable increase in the amount of proprietary software in the world as companies that would happily adopt a BSDL component decide to create an in-house proprietary version rather than adopt a GPL’d component.
It also aligns with my experience: my company couldn’t find an LZO compression library that wasn’t GPL’d, so the decision was between implementing one in-house or cutting the feature. We ended up restricting use of the feature to in-house use only, but opening up our core source code was never an option.
If there had been a permissive license option available, we would’ve likely donated (as we do to several other dependencies), and would’ve contributed any fixes back (because that’s easier to explain to customers than “here’s our patched version”).
Sorry, trust has been broken too often in these scenarios, and the benefits of lots more people working on the same library are not entirely clear.
I understand that many companies don't want to be a part of the pool of software licensed under the GPL - that is their right. But don't try to spin this "if only BSDL was the common one, there'd be a much bigger utilization of a different pool of software". That might even be true, but it would come with the caveat that tivoization would always be an option, which for some of us is something more significant.
If I put two choices in front of someone, the binary option of copyleft vs proprietary and they'll always go proprietary, or I give them something permissive and there's at least the chance they contribute back, the second option is strictly better. It's sort of the equivalent of having a wealth tax that raises no revenue, I'd rather have you here contribute something than move abroad and get nothing, even if the benefit is more indirect
We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.
Read LGPL a little more carefully. LGPL requires you to use it in a particular manner that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library. Even if you make no changes to the library!
I had thought that the dynamic linking requirement was the only option according to the licence, but apparently not. According to 6.a. of v2 and 4.d.0. of v3 of the LGPL, it would be enough to give the user access to the source/object code of the main application and the compilation scripts under non-open-source terms, so that they can recompile and statically link it against their own version of the library.
Partly related. Would you have paid if the project had offered a paid non GPL licence?
We probably would’ve for LZO too; not sure why that fell through.
How would the legal argument be any different for MIT/etc. licensed software in that case? Would the lawyers sign off on using MIT-licensed software without a CLA? Wouldn't they make the argument that the provenance of the software and therefore its licensing is not solid? Seems like the only thing that matters is who has the right to offer a license to the software, not what the license is.
I think the reasoning (as it was explained to me) was that when people made their original contributions, they were agreeing to the license at that time (in this case GPL, but for other projects MIT). But the other contributors never agreed that the main maintainer could relicense their contributions for a fee.
The upshot was that we went with an in-house fully-proprietary alternative. More expensive, probably lower quality.
Lots of people express this fear that BSD-licensing of components will lead to a world where all the big proprietary software just locks everything down. But if you actually work with large software, you end up finding out that it's actually a lot of work to maintain your own fork, and so you start pushing to get more things upstreamed. Because, after all, if your code is private, it's your task to fix it if somebody breaks it, but if it's upstreamed, it's their task to do it.
An interesting datapoint is LLVM/Clang, where, yes, lots of companies have their own proprietary forks of Clang. But for the most part, those companies still upstream gobs of stuff: most of the biggest contributors to the project are the people with the proprietary forks. Furthermore, as I understand it, basically everybody relying on EDG has, or is in the process of, worked to move off of it into Clang. Which, if EDG dies, means that the permissively-license Clang has done more to kill off proprietary compilers than copyleft-licensed GCC has.
The best defense against proprietary software is to make it too expensive for proprietary software to compete, and using a permissive license means you can trick the companies making proprietary software into helping you do that.
It's also an example of the GPL not preventing corporations from building (and releasing under a more permissive license) non-GPL software.
Before Apple built Clang, they made a GCC plugin[0] which dumped the AST from the GCC frontend, and fed it into the LLVM backend. Sure, they published the source of their GCC modifications under the GPL, but that was nothing compared to the entirely novel backend, which was released under a far more permissive license.
Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.
[1]https://lists.gnu.org/archive/html/emacs-devel/2015-01/msg00...
But they didn't! Dragonegg is a GCC plugin, which didn't exist when work started on Clang--GCC plugins date to GCC 4.5, released in 2010, which is the same year that Clang became self-hosting.
The timeline is rather like this: LLVM originally relied on a hacked-up version of gcc 4.2 called llvm-gcc to create LLVM IR from source code. When GCC added support for plugins, there was the attempt to move that frontend to a more reliable framework, and that was Dragonegg. As far as I'm aware, Apple never contributed to the Dragonegg project itself. Dragonegg didn't last that long; by 2014, the project was completely dead. And for most of its life, the biggest interest in Dragonegg was to have some modicum of support for Fortran.
> Meanwhile, Stallman handcuffed GNU projects like Emacs for years[1] by refusing to expose GCC's AST in an effort to prevent something like this from happening.
By the time of that message, RMS's worst nightmare had come true with Dragonegg... only for Dragonegg to have already died due to a lack of demand for it.
> the GPL has led to fairly noticeable increase in the amount of proprietary software in the world
What he did:
> opening up our core source code was never an option.
It's companies that decide that open sourcing their software is 'never an option'–even the LZO compression part of it–that lead to a 'noticeable increase in the amount of proprietary software in the world'. They are just using the GPL bogeyman as a thin excuse for their own decisions.
I will go on record now with the prediction that, if uutils catches on, Red Hat will be one of the last companies to move away from GNU. They are probably the largest contributor to glibc and GCC.
What evidence do you have that they would have "preferred not to provide source at all"? Because their is a mountain of evidence otherwise.
As an individual user, Red Hat will give you a free license to their flagship product. Then they will tell you how to download every line of code for it. I don't have a license. I do not use Red Hat (other than occasionally using the also totally free RHEL9 container).
"Remember when Red Hat tried to lock away the source code to subscribers only?"
I do not remember them changing the policy you are talking about. If you think they did, it highlights how overblown the response was at the time. The biggest impact of the Red Hat change is that Alma Linux is now a better project that can actually innovate and contribute.
Red hat provided the source to their kernel with the letter but not the spirit of the law, to impeed Oracle Linux. We'd (Ksplice) get the changes from Redhat version to version as one giant patch file, with all the changes mixed together. There's no chance in hell their internal kernel developers worked that way, but the source was there, so the letter of the GPL was satisfied.
The other thing they did was close the source repos. First you had to be a subscriber to get the binaries, and thus by the GPL, you could get the source. However, if you shared that source code with anyone else and they caught you, they wouldn't let you renew your license the next year, so you couldn't get the newer version, binaries OR source. This also isn't technically against the rules of the GPL, but it's hard to see that as being in line with the spirit of it.
It's hard to see Redhat as the benevolent GPL open source hug supplier with real world business practices like that. Not that I fault them for it, it's just business.
Unbreakable Kernel.
https://arstechnica.com/information-technology/2023/06/red-h...
Again, be careful not to attribute past RH actions with IBM. Yes, IBM was very helpful in the 90s and later, but you can't fully trust a corporation past the next financial statement, and certainly not past a leadership change or three.
As he says, it's just business. And IBM isn't near the top on my list of big tech companies to avoid. However they are subject to the same enshittification pressures as the rest. Their history is not all rosy either.
The absolute most that Canonical can do is start making a fork of the software where they don't distribute the source code. But in that case, the original code is still right there. No freedom is lost at any point.
Them putting the downloads of their enterprise OS behind a login screen (student and solo developer licenses can STILL be got for free) is something I 100% understand and am kind of sympathetic about.
I know that's out of like with how some people define free software, but I've always had ethical issues with the way people would redistribute Red Hats work for free. Just because it's legal doesn't make it ethical.
If there's one thing people need to understand it's that corporations will always strive to take as much as they can and give back as little as they can. It's incredibly naive to think they won't do it again after that's exactly what every corporation has done for the past several centuries. Give an inch and they'll take a mile. You can't seriously think companies like Microsoft and Oracle aren't already salivating at the thought of the community rewriting GNU/Linux in a permissive licence?
It's not that this particular case is "freedoms being attacked". It's that freedoms are constantly and relentlessly under attack and we can't let our guard down for one moment. GPL is our protection and voluntarily stepping out of it would be suicide.
But yes, there were additional licensing assurances provided so as to not create problems for Novell/Mono - it was always treated positively.
1) Safety. With a Rust replacement, there's no more risk that a UAF CVE in ls(1) can run arbitrary code as you or something.
2) Modernity. Maintaining a crufty old C code base might have been par for the course in the 90s, but today's younger programmers will have none of it. Standardizing on a Rust base will ensure you have a large maintainer pool going into the future.
3) The GNU Project is problematic. It's just about run its course in terms of relevance, and especially with the larger number of women (cis and otherwise) and nonbinary folx doing work in open source, aligning yourself with anything involving Richard Stallman presents an ethical sticky wicket. An alternative is called for, and uutils presents one with some nice properties relating to 1) and 2) above.
Rust hit 1.0 *10 years ago*. How many more years will it take for people to stop constantly insinuating that people only use it because of the hype, and not simply because it's a vastly better language than C?
It boils down “this language may have merit but I don’t like the way people advocate for it”. That’s just tone policing. And the thing about tone police is that the standard they set is vague/nebulous and therefore impossible to satisfy.
You have some “right way to advocate” in mind. Other tone police have some other “right way”. But advocates aren’t mind readers, nor can they satisfy all your demands simultaneously.
> push the language everywhere, regardless of it’s appropriate
Where is the language inappropriate? Notice you don’t say, so while it sounds like you’re making a technical argument it sounds like a pensioner whining about kids on his lawn.
That’s all this really boils down to. The whiners don’t have any technical arguments, they’re just old conservatives who like the way things have always been and want to keep it that way. In place of technical arguments they say silly things like “of the millions of rust developers out there, I didn’t like a few comments made by some of them”. Cool.
See, you’ve proven my point perfectly. You’re incapable of making a technical argument so you focus on the tone - “evangelist”, “bad faith”, “insufferable”.
> I rather write in a supposedly suboptimal language than dealing with those like you.
To be clear, you can download the compiler for free and write all the programs you like while interacting with 0 people. You’re talking to me because you’re on HN, not because you’re writing Rust. Isn’t that obvious?
“I don’t like the way some people speak” is not a technical reason and has no place in a technical discussion. It’s especially meaningless because no one can possibly like the way every person in a group of millions speaks.
A person who eschews technical discussion in favour of tone policing is not a person whom I take seriously. If you want to hang out with and learn from such people I wish you luck. Your age doesn’t matter. A 20 year old can have their thinking ossified just as much as a 60 year old.
> it's a vastly better language than C
when they could just say "it has some important features that C does not have and likely will never have".
He’s also been extremely prescient and decades ahead of his time. He stood his ground against relentless attacks where so many others have sold out and betrayed whatever morals they thought they had.
From my perspective, it seems imminently plausible. Who cares about the licensing?
But I'm interested in what leads you to the opposite conclusion.
Well, for one, the author of the Rust based utils cared enough to change it (or rather to not re-adopt GPL, but IMO that's the same ting). Why shouldn't we care about the licencing?
I know people do care about licensing, but it's also plausible that it isn't what any given project is most focused on.
Also anyone that really cared could use the BSD versions anyway.
Sorry, don't believe this one bit. I'm very thankful for everything Canonical/Ubuntu did about 20 years ago, but no thanks. This comes from someone who loves Rust and what it made possible. However, freedoms are too important to not treat anything that looks like an attack on them as such.