> That's the first type I think. The second type is the more HN-style professional programmer.
nah
> As a small P.S. to this, I think the middle ground is using the GPL for actual end-user applications, but leaving libraries and developer tools completely open with something like Apache-2.0 or MIT.
Thats closer. Non-reciprocal licenses are fine for projects that provide no value themselves. But for everything that provides direct value, reciprocal licenses like MPLv2 or GPL are better suited.
Even with the "Crazy Ideas" there currently is no reason to assume they would be blocked from being implemented, if only the resources for that were available. So, once the hard part of finding the resources for them is solved, why should one not put them on LO right away -- which is a much better maintained and stable base than the aging AOO?
> That's basically quibbling, though the OP did err in his history a bit. AOO existed before that point too, it just wasn't called AOO and it wasn't part of Apache; it was run by Oracle, and before that, Sun.
So OOo had:
1/ a different governance
2/ different copyright owners
3/ a different license
4/ different sponsors
5/ different contributors
6/ a different name
than AOO, but other than that it was totally the same?
"Other than that" being "own the trademark" here and only that. Just for fun, AOO didnt even use the trademarked term itself.
... as we would have needed for CMake or Autotools. It might have worked with the former for something as complex as LibreOffice, but GNU make being so simple/basic and stable over the years was a big plus: Im sure even with CMake LibreOffice would have had fun with lots of small cornercase regressions.
Even at the time of donation, LibreOffice had already gained a substantial set of the former Sun/Oracle developers: Stephan Bergmann (to Red Hat), Bjoern Michaelsen (to Canonical), Eike Rathke (to RedHat), Michael Stahl (to Red Hat).
Together with other former Sun developers like e.g. Thorsten Behrens and Caolán McNamara, LibreOffice had more of the old Sun developers than Apache OpenOffice had at any point in time. Incidentally, they also made a lot of contributions that allowed LibreOffice to strife past other derivatives: like build system cleanup, static code analysis and fuzzing, bibisecting.
The LibreOffice build system (which is plain GNU Make, without generated unreadable intermediate build files) does all these and more. Doing the same with autotools would be a nightmare.