App installer design: click packages

Tue May 21 02:19:08 UTC 2013

What if we made nearly every LGPL library of consequence a part of the
Ubuntu SDK?

On 05/14/2013 08:22 PM, Jeremy Bell wrote:
> Hello. New to the thread and the forum. Already sent a message directly
> to cjwatson, I won't repost here. Just wanted to raise the issue of LGPL
> compliance, which is not possible for commercial applications in the
> proposed system. The dependency system on the debian packaging system is
> what allows linux desktop apps to be LGPL compliant, but the new model
> does not allow shared library packages or apps that depend on other
> packages. Bundling an LGPL library with an app is only possible (and
> debatably so at that), if the app is itself LGPL/GPL. This is my
> understanding based on personal experience and legal counsel while
> delivering commercial enterprise applications. Sometimes, even the LGPL
> library is dynamically linked, a commercial license is needed when the
> library must be bundled with the installer (for example, to allow
> offline installs).
> 
> In order to allow LGPL compliant applications, your packaging system
> must at least do the following (as always, I am not a lawyer, consult a
> professional, etc.. ):
> 1) Applications and their LGPL library dependencies must be packaged and
> distributed separately. Bundling is the same as static linking for the
> purposes of LGPL compliance, even if the user can theoretically replace
> the dynamic library after your app is installed. You may often see this
> particular point made explicit by the LGPL author. Having separate
> package downloads works. Bundling the .so file in your application
> package does not work.
> 2) Applications must link to the LGPL library dynamically.
> 3) Users must be able to either modify the existing shared library
> binaries, or install a new version in such a way that your application
> will use it instead of the original.
> 
> I suggested an alternative to the way the desktop system does it, in
> that we could allow shared library packages, but have them self
> contained like apps, and let the user dynamically "switch" between
> shared libraries on a per app basis, including their own custom builds.
> I have no idea how technically feasible this would be, however, or
> whether it would actually qualify as compliance with the LGPL, but it's
> the only thing I could come up with short of allowing apps to download
> additional shared libraries after install and load then dynamically,
> which of course would be a security risk.
> 
> Regards,
> Jeremy
> 
> 
> 
> On Tue, May 14, 2013 at 10:47 PM, Barry Warsaw <barry at ubuntu.com
> <mailto:barry at ubuntu.com>> wrote:
> 
>     On May 14, 2013, at 02:37 PM, Colin Watson wrote:
> 
>     >> > Barry spent
>     >> >some time looking at 0install, and it wasn't too bad a fit but
>     we would
>     >> >still need to solve many of the same system integration problems.
>     >>
>     >> Is there a list of these issues somewhere?
>     >
>     >Barry Warsaw would have to speak to that, I think.  But mainly, there's
>     >no way for the system to declare any kind of integration facilities at
>     >all, as far as I can see, so we'd have to solve that problem anyway.
> 
>     What I think Colin is getting at here is that any system is going to
>     have to
>     deal with declaring the files that allow an app to interoperate with
>     system
>     services.  Think along the lines of dbus .service files, .desktop
>     files, etc.
>     These will be things we might know about right now (such as the
>     above), but
>     they maybe be additional integration points in the future.
> 
>     Let's say for example, some future system service comes with a new
>     version of
>     the SDK or OS image, that allows apps to define push notifications, by
>     including a .push file that has to get installed somewhere to be
>     registered.
>     The app itself will only declare that it has a myapp.push, and you
>     won't have
>     anything like a maintainer script to install myapp.push.  Instead, the
>     system's push notifier will have to be responsible for registering a
>     plugin
>     with the installer system to say "okay, now when you see .push
>     files, put them
>     here and do this something to register it."
> 
>     You don't want the logic for that in the installer, and you don't
>     want it in
>     the app.  You want it as part of the system push notifier.  This
>     latter will
>     register a trigger that gets run whenever the installer sees that an
>     app has
>     declared a .push file *and* you want it to run over all app .push
>     files when
>     the system push notifier is installed.  In the latter case, imagine
>     that you
>     have a dozen apps that support push notifications installed on your
>     phone, but
>     the system push notifier hasn't been installed yet.  Once it is, all
>     your
>     already installed push-enabled apps will Just Work.
> 
>     This all means that the installer must have plugins for handling new
>     functionality and the declarative manifest must be extensible, i.e. the
>     installer will ignore extensions that it doesn't (yet) have a registered
>     plugin for.
> 
>     I didn't get far enough on 0install (or don't remember ;) whether it
>     has that
>     capability.
> 
>     >I will certainly concede that the rest of 0install is very flexible and
>     >has a usefully pluggable design; you seem to have done a good job on it
>     >and Barry spoke well of it.  It just seems that there's a bit of a
>     >mismatch in that it's kind of over the top in terms of flexibility for
>     >what we need and seems to be entirely missing some other things we
>     need,
>     >as above; and it would be a lot of code to rewrite in some other
>     >language if (as is possible, though not imminent) we decide that Python
>     >is just too heavyweight to run routinely on the Ubuntu phone.
> 
>     On just few other points:
> 
>     I'm not really a big fan of XML formats, since they're not human
>     consumable
>     (readable or writable).  Others may disagree, which is fine, but I
>     don't have
>     any interest in arguing about it.  Probably not a deal breaker,
>     since the XML
>     files can always be generated, either by the 0install tools or
>     something that
>     takes a JSON or YAML as input, etc.
> 
>     I liked that it was fairly easy to wrap executables in "security"
>     containers,
>     but I didn't dig into this in a lot of detail.
> 
>     It seemed to have good security considerations.
> 
>     IIRC, there's no built-in support for uninstallation.
> 
>     We probably want something like an online-only search REST API for
>     finding
>     apps, and then downloading from the URL such a search gives us.
>      Thus, there's
>     no cleverness in the repository layout, nor on the device, for
>     finding apps.
> 
>     Anyway, that's about all the additional stuff I've gleaned from my
>     previously
>     private experiments with 0install that hasn't already been discussed
>     in this
>     thread.
> 
>     -Barry
> 
>     P.S. If we *were* to accept that the installer could be written in
>     Python, it
>     would *have* to be Python 3.  No more Python 2 on the phone, please!
> 
>     --
>     ubuntu-devel mailing list
>     ubuntu-devel at lists.ubuntu.com <mailto:ubuntu-devel at lists.ubuntu.com>
>     Modify settings or unsubscribe at:
>     https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> 
> 
> 
> 
> -- 
> Jeremy Bell
> Sleepy Daddy Software™
> ---------------------------------------------------------------------------------------------------------
> Have a little one? Try Giggle Pad© for Windows Phone 7, a fun and
> educational game for children 9 months and older:
> http://social.zune.net/redirect?type=phoneApp&id=5858669e-88d5-df11-a844-00237de2db9e
>  
> Does your brand new Windows Phone 7 have dead pixels or screen
> discoloration? Find out with Pixel Checkup© for Windows Phone 7:
> http://social.zune.net/redirect?type=phoneApp&id=1f5d0cf5-a2d8-df11-a844-00237de2db9e
>  
> Giggle Pad and Pixel Checkup are copyright © 2010 Jeremy Bell and Sleepy
> Daddy Software™
> 
> 