GPL violation

[jd485]

No source code for the OS

No public release of the skin

Use of GPL software such as xbmc, NOOBs, OELEC.

What is going on

[cecemf]

The product is not officially out yet so a bit of patient seriously people things everything come from the sky magically. There is work done behind the scene. Under the GPL they still have time to release it. Many company release them years after launch. There is no time limitation as long as it's released. So chill out.

[ghollingworth]

It's just delayed because we're still trying to get to a working version... The build system / distribution management scheme for OpenELEC makes it very difficult to release the code because we have to generate patches for everything!

But we'll get there and release a working version when we've got something a little more mainline.

Is there anything specific that you wanted to see / do that you needed from the code?

[pbuyle]

While public release of the source code is the usual way to comply with the GPL, the GPL does not require you to do so. From https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html#SEC3

You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) ... b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c) ...

Sadly, AFAIK, Five Ninjas does not comply with the GPL because the written offer is also missing. I trust them to resolve the issue quickly, either by publishing the source code or by simply adding the written offer to future distribution of the code.

That said, I personally dislike the argument "we are polishing it before releasing our source code". Release imperfect source code is perfectly fine. You don't have to publish a perfect masterpiece, publish whatever you have. Put your code in public repository(ies) early, let the cleaning and refactoring be public. You may attract early contributors and they may help you to polish your code to get to a nice, stable and clean distribution of your work.

[ghollingworth]

Unfortunately this is not a case of 'polishing' (where did you see that anyway?), it is a case of getting the code into a state where it can be shared / upstreamed.

Hopefully it should be ready to go in a couple of weeks

[gerv]

Without wanting to pile on, and acknowledging that this was not the expressed position of Five Ninjas, "Under the GPL they still have time to release it" is simply not true. The GPL requires source to "follow the binaries" to anyone to whom you ship binaries, at any time. It does not require publication, it is true. So, whatever code inside Slice is GPLed (and that may not be all of it), then recipients of Slice hardware need to get either the source, or a written offer. This is GPLv2 section 3 parts a) and b).

As someone else has noted, the GPL only requires "source follows binaries", not publication. But of course, any recipient of the source can publish it.

Five Ninjas need to be shipping written offers or GPLed source with Slices. For Slices with an HDD, sticking the source tree on that seems like the obvious option. For those without, if it'll fit on the Flash storage, stick it there, or ship a CD. All of those things are generally considered less hassle than having to deal with answering requests sent in by people with written offers.

Gerv (Day job: licensing guy at Mozilla; Night job: waiting eagerly for a Slice :-)

[ghollingworth]

I assume it's OK to just publish the patches for OpenELEC in which case there are only a couple of items that need to be published everything else is already supplied in source format on Slice anyway.

Might be easier than I thought

[gerv]

ghollingworth: the GPL requires the complete corresponding source code (GPLv2 section 3 part a) to either accompany the executable or be available via responding to a written offer. So anything which is GPL and compiled needs source, all the source.

If stuff is already in source format on Slice (and not preprocessed or stripped or reduced in other ways) then it may not need to be supplied again; it depends if it's "the preferred form of the work for making modifications to it". If people wouldn't normally hack on it in the form or arrangement it's delivered in on the Slice, then you may need to supply it again in development arrangement.

Basically, it's easiest just to ship your entire tree, holding back those bits which are specifically and carefully engineered, technically and legally, to be (at the moment) closed source. That way you can be sure you've met your obligations.

[ghollingworth]

Although the build system for OpenELEC doesn't include the sources for the underlying packages (i.e. linux kernel for example), those are downloaded as part of the build process. What happens in this case? Do I have to make copies of those as well (basically just bulk copy the OpenELEC sources as well?)

This is why the GPL is such a problem in such a situation, it clearly puts a significant overhead on a project like this. I had originally planned on making continuous updates to the Slice OS but it seems that would mean I'd spend most of my time just getting it into a suitable form for publication

So I guess that means the best thing for me to do is implement the initial OS and then leave it for the community to continue to support it. Effectively dropping support for the source as soon as I make it open

Gordon

[ghollingworth]

Is it OK for me to zip up the 16GB build directory and ship that? I assume so... Not sure how long it'll take to download but does hit the requirements...

How long does the code need to be made available for? Is there any reason to keep sources hanging around for old builds if the same code exists in newer builds?

[gerv]

ghollingworth: it's probably a good idea to read the GPLv2, to be certain of what's required rather than relying on my advice :-)

If the build dir contains all the source code, and one could rebuild a modified OS from it, I'd say it meets the requirements.

