In the example source code that Apple gives to developers, they put licensing terms at the beginning of every file. As I read them, the terms essentially say: "You may redistribute this file without modification, but only if you leave these licensing terms in the file."
Isn't that a tautology? If I share the file without modification, then the licensing terms are already in the file. If I remove the licensing terms from the file, then it's no longer "without modification", and I am then free to share the file sans licensing terms. That's what I would naively think. Does the law include a rule of some kind to avoid this circularity?
Here's the language as it appears in every source file (excerpted, emphasis added):
In consideration of your agreement to abide by the following terms, and subject to these terms, Apple grants you a personal, non-exclusive license, under Apple's copyrights in this original Apple software (the "Apple Software"), to use, reproduce, modify and redistribute the Apple Software, with or without modifications, in source and/or binary forms; provided that if you redistribute the Apple Software in its entirety and without modifications, you must retain this notice and the following text and disclaimers in all such redistributions of the Apple Software.
Here's the reason I ask. I've been looking at a particular Apple example, and I felt compelled to fiddle with it. I applied my coding style, edited the comments, renamed things (including the project itself), added a delegate protocol, and fiddled with the UI. I feel the result is better than the original; maybe not hugely, but enough that I want to make the modified code publicly available.
I did this once before with an ancient example project called "Moriarity". At that time I removed the duplicated licensing terms from all the source files and put them in an accompanying file called LICENSE.txt. (Come to think of it, the legalese above makes more sense when the licensing terms are in their own file.) Now I'm wondering if that was really necessary. If not, then I'd rather not include a pointless license file with the project. Or rather, I'd rather include my licensing terms, which are that you're free to use my changes however you want, with or without attribution. Of course, I'd mention that the code is derived from an Apple example.
There are a couple of other issues that make me hesitate. For one thing, this is one of the example projects from WWDC, which means you need a developer login to get the original version from Apple. I'm not too worried about this, because this example is Mac-only, and unlike the iOS 6 SDK, the 10.8 SDK is now public. [Update: This example project is now public, and actually had been for a few days already when I wrote this post. It's the "Scene Kit Document Viewer" project I mention here.]
The other issue is that the example project includes artwork — a 3D model in a .dae file — that clearly belongs to Apple. I'd like to use this model, but I suppose if I had to I could find a public domain one to replace it with.
I'm probably worrying way too much about this, especially given how tiny the code in question is. I'm going to go out on a limb and guess that Apple has bigger legal fish to fry regarding people copying stuff. I should probably go ahead and publish my version of the code, and just decide: either include Apple's licensing terms just in case, or leave them out on the forgiveness-rather-than-permission principle. What's Apple going to do, get me in trouble for writing the exact code they advise us to write?




Now I can look up NSNull in AppKiDo the same way as I did in Dash, by selecting text and hitting a key. This assumes AppKiDo has a browser window open and frontmost, but for me that's always the case.
To search AppKiDo-for-iPhone, you'd need a separate hotkey.
If you want to get technical, AppKiDo doesn't show the whole docs page, only one part of it at a time. To see the whole HTML page, and thus appreciate its zen-ness, you'd have to right-click and select "Open Page in Browser". And then you'd have to dismiss a dialog in Safari because that file is quarantined. So now we're talking maybe five seconds. Dash wins handily at displaying the whole page.
## The YoruFukurou problem
While testing my "Look up in AppKiDo" shortcut, I discovered that YoruFukurou doesn't support the "Use Selection for Find" operation. It bugged me to have this edge case, so I created a variant of the shortcut just for YoruFukurou:
This uses the fact that AppKiDo can be scripted to do a search. I also use Keyboard Maestro's ability to have a keyboard shortcut do different things depending on which application is active, so I don't have to remember a separate shortcut for the YoruFukurou case.
The reason I don't use this approach in all cases is that Command-C blows away the contents of the copy-paste pasteboard, whereas Command-E uses a different pasteboard.
## "Look up in Xcode"
Finally, just for grins, I thought I'd do a similar shortcut for doing the search in Xcode. Xcode is very slow at searching the documentation, but it's useful for doing full-text searches of the complete documentation, as opposed to searching only the API reference docs based on the name of the API symbol.
This shortcut uses the fact that in Xcode, hitting Shift-Option-Command-/ (aka Option-Command-?) always causes the doc window to be open with the Search field selected.
* Type Command-C to copy the desired search string into the clipboard.
* Activate Xcode.
* Type Shift-Option-Command-/ to bring up the doc window, and Command-V to paste the search string into the search field.
Note that *within* Xcode there's already a shortcut for searching the docs for the selected text: Control-Option-Command-/ (last item in the Help menu).