
DuetDisplay and Unattributed Open-Source - cyphunk
https://github.com/deanm/deanm.github.com/blob/master/_posts/2014-12-18-DuetDisplay.markdown
======
mronge
We've been developing app that also streams video content from Mac to iPad,
and this recent Apple reversal on USB has been very frustrating for us.

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.

~~~
hugs
It sucks, but this is always the risk when developing on someone else's
proprietary platform.

------
beltex
[https://github.com/rsms/peertalk/commit/5973b1722d3330340c08...](https://github.com/rsms/peertalk/commit/5973b1722d3330340c08c87c81d2e66f34299a8a)

PeerTalk's README was just updated with a note about DuetDisplay.

------
steipete
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.

------
christoph
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.

~~~
mstolpm
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...](http://www.macrumors.com/2014/12/18/duet-display-ipad-tethered/)

------
cyphunk
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.

------
jeremyjh
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.

------
codezero
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.

~~~
vertex-four
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.

~~~
sheetjs
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.

~~~
hugs
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.

~~~
sheetjs
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

~~~
geofft
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.)

------
colinbartlett
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.

~~~
rcthompson
Is it so hard to understand wanting to be credited when someone uses your
work?

~~~
codezero
If licenses were just about getting credit for your work, they'd be a lot less
complicated :)

~~~
Sephr
Hence the simplicity of the MIT license, which is mostly just about getting
credit for your work.

------
kiding
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/546676103645896704)
[https://twitter.com/duetdisplay/status/546709659457826816](https://twitter.com/duetdisplay/status/546709659457826816)

------
zitterbewegung
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.

------
jawngee
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.

~~~
the_imp
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.

