Publish a new Kivy Launcher for Python 3

[inclement]

Issue created to mark this goal for the 2019 Belgium hackathon.

[KeyWeeUsr]

New launcher is located here and the script for building setup.py. We need to find the key for signing the release.

Do we want to have both Python 2 and Python 3 launchers or just Python 3? Also, PyJNIus should have a release before this because there are important things fixed (ref counts, conversion between Python and Java, etc).

[inclement]

I'd be happy to go with just Python 3, since it keeps the play store listings simple. Does the launcher need any testing I could do?

[KeyWeeUsr]

I'm not sure there is any testing for the launcher necessary per se. It pretty much just runs a main.py file, but we need to check the services (e.g. service/main.py or something) actually works and/or launcher is at least compiled with --service ??? flag.

[AndreMiras]

I feel like this issue should be tracked in https://github.com/kivy/kivy-launcher/issues but I couldn't transfer it to the kivy-launcher project somehow

[ghost]

Does this thing replace the --launcher launcher? Because I have been meaning to look into removing that one due to licensing issues (uses the renpy source code in the source tree which has no license info and could be LGPL, which makes it a bit dangerous to keep around even if not used outside the launcher. Right now it might actually be copied into all apps even, I haven't investigated that yet)

It would be neat because then removing --launcher would be more feasible now. IMHO it is a great idea to have this as a separate external project, because I don't see how it couldn't use the normal bootstrap mechanism to start up

[chrysn]

The missing-license topic apart (that should be fixable if the actual source is tracked down), why would an LGPL file in the source be dangerous as long as it's properly declared? Python does not link, so even GPL requirements would only pertain to that file and not the "whole program", and with LGPL, it's even made explicit that this can be mixed with any license as long as the file stays LGPL.

[ghost]

@chrysn I am not a lawyer, did you ask yours or did you just make that up?

Again I am not a lawyer so this is probably all nonsense, BUT:

1. There is no way to swap it out easily in an .apk, that should be already a violation of the LGPL

2. Nobody informs people of the LGPL license text and where to get the original source in their app, that is also a violation of the LGPL (or do you do that in your app?)

3. Is a python import even regarded a dynamic link?

Python does not link,

Says who? the LGPL is written with C/C++ linking in mind, and while I get the argument python importing is similar to dynamic linking, did you actually ask someone competent about that? because just relying on a hunch here is a horrible idea

In overall the LGPL is just quite complicated to comply with, and on top of things the files are NOT properly declared right now. So I stick with my opinion that the only really sane option is to just rip them out.

[chrysn]

I am not a lawyer, did you ask yours or did you just make that up?

Neither am I, nor any of the options; my comment came from established practice in other projects, eg. what Debian accepts to be present in its binary packages.

I'd be happy to run through all those arguments, but before we waste both your and my time, is LGPL compatibility really the showstopper? And if so, do you have pointers to the possibly-offending files (for I didn't find them on a quick search but probably lacked the right parameters) to clarify their license? For if the renpy code should go out for technical reasons, or it turns out it's not as LGPL licensed as we imagine, continuing this would be interesting but pointless.

[ghost]

I did dig deeper into this and forgot to update: it's not actually LGPL but the same license as p4a, so forget all I said (wiki just mentioned LGPL for renpy because of other things) But yes, LGPL for apk has the risk of being a huge showstopper in general, or not what do I know (not a lawyer) but just see above. LGPL is not that easy to fulfill for combined binary packages

…

On April 8, 2019 3:32:43 PM GMT+02:00, chrysn ***@***.***> wrote: > I am not a lawyer, did you ask yours or did you just make that up? Neither am I, nor any of the options; my comment came from established practice in other projects, eg. what Debian accepts to be present in its binary packages. I'd be happy to run through all those arguments, but before we waste both your and my time, is LGPL compatibility really the showstopper? And if so, do you have pointers to the possibly-offending files (for I didn't find them on a quick search but probably lacked the right parameters) to clarify their license? For if the renpy code should go out for technical reasons, or it turns out it's not as LGPL licensed as we imagine, continuing this would be interesting but pointless. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #1638 (comment)

[chrysn]

I did dig deeper into this and forgot to update: it's not actually LGPL but the same license as p4a, so forget all I said (wiki just mentioned LGPL for renpy because of other things)

Thanks for the update, good to have that cleared.

But yes, LGPL for apk has the risk of being a huge showstopper in general, or not what do I know (not a lawyer) but just see above. LGPL is not that easy to fulfill for combined binary packages

I can see it is for nonfree apps. For apps that have source (like the launcher), there's no need to have the library swappable as a dynamic library (source is OK too per 4.d.0), and the referencing the copyright statement (4.c) is only necessary if there is a copyright section in the combined work. (But even my car does that :-) )

[ghost]

The launcher doesn't link its own source inside itself, does it? So yes it WOULD be (if it was LGPL) a problem even for that, because people will distribute it without realizing that. The LGPL is really more complicated than people make it, it's only not a problem if you ALWAYS distribute with full source or instructions to get it, which almost nobody other than linux distributions will do per default in all cases. Unless I am wrong of course, since, not a lawyer I'm just saying, maybe be careful suggesting LGPL compliance is trivial, there are many potential pitfalls and this can hurt people later if they're not careful

[Julian-O]

Closing as stale