MIT license? Is open-source dying?
the question seems non sequitur.
if you prefer "is free software dying"?
Cross-platform Rust rewrite of the GNU coreutils
301–310 of 498 posts
Re: Cross-platform Rust rewrite of the GNU coreutils
#302Earlier quoted context omitted.
There's nothing wrong with reading the source code. You're allowed to read whatever you like! Just don't copy it.
Well there's the rub - once you see the source code, it's tough to say you weren't influenced by it. In for-profit endeavors this kind of thing is typically done by having two separate groups of people, one that sees the competing product and writes detailed descriptions of behavior, and one that never sees the product, only the product of the first group. If you're careful about this and go to pains to keep the grou…
We're talking copyright here, not patents. If I read copyrighted C code, and rewrite it in Rust, I don't think a copyright claim can touch you, no matter how similar they are.
Note well: IANAL. This is my understanding of copyright law, not legal advice.
Re: Cross-platform Rust rewrite of the GNU coreutils
#303Earlier quoted context omitted.
The quality of tooling, and the ability of experts to verify the output of machine code is a really important point. I think I'd agree, rust at this point would hold back an elite developer like Richard Hipp. The promise of rust, which may or may not be realized is pushing some very common problems down to the compiler. All code has bugs, so the compiler probably does things wrong in some cases. As the tools mature,…
> That said, array bounds checking is responsible for so many problems, it seems worth it to raise the minimum for a language. Amen to that! If I could just add one feature to C - at least as an option - it would be array bounds checks. I have no trouble with manual memory management - a garbage collector is nice to have, but I have not had many problems with memory leaks or dangling pointers. And the ones I had were…
> I have not had many problems with memory leaks or dangling pointers. And the ones I had were relatively easy to locate and fix.
Note that every single browser vulnerability in this year's Pwn2Own was a use after free (dangling pointer).
Re: Cross-platform Rust rewrite of the GNU coreutils
#304Earlier quoted context omitted.
Did you see the short-lived attempt to create "friendly C" a few months ago? [1] There's languages that have a few undefined corners, and then there's C. A sufficiently large difference in quantity becomes a difference in quality. C is qualitatively worse than most modern languages with its undefined behavior. (Granted, some modern languages escape by having the one implementation, which is then the definition. But s…
It was too ambitious. Some of those examples, like shifting by 32, are about trying to remove even unspecified behavior. If you could reduce most cases of undefined behavior down to "what some real machine would do", it would be an enormous help, and wouldn't be anywhere near as hard. For example you could say that division by zero will either give a result or trap, but that it can't do anything else, and the code pa…
> Or that an uninitialized variable is equivalent to initializing it with a semi-random number.
This proposal destroys lots of dead code elimination optimizations that are very important in code post inlining (for example, in the STL).
Re: Cross-platform Rust rewrite of the GNU coreutils
#305Earlier quoted context omitted.
Yes, it is. This is an excessive level of caution which does not reflect the permissiveness of actual copyright law. However, there is the concept of "unintentional copying", which is effectively what you're describing, and which is still considered an infringement under copyright law, however it's very, very unlikely that such an argument would be used in court with regards to software, and even more unlikely that a…
A further complication for us is that the Mathworks is rich and amoral while GNU Octave is tiny and idealistic. If we ever become large enough for them to notice us, we have to make sure that we never give them the slightest argument in their favour. Should our code ever end up looking similar (similar variable names, similar structure), we have to be able to say that it's purely coincidental.
That's a fine reason for going the extra mile to protect yourself against a hostile adversary but understand that it really is "the extra mile". While it may be prudent in your situation, it is heavy-handed and unnecessary in general.
Re: Cross-platform Rust rewrite of the GNU coreutils
#306Earlier quoted context omitted.
No. It's not a derivative work. Creating a compatible piece of software is not copying. Even if you've seen the original code. If you're not literally copying and pasting code, it's fine. Copyright protects the code itself from being copied, but the ideas, abstractions, overall design, and even individual APIs are not eligible for copyright protection
I don't think that is accurate. If your work is derived from the source - even if you don't replicate the original - you're infringing copyright. That's why clean room design is so important.
Define "derived from".
Back in the BIOS clone days, they had someone read the IBM BIOS code, and write a detailed specification from it. They had someone else never look at the IBM BIOS, read the specification, and write code to implement it. (This was the "clean room" approach - the IBM BIOS was never in the room of the implementers.)
But that's still "derived" in the sense that it implements the same functionality. But it's perfectly legal. So "derived" doesn't mean "implements the exact same functionality as the other, and we examined it in detail to make sure".
Why did they do the clean room approach? So that IBM could never claim that they had copied the IBM BIOS, even by re-typing rather than electronically copying.
Well, if you're re-implementing it in Rust instead of in C, you're not copying it, either. You're making a completely new implementation. (Rust doesn't take C code as valid syntax, so far as I know, so typing in the same code from memory wouldn't get you anywhere.)
Re: Cross-platform Rust rewrite of the GNU coreutils
#307Earlier quoted context omitted.
Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. (Incidentally, while I think that part of the reason why Git is this way is due to design differences from CVS, this isn't essential to it being true. Git is also better than Monotone or Fossil or Bazaar, despite being much closer in design, because it has network effects…
> Git makes it easier to accept contributions and code review from a larger developer community, thereby allowing building a higher-quality product. It is very easy to contribute if you know git. But you can mess it up if you don't know. I made a two-line bugfix patch to flycheck, and heck, I was nearly pasting the patch into a comment in issues because I didn't know anything about how to make a pull request on githu…
I think it's easily fair to say that git is by far the superior option to CVS, and preferring CVS over git is objectively incorrect. I think that you would be wise to invest the time in learning how to use git correctly.
Re: Cross-platform Rust rewrite of the GNU coreutils
#308Earlier quoted context omitted.
I suppose this coreutils impl doesn't do it but one could perhaps use rust w/o its standard library and use strictly some libc instead. Would probably still be a net win.
Writing Rust code interfacing libc is a rather frustrating experience though. Many libc interfaces use constructs that Rust really wants you to avoid (for very good reasons), things such as global mutable variables (errno and for callback functions without context pointers) or union types. I know about at least one cargo crate attempting to "Rustify" libc with some level of success. None the less, this is what I typi…
Personally, I rather enjoy writing clean Rust wrappers for gross C APIs. Doing so does require a solid knowledge of C, and familiarity with a small bag of Rust tricks.
In my experience, the Rust standard library is extremely convenient and it handles corner cases very well. There are definitely still holes, but that's what "cargo add $CRATE_NAME" is for.
My biggest annoyance with Rust (and it's not a huge one) is that if I'm doing something off the beaten path, I'm probably going to need to wrap a C library or two that nobody has wrapped yet. There's a lot of great stuff on crates.io, but it's only a minuscule fraction of the total C ecosystem.
Re: Cross-platform Rust rewrite of the GNU coreutils
#309Earlier quoted context omitted.
Not sure why you're being downvoted. I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code.
> I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code I agree in principal, however the timing is wrong. Rust is a very new language (less than 6 years old), and is undeniably totally unproven. It is the latest "buzz" language, and may not be around long term... nobody knows. What-more, a full-fledged re-write of CoreUtils in…
>Flatly, re-writing a several decade's old, matured codebase in today's flavor-of-the-week language is not a good idea. It's a waste of time and effort.
That's the sort of thinking we'd benefit from having less. Legacy is a terrible burden.
Re: Cross-platform Rust rewrite of the GNU coreutils
#310Earlier quoted context omitted.
No. It's not a derivative work. Creating a compatible piece of software is not copying. Even if you've seen the original code. If you're not literally copying and pasting code, it's fine. Copyright protects the code itself from being copied, but the ideas, abstractions, overall design, and even individual APIs are not eligible for copyright protection
I don't think that is accurate. If your work is derived from the source - even if you don't replicate the original - you're infringing copyright. That's why clean room design is so important.
No, a "derived work" is a legal concept, it means "you copied the original". Being inspired by, or even deliberately designing for API compatibility with an original work is not "derivation" nor is it "copying", as far as copyright law is concerned. Remember only certain portions of the original are eligible for copyright in the first place, e.g. APIs are not, module or class structure is not, ideas are not.
It's important to remember that copyright law protects works from being copied, not from being read. Clean room is a legal tactic used against an aggressive adversary, it's not something that's at all necessary or appropriate in the general case.