About a year ago we submitted an app to the App Store that uses the same USB tech (PeerTalk), we wanted to see if Apple would allow it (we didn't want to build a business around something that could change on a whim). If it was allowed that would have changed the entire direction of our development. An Apple rep called us and informed as that USB access is not allowed.
With this in mind we went ahead with using WiFi, which has been HARD and time consuming. Now Apple all of a sudden allows USB access, what?!
How does Apple expect people to build serious apps when the ground is shifting beneath our feet?
Anyway.. I should write a post with more details.
PeerTalk's README was just updated with a note about DuetDisplay.
That said, Duet works well on my 13" Early 2011 MBP and a iPad Mini Retina, normal resolution. Retina resolution bumps up the cpu utilization. Duet does not work so well with the same machine connected to an iPad 3, but still usable. Duet does NOT work with 10.10.2 BETA according to the MacRumors thread. Hoping for updates.
It caused one graphical hang on my Mac and then it opened too many file descriptors, reaching the system limitations and I had to uninstall it and reboot.
The inclusion of x264 requires this software is licensed in a GPL compatible way. I'm fairly apathetic about software licensing, so to make everyone's life easy (but mostly mine) CocoaSplit is licensed under GPLv2.
Considering the apathy of CocoaSplit if there is going to be an aggrieved party here it will be authors of x264.
Sort of. If you license your main source code under, say, the MIT license, you can distribute that source code, and any object code compiled from it, under the terms of the MIT license.
However, once you distribute a binary containing that source code and some GPLed source code linked together, you have to distribute all that source code (including any other libraries) under GPL-compatible licenses, such that the user can compile and distribute the application themselves.
The LGPL allows you to keep your main source code closed-source while using an LGPLed shared library, so long as a user can replace the shared library with their own version.
See the discussion of libnoreadline.a in this email exchange: http://clisp.cvs.sourceforge.net/viewvc/clisp/clisp/doc/Why-...
and specifically Steve Jobs asking Richard Stallman if he could avoid having the Objective-C compiler be under GPL:
I say this based on discussions I had with our lawyer long ago. The
issue first arose when NeXT proposed to distribute a modified GCC in
two parts and let the user link them. Jobs asked me whether this was
lawful. It seemed to me at the time that it was, following reasoning
like what you are using; but since the result was very undesirable for
free software, I said I would have to ask the lawyer.
What the lawyer said surprised me; he said that judges would consider
such schemes to be "subterfuges" and would be very harsh toward
them. He said a judge would ask whether it is "really" one program,
rather than how it is labeled.
The situation is, probably, a bit different if the video player authors have no intention of using GPL code and just develop an interface, and someone else unrelated comes along and writes a GPL plugin. But if the app's authors ship the GPL plugin or worse write it, they're on shaky ground.
(This gets you into some slightly silly situations where author A writes GPL software A linking software B, software B can make use of a GPL-incompatible library C, all of A, B, and C can legally redistribute their software on their own, but Debian has to make sure A doesn't link C because they're shipping the whole thing.)
What actual benefit is derived by an open source project when they are credited somewhere deep in an about page? Is tangible value provided there?
I feel that if I had produced an open source library, I'd be less interested in having my name anywhere near a project that I didn't actually produce. But I have little practical experience with such things.
BSD's non-endorsement clause comes close to what you want:
Neither the name of the <organization> nor the names of its
contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
- CocoaSplit's licensing isn't anywhere BUT in the credits.rtf which is buried. It's not in any of the source headers, not in the README.md. If you aren't using the app part of CocoaSplit, you would never know it was there unless you grep'd. And who amongst us has grepped for a license?
- PeerTalk and GPUImage are permissive licenses that only require attribution
I don't see what the big deal is, to be honest.
The big deal here is that licenses matter, especially when you're profiting from others' work.
Try packaging some software for Debian and you'll do a lot of grepping because Debian cares deeply about complying with the law. I've also poked Red Hat's lawyers to get some kernel code from GPLv2 to GPLv2+ because I wanted to reuse it in GPLv3 software, etc. If you're following the law, you're grepping for licenses. If you or your employer don't care about complying with the law, you're welcome to take that risk.
Here's the results of all the grepping I did for a Debian package recently, and this was relatively straightforward as software goes. Note the lines that start "Comment":
If you don't have the explicit right to reuse a piece of code, you can't assume you do. If you don't like this, get your lawmakers to remove your country from the Berne Convention. Or you can risk breaking the law and hope nobody notices; up to you.
It might be telling that there's an entire _company_ dedicated to grepping for licenses as a service, because people don't do so and then they get in trouble.