What happens when new versions of the dependencies come out that break the code that's found on the source code section? I think it'd be a good idea to include dependencies instead of having the users hunt all over the internet trying to find version X.Y.Z (that they might not be able to)
It's the source code section. Not binaries and libraries supplied section. One needs to compile the SFML source code to use the SFML libraries. The libraries are not compatible between compiler versions, between debug and release builds, or between compilers and certainly not between platforms. That's a lot of cruft you would have to include to keep people from having to visit the place they should already be visiting if they want to use SFML. It would make more sense to me just put it on the SFML wiki where people who are interested in it will be looking for it.
As an aside, SFML 1.6 is outdated, unmaintained and much buggier than the current version. If only Laurent would make that more obvious on the front page of the SFML site, it would quell a lot of confusion from new users.
Any non-trivial project could potentially have dozens of dependencies, any one of which becomes incompatible, invalidates the entire project in respect to the 'new programmers' that will be using it.
A non-trivial project should have a home in the form of a code repository or website somewhere. Linking to it seems more appropriate to me than duplicating it.
...my point is that depending on third parties to a) host project dependencies, and b) maintain project dependencies makes for an extraordinarily fragile system if stability and ease of use are design considerations. What happens if the SFML website goes down tomorrow or the author decides to break some backward compatibility? I'm not saying that it will happen, but if it does, now all of your source code is pretty much useless. Ever try to find a certain version of a library that you need for extending an in-house code-base only to find that the project is now abandonware with a broken link for a website? If only the previous maintainer had kept a copy of it instead of just a link.
I guess that's how the open source world operates, but IMHO it's too sloppy for me to adopt.
If only Laurent would
Yes, if only XXX would YYY, but we are effectively at their mercy.
By the way, this may sound like an attack, but don't take it like that.
You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.
[Q] I use a proprietary compiler toolchain without any parts of GCC to compile my program, and link it with libstdc++. My program itself does not include any runtime library code the same way that GCC-compiled programs include libgcc. Can I still take advantage of the exception?
[A] Yes. While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use.
[Q] What libraries does the GCC Runtime Library Exception cover?
[A] The GCC Runtime Library Exception covers any file that has a notice in its license headers stating that the exception applies. This includes libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov, and other libraries distributed with GCC.