Too restrictive. People should be able to make money from stuff.
The definition of "commercial" could also be taken in extremely broad senses, making serious reuse risky in many applications.
Notably, many university courses use it, notably MIT OpenCourseWare. Ciro wonders if it is because academics are wary of industry, or if they want to make money from it themselves. This reminds Ciro of a documentary he watched about the origins of one an early web browsers in some American university. And then that university wanted to retain copyright to make money from it. But the PhDs made a separate company nonetheless. And someone from the company rightly said something along the lines of:TODO source.
The goal of universities is to help create companies and to give back to society like that. Not to try and make money from inventions.
The GNU project does not like it either www.gnu.org/licenses/license-list.en.html#CC-BY-NC:
en.wikipedia.org/wiki/Creative_Commons_NonCommercial_license#Defining_%22Noncommercial%22 also talks about the obvious confusion this generates: nobody can agree what counts as commercial or not!
In September 2009 Creative Commons published a report titled, "Defining 'Noncommercial'". The report featured survey data, analysis, and expert opinions on what "noncommercial" means, how it applied to contemporary media, and how people who share media interpret the term. The report found that in some aspects there was public agreement on the meaning of "noncommercial", but for other aspects, there is wide variation in expectation of what the term means.
Cloud Computing market share in Q2 2022 by statista.com
. Source. If you are going to do closed source, at least do it like this.
Basically the opposite of need to know for software.
New developers won't want to learn your project, because they would rather shoot themselves.
Of course, at some point software gets large enough that things won't fit anymore in 5 seconds. But then you must have either some kind of build caching, or options to do partial builds/tests that will bring things down to that 5 second mark.
A slow build from scratch will mean that your continuous integration costs a lot, money that could be invested in a new developer!
One anecdote comes to mind. Ciro Santilli was trying to debug something, and more experience colleague came over.
To reproduce a problem, ciro was running one command, wait 5 seconds, run a second command, wait 5 seconds, run a third command:
cmd1
# wait 5 seconds
cmd2
# wait 5 seconds
cmd3The first thing the colleague said: join those three commands into one:And so, Ciro was enlightened.
cmd1;cmd2;cmd3
The software engineer phrasing of simplicity is the ultimate sophistication.
Like all other principles, it is not absolute.
But it is something that you should always have on the back of your mind.
You aren't gonna need it is closely related, as generally the extra unnecessary complications are set in place to accommodate useless features that will never be needed.
Working remotely is hard if you don't already highly master the software and enterprise systems used.
Also you don't feel people's love as strongly, and usefulness is built on love, see also Steve Jobs's Pixar office space design philosophy.
But please, give workers a small silent office so that we can concentrate instead of a silly open space, and create an internal social network so people can see what others are doing.
Remote working is much better if the majority of the team also does it, otherwise you will get excluded. Maybe after VR...
Political division:
- nominal leader: British monarch
- toplevel arch-dioceses/provinces of Cantebury and York. One archbishop each, who is also bishop of Cantebury and York diocese
- within provinces: one cathedral and bishop per diocese
If something does a quantum jump, what causes it to decide doing so at a particular time and not another? It is expected that a continuous cause would have continuous effects.
This concern was raised immediately by Rutherford while reviewing the Bohr model in 1913 as mentioned in The Quantum Story by Jim Baggott (2011) page 32.
Unlisted articles are being shown, click here to show only listed articles.