Remember, there is no requirement that you make the code generally available (although that's common), you just have to make it available to Slice purchasers either with the Slice, or as a written offer. If you use the written offer method, you have to be willing to ship CDs, for 3 years, to anyone, of any version of the software ever shipped with a Slice. Which is why most people consider that option far more hassle, and find it easier to just ship the source with the object. Then you have no further obligations to that purchaser.

In terms of support, no-one, not even the GPL, can force you to do collaborative development in the open. But there are many reasons why it's in your interest.

It shouldn't prevent you from doing continuous updates. Updates are downloaded, not shipped, and the GPL says that as long as the source is available for download in an equivalent manner, then that's fine - you don't have to force people to download it. So if you do open development, and have a Git repository, and the software tells the user somewhere exactly what build it is, you are probably fine for continuous updates.

You say "the GPL puts a significant overhead on a project like this" - how does that compare to having to implement your own OS from scratch? Let's make sure we are doing a fair comparison. Five Ninjas also have to spend time applying for and tracking licenses for video codecs, and various other administrative tasks to do with shipping a product. This isn't different.

[gerv]

Happy to talk this through on the phone if that would help :-) I want to see Slice succeed; being dinged for GPL violations by the community is not a point on the route to success. Email me at gerv at gerv dot net to get my number.

[cecemf]

Gerv I don't understand why you jump on there thought and threaten the FuveNinja when the OS is not finished it still Beta so there is no need to publishe anything on an unfinished project. The product is on pre-order (general sale) and not shipping yet. Slice is basically OpenELEC with Kodi so I don't get it why you need it so bad right now. Give them time. They are a small team with a lot lot of work. You don't see Linix foundation or even Apple release their GPL software while in beta do you ?

Chill out be patient and let them do there work please.

This is just my personal view that is.

[gerv]

I have no desire to "jump on" our threaten anyone and I hope observers would agree my tone has been polite and helpful. But it is simply not true to say that because software is in beta or unfinished that the GPL can be ignored. If binaries are shipped, the source must follow.

Apple doesn't use GPLed software, but yes, Linux is developed in public and so the source is always available, to development and to release versions. And the Linux Foundation doesn't ship hardware, so the situations are not the same anyway.

[ghollingworth]

In the end it'll get done it's just going to take some time, thanks Gerv for the information and offer of a chat, might take you up on that later. At least now I understand what it is we need to do.

[cecemf]

FYI Gerv Apple uses a lot of open source and ever OS as the open source part of released, as you can tell we now are at 10.10.2 and only 10.10.1 is release to the public because this is how it works. http://www.opensource.apple.com

[gerv]

I know Apple uses a lot of open source. It uses very little or no GPL software. This stuff is my day job. :-)

[NedScott]

