[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gphoto-devel
Subject:    [gphoto-devel] Re: gPhoto2 licensing clarification (was Re: Introduction and Comments)
From:       David Brownell <david-b () pacbell ! net>
Date:       2000-08-20 11:51:11
[Download RAW message or body]

> From: Scott <scottf@gphoto.net>
>
> David Brownell wrote:
> > I've not seen the gphoto2 stuff yet; are these APIs done in
> > network-transparent ways?  I know that corba handles most of
> > the functionality you'd described as "core" (except defining
> > camera-specific apis and policies), and that such protocol
> > level interop is a common way to let software with all sorts
> > of crazy constraints (licensing, platforms, etc) interoperate.
>
> the core also provides other misc functions as well. the best way to do
> it would be to put a CORBA layer on top of the core and just let the
> core do what it's good at. This would also make the CORBA layer easier
> to design and implement.

The point would be (for me) to make it easier for implementations to talk
to each other regardless of who implemented them, how, licensing strings,
and
so forth ... not to complicate things by adding a second integration
framework.
It sound like you think you're past the point where you could easily adopt
alternative approaches, though.

Tradeoffs for folk who can't/won't use copylefted code would be simplified:
since significant chunks of the core (CORBA) would be widely available even
with proprietary licenses, or are "pure documentation" (better interface
specs, in IDL; and naming policies for camera discovery) ... they'd have
a lot less to worry about.



> As for network-transparency, it should be. I am not familiar enough with
> CORBA though to make a definite statement either way though. If you drop
> me a separate email, i'd be happy to run through it with you.

I'd expect that if you don't know _today_ that it's network-transparent,
then it isn't ... designs focussed on library-style linkage accumulate
all sorts of assumptions about shared state and concurrency, even with
the best of intentions.  Those assumptions are good to get rid of (or at
least identify and document) even in library-style designs.

That said, I'm unlikely to have time to investigate this new library for
a while yet.  I couldn't find even a prototype on the gPhoto website; I
had to poke around quite a bit before I found out that there's now a
gphoto.sourceforge.net project, whose homepage is not www.gphoto.org ...


> > > Here is the licensing that gPhoto2 is currently under is:
> > > - the gPhoto2 core is LGPL
> > > - the gPhoto2 camera libraries are unspecified.
> > ... and I think you said there's to be a GPL'd front end.
> > Isn't that part of gphoto2?  Decoupling those would be a
> > pretty major redefinition of the project.
>
> Well, the front-end is already decoupled.

So it's a major redefinition, and anyone downloading "gPhoto" would
no longer be getting a user interface integrated with camera support.

This is confusing.  Have you thought about using a different name for
this "core" then, and letting "gPhoto" continue to be used to identify
a user interface bundled with a usefully large set of camera interface
code?  Users Would Be Surprised to see a rev 2 delete essential features.

Heck, the gPhoto roadmap on the website doesn't even mention anything
after 1.0, and it says the current development target is 0.6 ... no
wonder I'm scratching my head !!

- Dave


>    The gPhoto2 core does not
> depend at all on the front-end (one of the major benefits of the
> redesign). it was designed so that ANY front-end can be written and use
> the core/camera libraries. it's possible to write a KDE/QT, Tk, ncurses
> (!), and whatever other front-end you'd like to write. the gPhoto2 core
> and camera libraries' only purpose is to get the pictures off of and to
> configure the camera *easily*. That's why gPhoto2 is more of a driver
> framework than an application framework.
>
> there is already a GPL'd GTK+ interface that uses the gPhoto2 libraries
> that i wrote. There is another one in-the-works as well that will have
> many more features (Jae is working on that one). We have had people
> interested in writing a KIO Slave driver that uses the gPhoto2 libraries
> so that people can open their images directly from their KDE
> applications. There was also interest in a gnome-vfs driver that
> provided a handler for "camera:". There's been inquiries from all sorts
> of different projects that use different toolkits/platforms to use the
> gPhoto2 libraries.
>
> > Also, gPhoto2 camera libraries derived from gphoto 0.4.x code
> > will normally be remaining GPL ... and would, I hope, be
> > part of the "gPhoto2" package one will download.
>
> personally, i'd prefer to keep the camera libraries GPL'd so that we are
> guaranteed that *only* free software can link directly to them
> (guaranteeing a free "core"). I'd also prefer to allow for non-GPL'd
> applications to use the gPhoto2 core though so that we can push it as an
> open and free standard for digital camera access on all platforms that
> it runs. those are my opinions though. :)

[prev in list] [next in list] [prev in thread] [next in thread]