One interesting implication is that since people can view and modify the source code, patches and modifications to the software are shared.
This has always lead me to wonder if a diff file violates copyright as it includes some of the original source as context.
My understanding is that use a patch file as long as your patch doesn't include any copyrighted material it is fair to share.
A patch file does not necessarily have any of the original code, just the location info and the new value.
It's one of those problems that are solved only at the individual level but because of that are not going to be solved at all.
Copyright law can still apply. Just because I have your sources doesn't mean I can go and use them in my own software, or re-implement your patented algorithm.
"But how can I be sure that my customer isn't stealing my work?"
Well, ask someone to look at the source code they provide to their customers. Remember, we're in an imaginary world where source-included is the normal way to sell software, and anyone peddling binary blobs is seen as shady.
1. Obfuscated code. This is a classic, employed back in the day when raw machine code wasn’t quite as much of a barrier like it is nowadays. Less common now since its importance has lessened, but still ever-present, and could be re-employed instantly.
2. The very design of the software. For instance, the software might require a phone number for every user, and this is baked in at the very fundamental design level, making it impractical to change. Other design choices might encourage you to share your contact lists, for say, backups, and your data is now leaked.
3. The software is merely a collection stubs calling a cloud service. Very common now with so-called "apps" for phones. This design has come to its pinnacle with “web page apps”, where only the front-facing UI portion sits on the user‘s control, and the rest runs remotely.
This is why “shared source” and the like is not enough. The end user must have the practical ability to, reasonably easily change the software, either by themselves or by hiring anyone they like and/or trust to do it for them.
But, to your point -- yes, companies can do altruistic things. That doesn't mean they always do altruistic things, nor does it mean that they tend to do altruistic things. This should not be surprising -- companies are designed to maximise profit and altruism is rarely as profitable as other avenues. Companies which contribute to or sell free software are in the overwhelming minority today, let alone 30 years ago.
I didn't mention socialism, nor redistribution of assets. More importantly though, if you feel the need to protect the concept of capitalism whenever there is even the hint of criticism, then you should take a page out of Hamlet -- "the lady doth protest too much, methinks".
Also, free software isn't socialist. If you feel the need to tie to it a political ideology, it's much closer to anarchism.
It technically isn't, much like having an excavator isn't essential to digging up ground for a new mall, when you can technically do this with a shovel too.
I get your point, but right now, I'm sitting in front of a 22-years-old game I spent a great deal of time even trying to get to run. I want to restore it. There's no source leak of it that I know of, it has no clear relation to prior titles and there wasn't any reversing effort I could find either. Half of the formats used by it are obscure, and from causal inspection seem to be dumps of in-memory structures.
Having source code, my main problem would be to build it - but it's essentially a straightforward task of finding and patching or mocking various 1990s-era peculiarities, until the whole thing builds correctly with an reasonably current compiler. The source code would assist me with reversing the data formats too. However, I don't have the source code, just a barely-32bit application with a 16bit installer. The game plays really weird tricks with your screen, so attaching a debugger will be a PITA (unless I figure out how I can run a debugger on a different machine and remotely debug the game on the one computer that it manages to run in half-broken fullscreen mode). Best I can do now is poke it and see what changes.
> It could even be argued that the rise of open-source lead to a decrease in interest and skills of RE.
I think so too - simply because being able to ask decreases interest in and skills of figuring stuff out yourself. Has its good and bad sides.
Two suggestions for you: 1, VMs are your friend. 2, decompilation technology has gotten very good. I'd "statically analyse" the binary in a disassembler/decompiler for a while first and figure out what it's doing before actually trying to run it.
I don't think source is necessarily always making things easier either --- I've had a few times where, even with open-source software, it's easier to find the right bytes in the binary to patch than to figure out where in the (huge) source that would be, and then how to build the rest of it (along with all its hairy web of dependencies) completely unmodified from the original binary.
Especially if it's a fundamentally trivial change (like a string constant somewhere, whose desired value is the same or smaller in size), and I don't expect to make any more complex changes, I'll definitely choose opening the hex editor for a few minutes (at most) over spending perhaps hours downloading a few hundred MB of source and dependencies and figuring out how the original was built and how to reproduce that.
You're right that it's not essential -- and he does mention this in most of his talks. But reverse engineering is very time-consuming and difficult, especially if you need to do it for every program you use.
So his view that software freedom requires the source code to be available to users is much more of a practical requirement than a philosophical one. This is why the GPL requires the preferred form of modifying the program be provided -- to ensure it's just as easy for users to modify the program as it is for the developers.
Most EULA's prohibit Reverse Engineering and companies like Oracle have entire legal teams dedicated to prohibiting reverse engineering going as far as prohibiting people from reporting security vulnerabilities discovered using "reverse engineering techniques"
Further the wide interpretation the courts have allowed under CFAA can easily be applied to reverse engineering as well, i.e "Exceeding authorized use" making reverse engineering of software a felony under US Law
The alternative to working on favorably licensed OSS that you posit, is roundly illegal, unless you had no designs on modification and/or redistribution of a derivative work.
In fact, PC magazines of the 80s and early 90s used to contain articles specifically about patching software to do interesting things, complete with instructions of the form "change byte at X to Y"; AFAIK they didn't violate any copyrights because they didn't distribute copyrighted material. Then there's the whole series of "undocumented DOS/Windows" books written by people like Matt Pietrek, Andrew Schulman, and Mark Russinovich; all of which required substantial amounts of reverse-engineering and analysis, but instead of them being persecuted, two of them now work at Microsoft.
"If you outlaw freedom, only outlaws will have freedom."