Project discussion: "NVIDIA Gamestream in Kodi"

  Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
garbear Offline
Team-Kodi Developer
Posts: 1,750
Joined: Dec 2010
Reputation: 112
Location: city of angels
Post: #16
(2015-03-09 12:03)gazben Wrote:  This idea misses all of the licence problems above, of course if we come up with another solution, and we have to add it as a binary addon. The binary addon solution would be much slower because of Java I think.

Licensing isn't as much of an issue anymore with binary add-ons. Most emulators have strict non-commercial licenses, but their code is separate from ours.

and check out the game ideas thread i just posted in the gsoc 15 subforum
find quote
RockerC Offline
Posting Freak
Posts: 1,485
Joined: May 2011
Reputation: 28
Post: #17
(2015-03-09 12:03)gazben Wrote:  I think my project would be: Study the Limelight C implementation. Port the Java code to C++ (if I can contact the developer of the project, I don't think this will be an issue). the porting has to be done in Kodi's framework to not add more overhead. Add the code to the retroplayer as an addon.

This idea misses all of the licence problems above, of course if we come up with another solution, and we have to add it as a binary addon. The binary addon solution would be much slower because of Java I think.
acmiyaguchi wrote: I was also interested in this project and have been taking a look at this in the last week. The language of the official Limelight client doesn't matter too much, since all the code would have to be ported over to use Kodi's interfaces anyways. The actual GameStream protocol has an implementation in C for their iOS and Windows phone projects as mentioned by RockerC, so I believe the majority of the work will be creating the client addon for Kodi.

Again, look closer into https://github.com/limelight-stream/limelight-common-c

Doing some more research I think that acmiyaguchi got the right idea here. Forget about the existing official Limelight clients that are written in Java. Instead only use the Limelight-common-c code in order to get the protocol code in C implemented into library used by a C++ GameStream Game Client as a new binary addon for RetroPlayer using the Game API, thus similar to to the libretro wrapper? So you do not need to port the Java code per say, but you probably do need to replicate parts its function as part of that C++ GameStream Game Client if not everything needed is contained with the Limelight-common-c code.

[Image: RetroPlayerTransparent_zps0b966969.png]
find quote
un1versal Offline
Out of Memory (1939–2016)
Posts: 7,134
Joined: Oct 2012
Location: Binary Pulsar
Post: #18
By the way, I read by a couple of people that claim gplv3 and v2 are compatible.

Please read https://www.gnu.org/licenses/gpl-faq.htm...patibility

Its clearly states it is not.

However stating "GPL “version 2 or later" on the relevant parts for the gplv2 program that contains 3rd party libs which are gplv3, seems to cure the issues with licenses and distribution of said code. Provide that upon distribution or conveyance that each are distributed in accordance with their versions. Or so it seems.

I point to any Ubuntu OS as perfect example of coexistence in harmony and in accordance to each license type, Where its one license under one license (because their code is and contains a gazillions different libraries that in a whole are part of the the OS and without some it would have specified functionality. They clarify with http://www.ubuntu.com/about/about-ubuntu/licensing

Kodi is a much smaller project in comparison, and imo its development present and future shouldn’t be restricted by what some Hardware vendors prefer or by confusion, or by license versions.

Also the main license for kodi https://github.com/xbmc/xbmc/blob/master/LICENSE.GPL#L3 should specify "GPLv2 or later" if it contains/distributes source/binaries for any 3rd party libs that are gplv3

I see no issues with kodi code being gplv2, including parts of its source where it makes it work with 3rd party libs that for e.g would be gplv3 and coexisting perfectly alight in accordance with both licensing without requiring any impromptu license upgrades.

I researched and corresponded with FSF and discussed this for a much smaller project which conforms perfectly with both. The GPL faq is a great source of clear and concise information for instance.
(This post was last modified: 2015-04-15 13:18 by un1versal.)
find quote
garbear Offline
Team-Kodi Developer
Posts: 1,750
Joined: Dec 2010
Reputation: 112
Location: city of angels
Post: #19
gpl v3 is the least of our worries. most emulators are straight-up noncommercial which is as gplv2-incompatible as you can get. this just means that they have to be distributed as a "separate work" and can't be bundled with Kodi. Which is why one of the first RetroPlayer features I ever implemented was just-in-time installation. License incompatibility has been built into RetroPlayer from day 1, so I don't think there's anything to be worried about.
find quote
un1versal Offline
Out of Memory (1939–2016)
Posts: 7,134
Joined: Oct 2012
Location: Binary Pulsar
Post: #20
Im sure it will work just wonderfully well none the less.
find quote
cgutman Offline
Junior Member
Posts: 3
Joined: Mar 2015
Reputation: 2
Post: #21
If licensing becomes a problem, I can relicense/dual-license limelight-common-c. Other than some comments and build files, I don't think anyone else has contributed code to that repo.
find quote
natethomas Offline
XBMC Chief and Kodi Project Manager
Posts: 6,233
Joined: Apr 2008
Reputation: 128
Location: Kansas
Post: #22
(2015-04-17 05:25)cgutman Wrote:  If licensing becomes a problem, I can relicense/dual-license limelight-common-c. Other than some comments and build files, I don't think anyone else has contributed code to that repo.

It probably won't. Licensing is mostly an issue if the person whose license we're using objects to how we use it. For this reason we pretty carefully spoke with the people at SAMBA for a possible switch to the current GPL3 version of samba on Android, since Android has weird signing requirements that could be interpreted as not necessarily working well with the GPL. If you are the author with the license, and you give your blessing to use your software, and the GPL compatibility seems probably good enough, then for IRL purposes, everything should be fine.
find quote
RockerC Offline
Posting Freak
Posts: 1,485
Joined: May 2011
Reputation: 28
Post: #23
(2015-04-17 05:25)cgutman Wrote:  If licensing becomes a problem, I can relicense/dual-license limelight-common-c. Other than some comments and build files, I don't think anyone else has contributed code to that repo.
Sure would not hurt if upstream re-licensed the limelight-common-c code parts to GPLv2+ regardless, as that might make more downstream projects use it and contribute code upstream.

Or dual-license the the limelight-common-c code parts as GPLv2 and GPLv3 as you said.

Another option is LGPLv2+, or dual-license as LGPLv2+ and LGPLv3+ for even higher compatibility.

GPLv2+ = "GNU GPL version 2 or any later version", and LGPLv2+ = "GNU Lesser GPL version 2.1 (LGPLv2.1) or any later version", see:

http://www.gnu.org/licenses/gpl-2.0.html
https://www.gnu.org/licenses/lgpl-2.1.html
http://www.gnu.org/prep/maintain/maintai...U-Packages
(This post was last modified: 2015-04-17 09:17 by RockerC.)
find quote
Post Reply