Just a little clarification, but I believe (I'm not a lawyer, etc) the applicable license in this case is GPL v3, since OpenELEC is being used. Kodi can be compiled under either license, and the way OpenELEC does it requires GPL v3 to be chosen (the "newer" Samba and some other code). This should make it easier to comply with the various requirements, as I understand it.

[gerv]

ghollingworth: it's been a couple of months now, and Slices have been shipping for a while, and back in April you suggested it might take "a couple of weeks". What can we do to get this moving?

Gerv

[cecemf]

The product is not on general sales yet. It's on pre-order and beta. So surely this will come once the OS and product is finalised. Why such a hurry god guys

Sent from my iPhone

On 8 Jun 2015, at 09:06, Gervase Markham notifications@github.com wrote:

ghollingworth: it's been a couple of months now, and Slices have been shipping for a while, and back in April you suggested it might take "a couple of weeks". What can we do to get this moving?

Gerv

— Reply to this email directly or view it on GitHub.

[Hedda]

You aren't allowed to wait and withhold GPL licensed source code in order to make it more presentable.

Like already mentioned the source code release must follow EACH binary release when asked, bit for bit.

Anyone who already got a Slice have the right to the full source code for each binary version of Kodi.

Same discussion and requirements as for Zidoo http://forum.kodi.tv/showthread.php?tid=227837

Also same as this longer thread about VidOn http://forum.kodi.tv/showthread.php?tid=207004

[ghollingworth]

OK, so one of the problems with the release of the sources is that the source tree is 16GB... Now from the terms of the GPL it looks like I have to release it like that, but if lots of people start downloading we are going to lose our server connection real quick!

If I release it as a set of patches to the OpenELEC tree (which incidentally is the way that the OpenELEC build system works) that would be easier although less useful because the patches are all going to change in the next couple of weeks anyway as we upstream our changes to the foundation kernel (the codec drivers and LED drivers for example)

Gordon

[pbuyle]

I'm no expert, but I think providing the diff patches with clean instructions on how to apply them it is enough for GPL compliance. If I'm correct, that would put you in the clear until they are included in upstream.

GPL compliance is not something you should eventually get to, when everything else if figured out. Software licences, whatever they are, are something you figure out and comply with from the very beginning.

[ghollingworth]

Since the sources are actually patches then I don't think there's a problem with supplying patches. The main problem is creating the patches in the first place and making sure that the resulting binaries created with those patches match the original binaries.

[Hedda]

@ghollingworth, the size of the sources and rolling incremental changes is why most open source projects host all their source code in a distributed revision control system such as Git on a public web-based repository hosting service such as here on GitHub, which coincidentally is what both OpenELEC and Kodi does too.

Yes you now do need to release that that full source tree which is 16GB as-is, but if you now understand that this is a must then from now on begin to utilize Git and use GitHub as your primary repository, preferably using forks from the upstream OpenELEC and Kodi, as that way you can just branch of and tag a revision with a version number then compile and release the binary of that build, and when people like us later ask for the full source code for that specific version of a Slice build then you can simple point to that branch and tagged revision here on GitHub.

Suggest that you look at how OpenELEC and Kodi teams operate with forks, branches, pull requests, and process flows for code reviews here on GitHub as they are doing an exemplary job and keeping it all fully GPL license compliant, and very professionally even though they are not doing it as their profession.

Collaboration together with a distributed revision control system is the whole point with GitHub.

https://guides.github.com/activities/forking/ https://help.github.com/articles/fork-a-repo/ https://help.github.com/articles/syncing-a-fork/ https://help.github.com/articles/configuring-a-remote-for-a-fork/

https://help.github.com/categories/collaborating/

https://help.github.com/articles/branching-out/ https://help.github.com/articles/creating-and-deleting-branches-within-your-repository/ https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches https://github.com/blog/1377-create-and-delete-branches

https://help.github.com/articles/using-pull-requests/ https://help.github.com/articles/creating-a-pull-request/ https://help.github.com/articles/checking-out-pull-requests-locally/

GitHub also provides access control and several collaboration features such as wikis, task management, and bug tracking and feature requests for every project.

Projects on GitHub can be accessed and manipulated using the standard git command-line interface and all of the standard git commands work with it. GitHub allows registered and non-registered users to browse public repositories on the site. Multiple desktop clients and git plugins have also been created by GitHub and other third parties which integrate with the platform. A user must create an account in order to contribute content to the site, but public repositories can be browsed and downloaded by anyone. With a registered user account, users are able to discuss, manage, create repositories, submit contributions to others' repositories, and review changes to code.

[gerv]

I don't think it's right for us to use the word "must" in telling ghollingworth how to go about this; there are many ways it can be done. But I agree, it does seem that some of the potential practical problems he sees could be obviated by using a Github fork to develop the open parts of the Slice, and then having a separate tree and build step to include the parts which are not (yet? :-) open source. This should have process advantages for the development.

However, I'm afraid I must push back on the idea that providing patches is acceptable. For better or worse, the GPLv2 does not say "you must provide a way for the recipient of your binaries to reconstruct the source", it says you must:

"Accompany [your product] with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange"

(If you are using clause a) in section 3), which I would recommend.) Note the word "complete".

16GB is a bit of a practical problem, I agree. Are you sure that's the size of the pure source, and not the size of the source + build artifacts? How well does it compress? Could it fit on a DVD when compressed?

Gerv

[NedScott]

OK, so one of the problems with the release of the sources is that the source tree is 16GB... Now from the terms of the GPL it looks like I have to release it like that, but if lots of people start downloading we are going to lose our server connection real quick!

You only have to provide source for Slice users who have already received the software (which would assume they have a physical Slice). Until then, there is no GPL violation :)

You could host it on bittorrent, or even ask people to send you a blank USB drive to copy it on. GPL v2 is old school like that.

Personally, I wouldn't worry about this. I would learn from it and make sure it doesn't happen in the future, and as long as that happens then I think people will be very forgiving of the original delay (if it ever happens in the first place, as no GPL violation seems to have happened yet). Team Kodi and the OpenELEC guys are all happy to help with advice on how to handle this stuff, as well.

[Hedda]

