DuetDisplay and Unattributed Open-Source(github.com)
github.com
DuetDisplay and Unattributed Open-Source
https://github.com/deanm/deanm.github.com/blob/master/_posts/2014-12-18-DuetDisplay.markdown
11 comments
It sucks, but this is always the risk when developing on someone else's proprietary platform.
Walled garden issues, to state it more bluntly. You live by the sword, you...
I went ahead and put together a post. Check it out. "Apple, is USB allowed now?"
https://news.ycombinator.com/item?id=8778010
https://news.ycombinator.com/item?id=8778010
https://github.com/rsms/peertalk/commit/5973b1722d3330340c08...
PeerTalk's README was just updated with a note about DuetDisplay.
PeerTalk's README was just updated with a note about DuetDisplay.
It's always possible that they have custom contracts with the creators of these open source projects; CocoaSplit could have offered them a custom license without x264 so that part can be dial-licensed.
I paid for it and have had very little luck in getting it to work properly. I've mailed their support and heard nothing back. I would personally advise people away from giving them money, especially now I know of their lack of crediting open source projects.
On MacRumors [1], the developer responded in a thread and mentioned that its just him, no big team. So, perhaps he's just overwhelmed with customer queries?
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.
[1] http://www.macrumors.com/2014/12/18/duet-display-ipad-tether...
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.
[1] http://www.macrumors.com/2014/12/18/duet-display-ipad-tether...
It works well for me - 30fps is good enough for my needs. Let's hope they clear up their OS credit issue promptly.
It's working fine for me on iPad Air, the iPad 1 version is buggy (dev told me to wait a few days for a fix on Facebook)
it is working flawlessly for me. i am on a mbp watching vimcast core class on a sidecar mounted iPad air and it's chugging away without any stuttering.
Same here.
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.
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.
It works flawlessly for me :-)
Dean (the author of the article) mentioned that several other apps have attempted to use peertalk and other OSS code this app uses but had their app rejected by Apple (e.g. see mronge's comment). So perhaps the lack of attribution was made with the assumption that use of these OSS packages was part of the reason for rejection. If this is not the excuse then I can't imagine any reason for it. Attribution in this form is a simple footnote somewhere and giving credit to others never hurts your own brand. In fact I'd argue it contributes to it.
The CocoaSplit repository does not contain a LICENSE file. Basically this would mean it is unlicensed. However it does mention a license in its credits.rtf page, buried in the project:
" 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.
" 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.
Since the MacOS app is free, does the creator need to do anything but give attribution? Seems like the place to focus on for license issues is the iOS app which costs $10.
As it contains GPLed code, the MacOS app's source code must be distributed or offered for distribution under the GPL to anybody who has a copy of the binary.
Is that true? My understanding is that so long as you clearly segregate GPL and non-GPL code by using wrapper classes and linking (rather than copypasta), the core application can remain non-GPL.
> Is that true? My understanding is that so long as you clearly segregate GPL and non-GPL code by using wrapper classes and linking (rather than copypasta), the core application can remain non-GPL.
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.
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.
Except for OS libraries and similar, distributing two components intended to be runtime-linked together is generally not sufficient separation to be considered "mere aggregation". I would personally not even patch a GPL app to expose a custom API with the intention of using it from a separate non-GPL process; that also seems like it's more than "mere aggregation". (Using an existing / common API seems fine.)
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:
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.
Usually, the litmus test is: Does the software work at all without the GPL'd parts? If not, it doesn't matter how segregated you think it is, because it's still dependent on that GPL'd code.
As an example, consider a video player with a codec plugin system. The player ships with a noop plugin, a proprietary plugin for MPEG-1 video, and a general plugin that leverages GPL code. It is my understanding that the video player can still be non-GPL, but that wrapper to the GPL code must be GPL
This seems exactly analogous to the CLISP/libreadline example I just linked in another comment, where it was agreed that CLISP needs to be under the GPL.
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.)
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.)
If you're distributing them all together, all of it would have to be under the GPL. If you're distributing them separately, otoh, only the GPLed bits would have to be under the GPL.
I don't think that's correct as it is most of the point of the LGPL. I think it's how QT was able to sell licenses to closed source software despite being GPL'd as well (dual license).
Supposedly, the GPL3 is incompatible with the restrictions in Apple's App Store.
The Mac OS version isn't in the app store, but this does make it seem likely their iOS app is using one of the libraries.
CocoaSplit is GPL. Hence, the developer has to release the source code or risk getting sued. I'm looking forward to the OpenSource version of Duet :-)
Doesn't the developer only need to release the source to someone who has purchased (obtained) and used the application, if they ask?
They must release the source to anyone they give a copy of the binaries, which - since the software is free - is anyone who goes to their website and clicks "download."
It's not as simple as "if they ask" - if you choose not to distribute the source code with the binary or provide it for download, you must explicitly provide a written offer valid for 3 years for the source code.
Does including the license in the distribution satisfy the requirement?
I wouldn't think so (you'd need wording like "I agree to distribute source code to you on request to <address>"), but I doubt it's been challenged - it's an obscure use case of the GPL.
Not that obscure; lots of hardware vendors use Linux in their routers/TVs/tablets/phones/etc and distribute the sources separately. In fact, every manufacturer of Android phones should have such an offer included with their device.
Have they done that?
No idea. Have no idea what this software does, why anyone would find it useful, or who is using it.
Can someone educate me a little more on these license issues?
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.
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.
Is it so hard to understand wanting to be credited when someone uses your work?
I think the grandparent was saying that, 'as an OSS author I am not sure I would want every project that used my software to announce it; people will think it an endorsement of some kind'.
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.
BSD's non-endorsement clause comes close to what you want:
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.That is just you. Many who create open-source software and/or hardware do want to see attribution. While it is the right thing to do it is also important to adhere to the license under which it is distributed.
Duet Display twitter account responded that "[The omission of the attribution was] an oversight of rushing to get in the App Store before lockout" and "All projects we used were cleared for use."
https://twitter.com/duetdisplay/status/546676103645896704 https://twitter.com/duetdisplay/status/546709659457826816
https://twitter.com/duetdisplay/status/546676103645896704 https://twitter.com/duetdisplay/status/546709659457826816
The only real way to fix this situation is to threaten some type of legal action to enforce your copyright or your licence is really meaningless.
Not taking sides one way or the other but:
- 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.
- 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.
What sort of argument is that? If the Duet Display author wasn't able to find the GPL license for CocoaSplit, how could he assume that the code was available for any use? Furthermore, the ISC and BSD licenses of PeerTalk and GPUImage are rather permissive, yes, but they do require attribution that is not given by Duet Display.
The big deal here is that licenses matter, especially when you're profiting from others' work.
The big deal here is that licenses matter, especially when you're profiting from others' work.
> And who amongst us has grepped for a license?
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": https://tracker.debian.org/media/packages/p/prelink/copyrigh...
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. https://www.blackducksoftware.com/
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": https://tracker.debian.org/media/packages/p/prelink/copyrigh...
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. https://www.blackducksoftware.com/
The source headers say it's copyright and all rights reserved. Even without this notice you would have to presume a full copyright.
If there's no license then you can't incorporate the code at all. "It's hard to find the license" is not an argument. If you can't find it then you have to assume you can't use it.
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.