5,231 karma · joined June 16, 2011
c in 2^64 = 1.625 × 10-11 m/s; width of a hydrogen atom: 2.50 ^10-11 m
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
It is very unlikely that this story is anything more than a fanciful tale: The dedicatee of the piece is unknown; the work was found in papers long after Beethoven's death and was unknown before that. So, the prospect of there being someone who was told the story and wrote it down, even though it's recorded nowhere is close to nil. See the Wikipedia article for more details.
This the first time I've seen this view of GitHub, and I'm struggling to figure out what specifically he's referring to.
However, I agree that if they view their new mission to be "selling themselves" to one side or the other, that would indeed detract from my willingness to continue supporting them long-term.
I'm not sure what distinction you're trying to make. The very first line of the AGPL reads: "The GNU Affero General Public License is a free, copyleft license". And from the FSF's own site: "The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement..." [0]
Google is the company that initiated the whole movement against the GPL and the AGPL. I was in touch with their OSS guru, Chris diBona at the time. Also, Bruno Lowagie's book "Entreprenerd" gives some more details about this initiative.
In short, Google were caught in violation of the GPL's copyleft terms and decided that they could not be caught in violation again on any of their principal technologies. So they started a very public campaign to strip the GPL from the company and because they are so reliant on OSS, to dissuade OSS developers from using the GPL (and by extension the AGPL). At the time, the GPL was, depending on survey the #1 or #2 license in OSS.
However, contrary to their public position, Google still uses GPL products widely inside the company. Linux and Java, for example, are both licensed under the GPL and used extensively at Google. And the parts of Android that are based on Linux are licensed under the GPL [0].
Note that all major companies that sell licenses to their OSS use the GPL or AGPL licenses. This is because the copyleft provision provides OSS developers with leverage ("Either open-source your app if you use our product for free or buy a license.") This is what Google does not want to do. None of the more permissive licenses give developers this leverage: under MIT, Apache, and the other licenses, the developer gives up the GPL's copyleft leverage.
Some companies have followed Google's lead and used scanning tools to eliminate GPL/AGPL code from their codebases. This is in part due to the copyleft provision and also to the so-called "viral clause" (if any part of the software is GPL/AGPL, the rest of the software it's part of must also be GPL/AGPL). This makes a lot of sense.
However, for developers of stand-alone tools, the GPL is a good option and much less disfavored in corporate contexts (as evidenced by the widespread use of Linux, Java, MySQL, etc. in corporations) and the GPL license provides OSS developers a possible monetary stream from companies that want to modify the tool without disclosing the source code.
Personal note: all of my OSS projects are released under permissive, non-GPL licenses because I'm not looking to make a business out of them and I want the widest possible distribution. Here, I simply want to provide context to the OP and clarify that it should be seen in the context of a long campaign by Google to dissuade OSS developers from the GPL/AGPL and to point out that those licenses have benefits for projects looking to pursue a business model based on licensing.
If so, what more compelling reason could there be to go migrate right away to Dropbox (or a similar service)?
Well, for one, because it's an exceptionally rare English word that is singular in meaning but plural in its usage. In addition, there is an unrelated English word that is singular in both meaning and construction. That confusion would naturally arise seems almost pre-ordained.
It's amazing how this POV lives on, even in an essay which decries technical debt. Documentation and well-written code fill different roles with only some overlap. Your code can be beautifully written, but if I need to read the whole 500+ lines to figure out what you're doing, rather than read a single paragraph at the top of the file, you've burned through a lot of my time. Good documentation explains the why, code explains the how.