Since they provide binaries of OpenELEC with Kodi on their website via its forum for anyone to download today they must provide to the source code to anyone who asks that have downloaded those binaries, even if you are not their customer. They have already distributed the binaries to anyone who downloaded it from there, hence no matter if they actually received or bought a Slice device. You can go a and download it now yourself, and if you do then you also have the right to get access to the complete source code for any code files that are licensed under GPL.

[NedScott]

Fair enough. However, I still wouldn't worry too much about this. Yes, it's a GPL issue at the moment (I assume you've downloaded the binary and are now asking for a copy of the source code, etc), but I think it's worth giving FiveNinjas the benefit of the doubt that they want to comply, but just need some help at the moment. This is very different from VidOnMe or other examples, where they had repeated issues of delayed releases.

The important thing going forward is to try and fulfill the current requests for code (the sooner the better), and help them for the future so that it works out well for everyone. Everyone makes mistakes, and that even includes Team Kodi/XBMC (we've found some bad code in the past that wasn't even licensed correctly, oops!). We've brought the issue to their attention, and now we can work on fixing it, so things are all good (in a manner of speaking) so far.

If, on the other hand, this becomes a pattern of abuse in the future, then I will gladly grab my pitch fork and torch ;)

[ninyule]

I hope all you people causing hassle have bought Slices...

And I trust that ALL of the posters who have bought Slice will be writing great hacks and sharing them with the rest of us!

Just sayin'

[ghollingworth]

It's definitely all going to get up there I promise... The issue is that we're trying to do it right, and by right I mean make sure our changes can get accepted upstream (the Raspberry Pi kernel mostly) so that they all automatically appear in other operating systems. Such as OpenELEC, OSMC, Raspbian etc. You should then be able to use the LEDs and the audio codec without actually changing anything (yes that's right, the device tree stuff we're trying to get working should mean that the audio output will 'just work' without any input from anybody!)

But if I release some of the stuff we did up front then I'll release some code that I'm really not happy about people starting to push upstream... As an example the first implementation of the LED code, the way I did it was wrong and I've since changed it, but if I released it someone may try and push it into the Raspberry Pi kernel without my input meaning I'll end up with an out of date driver that people then based software on!

You should start to see some changes appearing over the weekend since I should have a little time to work on it, starting with the kernel and hopefully adding in the OpenELEC build system as we go

[gerv]

ghollingworth: I see your concern, but I'm not sure "I'm not happy with the code I've shipped" is a valid reason under the GPL for not giving a copy of the source to the people you shipped binaries to. :-)

Remember, you don't have to make the source public, but you do have to give it to everyone who gets a Slice (who then may make it public if they choose). Of course, given that you didn't ship source with the original Slice shipments, making it public is probably a better (if technically non-compliant) way to make amends for that than shipping everyone an extra DVD.

If you want to accompany it with a README file saying "some of this stuff is a hack; please don't push it upstream yet", that's fine, of course.

Anyway, looking forward to seeing the code appearing :-)

[ninyule]

Gordon, I would like to think I speak for the majority of Slice users - take your time and please make sure you personally are happy with your work. It makes absolutely no sense to push out code that is 'wrong' yet might be put out into the public domain...

I can't believe there are people genuinely pushing for that scenario. Perhaps those posters' time might be better spent creating for the community rather than criticising those who have spent many long hours doing the creation.

Reading the Kodi forums is an exercise in frustration, to see genuine, sensible feature requests get swamped by endless arguments and complications.

I would also be interested to know what use of the code is intended by the critics. Maybe they could let the rest of us have a list of functions/hacks they intend to implement for the good of the Slice community?? Adding an 'Add to Playlist' function to the Music library would be a good start - apparently Kodi users have been waiting 10 years for it and still no sign!!

[gerv]

I can't speak for anyone else, but my motivation is twofold. Firstly, to avoid the Slice project running into community, PR or legal trouble, because I want Five Ninjas to succeed. Secondly, because complying with open source licenses is the Right Thing to Do. We're all one big community, and if people contribute code to the commons under certain terms, it's right to respect that, or not use their code.

[NedScott]

@ghollingworth That's not a good reason to withhold the code, but I really doubt you have anything to worry about. If my time at the Kodi project has been any indication of what it is like for other open source groups, people are very very slow (or unlikely) to try to push someone else's work upstream. They almost always first ask the person who made the change (such as you) to push it upstream. You can also note things (documentation, documentation, documentation) in the code itself and literally say "this is a temp hack, so please don't push this upstream". Getting people to push things upstream is like pulling teeth, and it's not something people seem to rush to do ;)

[MartijnKaijser]

