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@ubuntu.com
> <mailto:barry@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@lists.ubuntu.com <mailto:ubuntu-devel@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™
>
>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
