[Koying]

What about the Kodi name being Trademark ?

Yep, unrelated to GPL but they are violating Kodi's trademark if they actually call their product "Vidon Kodi".
The sources also still use "org.xbmc.kodi" as the package name, which is big, big no-go.

[Wolly]

That was committed on 3 Feb 2015, in the release version, we never used VidOn Kodi as the app name, we use VidOn XBMC.
And our package name now is org.vidonme.xbmc.
We will change that file asap.

[Koying]

@Wolly Please be careful. The published sources must be the ones used to build your release product, or you are actually violating the GPL.
Please also address the issue of the binary dynamic libraries or their sources, so that anyone can rebuild "VidOn XBMC" from the sources you provide.

Thanks

[movie78]

Interesting!!!

[MrMC]

GPLv2 code calling non-GPL libs.

If system lib, ok. system libs are exempt. This can also depend on what you call a system lib I call libs that are installed on the distro (firmware), a system lib. Any lib that is carried by the actual install, is not a system lib.

If non-system, then you get into the 'passing complex data structures' which can become vague and meaningless depending on the point of view of 'complex'.

When in doubt, I tend to look to the intent of GPLv2 , 1) source code changes public and 2) you can build and run it. If those pass, then there is no GPLv2 issue worth pursuing. If you review ALL the legal cases that have involved GPLv2 (and I have) 1 and 2 are the prime points of contention.

If they are using the samba GPLv3 lib, then the entire app becomes GLPv3 and that is a totally different world of hurt.

[RockerC]

Why don't anyone of you just follow the posted links and read the GPL FAQ at gnu.org as it explains all of this and why VidON is in the wrong here?

[EDIT]: At least MrMC have clearly read the GPL FAQ and understood the hard edges as well as the loopholes. But it is clear that VidOn has not.

From a quick look at the sources, vidon calling libraries from inside Kodi, not actual external player.

Yes and it being an "internal player" by deffinition means that VidOn has to release their full player source code under a GPL compatible license. It does not have GPL but as long as it is an "internal player" then its source code has to released under a a GPL compatible open source license. Otherwise they would have to change their design to use a true "external player" instead, meaning that they would loose the seamless integration with Kodi.

Now, I'm surely not a GPL specialist, but saying that a lib called from a GPL app must be GPL just seems BS to me.
It's true for an app that CALLS a GPL lib (unless it's LGPL), iirc, but not the contrary, that just doesn't make sense.

Sorry to inform you that you are completely wrong here and you have totally misunderstood the GPL. It does make sense under the "combined work" concept which is one of the main ideas that the GPL covers. Otherwise you have to use the LGPL (Lesser GPL) license or a other license or add additional exceptions and except permissions beyond the GPL.

Please follow and read the previously links to the GPL FAQs. I think that you will find the GPL license far more restrictive then you might have thought at first. Libraries called from an GPL application must indeed either be fully GPL compliant or you must have written in additional exceptions into the source code license that give express permission to not follow the GPL in specific cases. And no, using a wrapper in for a proprietary module is not allowed either, so such workarounds are not allowed are still illegal as per the GPL. Read:

http://www.gnu.org/licenses/gpl-faq.html...uleLicense
http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs
http://www.gnu.org/licenses/gpl-faq.html...atibleLibs
http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic
http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic
http://www.gnu.org/licenses/gpl-faq.html...tarySystem
http://www.gnu.org/licenses/gpl-faq.html#SwitchToLGPL

That would just mean that no GPL app could run on windows unless Microsoft open-source all Windows system dll

That is not the same at all and shouldn't have to be explains as you are now you comparing apples and gorillas. Apps can use closed source "system libraries" which are covered under a GPL exception, read:

http://www.gnu.org/licenses/gpl-faq.html...yException
http://www.gnu.org/licenses/gpl-faq.html...timeAndGPL

Rocker I am slightly confused on your stance that they cant have an internal player. As we dont have the code lets say they modify dvdplayer and release that which from github it looks like they did but then they link into a binary blob that is closed source by GPL rules this is not a violation as long as they have given the source for the modified code that links into the binary blob. Its a grey area for sure and undermines GPL but it is not a violation of GPL. As this is the same way Nvidia and other companies handle their linux drivers. Open source the linking into the kernel but keep the binary blob closed.