@ghollingworth the rules are simple. you are NOT allowed to withhold any source code which is based upon GPL. You MUST make it public if you are either providing public binaries or if you don't but then the people who own a SLICE still have the explicit right to receive the source code in whatever state it is in. "it's not good enough" is not a valid reason to withhold.

[cecemf]

Martjin not sure what's your problem or why you are so eager to get it now ?!

I agree about the GPL but for a finished software not a beta software which is what SLICE at the moment. When you get the slice on kickstarter it's clearly mentioned also when you help finance a project you don't buy a product you get it as a reward therefor the GPL can't apply for an unfinished product and unfinished software. If you go to SLICE website you will see the pre-order are open but not on sale yet. You can't possibly in the right mind ask for this to be done on unfinished software.

Any developer in the right mind will do that'll I'm saying is see the situation as it is and be patient. It will come.

Sent from my iPhone

On 13 Jun 2015, at 07:50, Martijn Kaijser notifications@github.com wrote:

@ghollingworth the rules are simple. you are NOT allowed to withhold any source code which is based upon GPL. You MUST make it public if you are either providing public binaries or if you don't but then the people who own a SLICE still have the explicit right to receive the source code in whatever state it is in. "it's not good enough" is not a valid reason to with hold.

— Reply to this email directly or view it on GitHub.

[gerv]

cecemf: with respect, what you think is not as important as what the GPL actually says. It makes no distinction between beta software and finished software. You can keep your modifications to yourself for as long as you like with no obligations (as many companies do when developing software), but once you start shipping them to people, you have to ship the source to those people too. See GPLv2 section 3: http://www.gnu.org/licenses/old-licenses/gpl-2.0.html .

Given the above, can we please not have any more of either a) grumpy assertions that this is an unreasonable request, or b) grumpy demands for the source to be released yesterday? :-) Let's all chill out for a minute and let ghollingsworth work :-) I have every confidence the problem will be resolved soon, and continue to offer my help if it's useful.

[Hedda]

@ghollingworth please follow the link that gerv posted above. Your opinion on the code state or mature is irrelevant. Beta, alpha, or quick and dirty hacks in your code do not matter. Again, when you have provided binaries from GPL code to the public you must also provide the full source code on demand, no exceptions, and there are no valid reasons for delaying from now on when you have clearly been made aware of this issue.

I too want Slice to success with its product based on open source software, however to do so you have to always fully comply with the software licenses and show good faith by provide the source code upon request in a timely fashion or it will lead to bad press and hostility from the community. So it is good that this issue is highlighted early and brought to attention, that way the Slice team will hopefully understand to prioritize this and take action now rather than later when there might be too much bad blood to just say forgive and forget.

And yes I am a backer of Slice on Kickstarter, but reason for that is that you promised a product that would use open source software and comply with the licenses. If I knew or find out that the FiveNinjas do not take the GPL serious from now on then I for one will no longer support the project, and worse I advice my friends not to support it either. Word of mouth is extremely important for products like the Slice, and gaining a bad reputation in the Kodi and OpenELEC communities can not be good for any backer of the Slice.

[gerv]

Hedda: you should take a leaf out of the books of the Software Freedom Conservancy and other GPL enforcement organizations. I promise you that their approach is not nearly as combative as yours. For example, the SFC worked with VMware for 4 years before finally filing a lawsuit. I'm not saying we should wait that long, but perhaps a little perspective is in order.

[Hedda]

@gerv Trust me, this is not me being combative. As long as they are made aware and understand of the situation then small companies like FiveNinjas can be much more agile and respond faster to issues like this as they do not have the internal bureaucracy and legal departments that large international companies such as VMware, IBM, or Microsoft, etc. which also make great use of open source software today. Being a small company should actually gives FiveNinjas less of an excuse to not quickly respond to something as simple as this, and being a small company also means that they can probably not afford getting a bad reputation in the open source community which this or similar violations could lead to. In the open source community it is in everyone's interest to help new companies understand, respect, and promptly comply with the different open source licenses that they have the legal option to use if they play by the book.

[ghollingworth]

First major push of the Slice code is complete, finally builds again at the head of OpenELEC.tv

Still missing a fair amount of functionality although audio has already been pushed to the linux.git just need to make up a patch for the OpenELEC.tv whilst trying to get it upstreamed into the Raspberry Pi kernel. (Our CS4265 patches and changes have been pushed back to Cirrus for pushing upstream)

Next step after that is to re-integrate the LED code, although that should be simple in it's current state.

[ghollingworth]

Everything is now pretty much there now, couple of small tweaks for settings etc but they're minor changes... Check OpenELEC.tv repository for details

[gerv]

Great news :-) Thanks!