ubuntu-phone team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

You're confusing bundling with static linking.  I would really recommend
checking out the click packages session to see what is going on here.
You can really think of it more as a self contained ZIP file than a
single binary that gets executed.  The ZIP file can contain heaven knows
what, and the program can freely use anything in that directory,
including loading libraries from there.  It also, in theory, could allow
for specific files to be overridden by the root user to allow for
replacement of the library or by putting them earlier in the library
loading paths.  It seems to me that in these cases the library remains a
distinct work instead of a derivative work.

I didn't think of the shaped binaries as static linking, but I guess
effectively it is.  For those folks I guess they'd have to include a
copy of the Mono runtime (similar to what Turbo Tax does on OSX) or pay
Xamarin for an appropriate license.

In the end, I'm not a lawyer; and more importantly, I'm not your lawyer.
I'm a guy on the Internet.  But, I've seen nothing that convinces me the
Click Package format restricts developers from using LGPL libraries as
long as they're handled correctly.

Ted

On Tue, 2013-05-14 at 16:27 -0400, Jeremy Bell wrote:
> There is more to it than providing the sources for the library the app
> includes, at least for commercial applications.
> 
> 
> 
> To summarize
> this: http://answers.google.com/answers/threadview/id/439136.html
> 1) The application and the shared library must be distributed
> separately. If the application and the shared library are distributed
> together (e.g. as a bundled, self-contained app package), then the
> whole work (app + library) is considered a "derivative work", similar
> to static linking the library. For the LGPL, that means your
> application code must be LGPL, so this cannot be used for closed
> source application development, or in any case where you also bundle
> another library with your app that has a license which is incompatible
> with the LGPL and you don't own the copyright to re-license the work
> under the LGPL.
> 2) If you make any modifications to the library, you must provide the
> source to those modifications under the same license.
> 3) The application must allow the end user to modify (or if you
> prefer, must not prevent the user from modifying) the LGPL binary in
> question without your permission or intervention and without
> recompilation of your application binary, and must also not prevent
> the user from reverse engineering your application, for the purposes
> of debugging their modifications to the shared LGPL library used by
> your app.
> 
> 
> You mentioned the 2) requirement, but 1) and 3) are also requirements,
> and are not possible to comply with in a BYOD self-contained app
> packaging platform, because ALL apps must bundle their dependencies in
> the same app package, which cannot be modified after installation. 
> 
> 
> And, please note that nobody can use the LGPL license of the mono
> library (or any other LGPL library) in an application distributed on
> iOS or Android app stores. All use of mono on those platforms is via a
> commercial dual license sold to them by the author of the library,
> Xamarin. The LGPL license cannot be used with those app packaging
> models either. 
> 
> 
> Regards,
> Jeremy
> 
> 
> 
> On Tue, May 14, 2013 at 1:24 PM, Ted Gould <ted@xxxxxxxxxx> wrote:
> 
>         
>         I don't see any reason that this is LGPL incompatible.  It
>         just means that the app author needs to provide sources for
>         the library that they include.  Just like I can provide a
>         binary distribution on a CD and then provide sources
>         separately.
>         
>         There is no plan at this time to include Mono in the base
>         image.  That of course can change, but nothing currently
>         requires it that would justify including it.  Most of the apps
>         that are being developed using Mono for iOS and Android
>         currently use the shaped binary mode of Mono to create a
>         native executable.  I would expect that Mono using apps would
>         do the same thing on Ubuntu.
>         
>         Ted
>         
>         
>         
>         On Tue, 2013-05-14 at 10:17 -0400, Jeremy Bell wrote: 
>         
>         > Thanks Ted for your more clear answer. This is most
>         > unfortunate. I would have thought that, if any mobile OS
>         > would be LGPL friendly, it would be Ubuntu. Unfortunately if
>         > it is truly BYOD, it is once again impossible for apps to
>         > comply with the LGPL license of third party libraries. 
>         > 
>         > 
>         > Is there any possibility of the Ubuntu team rethinking their
>         > position on this? Large swaths of third party libraries are
>         > licensed under the LGPL and would quite effectively be
>         > excluded from use in Ubuntu mobile apps, where the same
>         > libraries would be perfectly fine in desktop apps. Why
>         > exclude them from mobile and not desktop? I don't see any
>         > difference between mobile and desktop apps beyond layout/UX
>         > needs, which have nothing at all to do with shared library
>         > dependencies.
>         > 
>         > 
>         > I realize that BYOD is the new norm in app packaging
>         > everywhere, and that the LGPL is incompatible with this
>         > environment, but there are quite a few useful, mature LGPL
>         > licensed libraries out there. But, assuming you don't change
>         > your mind, would you at least be willing to include the mono
>         > runtime in the "base image" you mentioned? This would allow
>         > easy porting of, for example, various MonoGame games that
>         > currently run on various platforms, from iOS, Android,
>         > Windows 8, etc.. 
>         > 
>         > 
>         > Regards,
>         > Jeremy
>         > 
>         > 
>         > On Tue, May 14, 2013 at 8:51 AM, Ted Gould <ted@xxxxxxxxxx>
>         > wrote:
>         > 
>         >         
>         >         We expect that applications that need sophisticated
>         >         dependency schemes will include those dependencies
>         >         in their own packages.  There will be a base image
>         >         that everyone can depend on, but beyond that, you'll
>         >         need to BYOD (bring your own dependency).
>         >         
>         >         There'll be a difference between packages that are
>         >         part of core Ubuntu (the archives) and those that
>         >         are distributed via the Software Center.
>         >         Applications in the archive will continue to have
>         >         the rich dependencies.
>         >         
>         >         All of this is under the title of "Click Packages"
>         >         and is being discussed at vUDS in a few hours:
>         >         http://summit.ubuntu.com/uds-1305/meeting/21760/foundations-1305-click-package/ 
>         >         
>         >         Ted 
>         >         
>         >         
>         >         On Tue, 2013-05-14 at 08:45 -0400, Jeremy Bell
>         >         wrote: 
>         >         
>         >         > I tried asking this question on the forums and the
>         >         > IRC channel, but haven't been able to find someone
>         >         > with the right answer.
>         >         > 
>         >         > I am researching whether it would be possible to
>         >         > distribute a shared library/runtime package on the
>         >         > Ubuntu software center for distribution on the
>         >         > phone and tablet versions of ubuntu. And
>         >         > additionally, whether mobile apps distributed
>         >         > through the software center can take dependencies
>         >         > on these shared library/runtime packages, such
>         >         > that they are automatically installed when the
>         >         > user installs the app.
>         >         > 
>         >         > I assumed so, as desktop apps can do this, and it
>         >         > appeared to be the intent to share the same
>         >         > ecosystem with the desktop app center.
>         >         > 
>         >         > For example, this would allow distribution of apps
>         >         > using alternate languages and runtimes, such as
>         >         > ruby, python, or Mono/.net with platform bindings.
>         >         > In my case, I am interested in using Mono, which
>         >         > is licensed under LGPL, and so the shared library
>         >         > approach would be the only way to distribute my
>         >         > app without it falling under the category of
>         >         > "derivative work" in the license. Note that in the
>         >         > case of Mono, the mono executable may be needed in
>         >         > addition to the shared libraries to run the app.
>         >         > 
>         >         > So this boils down to three questions:
>         >         > 1) can developers distribute shared
>         >         > library/runtime packages as is done on the
>         >         > desktop, e.g. the mono package on the desktop.
>         >         > 2) can apps take dependencies on these packages
>         >         > and have them auto installed?
>         >         > 3) once installed, can users overwrite shared
>         >         > libraries installed on their device with their own
>         >         > versions? It's ok I think if they have to unlock
>         >         > their phones first or tether them to a pc, etc...
>         >         > This is required for compliance with the gpl/lgpl.
>         >         > 
>         >         > Thanks!
>         >         > Jeremy
>         >         > 
>         >         
>         >         
>         >         
>         >         
>         >         
>         >         --
>         >         Mailing list: https://launchpad.net/~ubuntu-phone
>         >         Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>         >         Unsubscribe : https://launchpad.net/~ubuntu-phone
>         >         More help   : https://help.launchpad.net/ListHelp
>         >         
>         > 
>         > 
>         > 
>         > 
>         > 
>         > -- 
>         > 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™
>         
>         
>         
>         
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> 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™

Attachment: signature.asc
Description: This is a digitally signed message part