The Linux kernel is a binary blob drivers and modules is a whole separate discussion that we should not have here. Let's just in summery say that there are loopholes in place in the GPLv2 license to allow the usage of binary blob drivers and modules if packaged as "system libraries" or GCC Runtime Library. See http://www.gnu.org/licenses/gpl-faq.html...ernelLinux and http://www.gnu.org/licenses/gpl-faq.html...CException

[wrxtasy]

Are are we dealing with Static or Dynamically linked libs or modules (into XBMC) with VidOn's Core player ?

[RockerC]

Are are we dealing with Static or Dynamically linked libs or modules (into XBMC) with VidOn's Core player ?

FYI; that doesn't matter for GPL, only for LGPL. Again read the GPL FAQ:

http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic
and
http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic

Kodi as a combined work is covered under the GPL license, not LGPL, so:

http://www.gnu.org/licenses/gpl-faq.html...cVsDynamic

Question: Does the GPL have different requirements for statically vs dynamically linked modules with a covered work? (#GPLStaticVsDynamic)

Answer: No. Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination. See also What legal issues come up if I use GPL-incompatible libraries with GPL software?

[Koying]

Sorry to inform you that you are complete wrong here and you have totally misunderstood the GPL.

Ok, I stand corrected. GPL is far more strict and far-reaching than I (intuitively) thought

@wrxtasy static or dynamic explicitly makes no difference as per the FAQ.

[wrxtasy]

Cheers, I did read thru the FAQ about a week ago, and before that as well.

I now see the distinction between calling an external player from within Kodi using the inbuilt playercorefactory.xml function. An using a standalone external App such the Android MX Player.

Compared to packaging a custom player into XBMC itself as VidOn are doing.

When in doubt, I tend to look to the intent of GPLv2 ,
1) source code changes public and
2) you can build and run it. If those pass, then there is no GPLv2 issue worth pursuing. If you review ALL the legal cases that have involved GPLv2 (and I have) 1 and 2 are the prime points of contention.

Point #2 that Mr MC made is where I see its impossible to compile and run succesfully the VidOn.apk due to the closed source libs residing on VidOns protected servers.

This is the commit I'm talking about:
https://github.com/xbmc/xbmc/commit/4ff7...01a191c3de

I'm calling them non-compliant as well on this point #2 alone.

[MrMC]

Use caution in taking the FAQ as reality, GPL can become a political mess very quick. Legality ignores things like FAQs, and looks at the legal wording of the license as well as the intent. For example, if what you link is a system lib, #GPLStaticVsDynamic does not apply (for GPLv2).

Note, anything GPLv3 has a much stricter set of rules. If VidOn is using samba GPLv3, they are in a world of hurt right now

[Koying]

[Ok, I stand corrected. GPL is far more strict and far-reaching than I (intuitively) thought

OTOH, thinking about it, it makes plenty of sense. It would be too easy to "hide" proprietary code written above a FOSS app in a lib, which is basically what VidOn does.

[learningit]

I would suggest that you read this outline of compliance:
https://www.fsf.org/licensing/compliancelab.html

There are many ways to grant exceptions for binary libraries. A number of companies that I've managed in the past have done just this. When reading through the compliance docs you need to be able to discern the legal difference between must, shall and should.

GPL compliance is not for amateurs or those on a witch hunt. I would suggest that rather than speculate, one of you get in touch with FSF and ask whether or not the particular program being discussed is compliant or not in their opinion. I'm not certain if they charge for this, but it would be nominal for a ruling vs. compliance certification.

[MrMC]

Not exactly they dyload their proprietary lib inside their kodi codec. Exactly what happens on all AMLogic boxes with the obsolete amlplayer and existing amcodec.

Where they messed up was sticking their proprietary lib into prefix and not providing the headers so others can build and run the silly thing on supported hardware. Thus you have two points 1) proprietary lib is not a system lib and is carried by the install of the app and 2) You cannot self build and run it.

Buzz, epic fail. Try again and pay attention this time.

[MrMC]

FSF is very political, I would never go to them for advise as they would tilt it toward their political agenda. If you really want to know, hire a legal team to investigate the issues. Legalize is a very odd language, words and phrases that you think make prefect sense CAN have a legal meaning that you would not expect. Been there, done that...