Re: Using the invoice system - government rules

["Chris Travers" <..hidden..>]

On 10/30/07, John R. Hogerhuis <..hidden..> wrote:

> > Adding a dependency to a GPL v3 project would complicate license
> > issues.  In particular I am not clear how GPL v3 section 7, paragraph
> > 2 could be applied to BSD-licensed code* in some of our other
> > dependencies, so I don't know if it is a good idea for the project to
> > become tied to KT.
>
> I guess that question hinges on whether using a GPL v3 web service
> from GPL2 code triggers the linking provisions of GPL 2, since the
> access would be over the network via SOAP. I don't know the answer to
> that off the top of my head.


The GPL v2 has no linking provsion.  Even the FSF agrees that use of
web services is safe. Although IANAL I would further suggest that you
refrain from using any other copyrighted elements such as graphical
design themes and the like from the GPL v3 application because that
would seem to be entering an area that is more obviously dangerous.

>
> >
> > * This paragraph covers "relicensing" of portions of the covered work,
> > basically requiring the ability to change the license on any of our
> > depencies to the base GPL v3 + 7(3) additional terms without asserting
> > any copyrights of ones own.  This would be applicable to PostgreSQL if
> > and only if we could distribute PostgreSQL
>
> I'm confused about the PostgreSQL licensing angle. Why relicensing?

Unlike the GPL v2, the GPL v3's definition of corresponding source requires
1)  That all dynamically linked subprograms that the software is
designed to require are included and
2)  That this is released as a single work, governed by the GPL v3.

If we are bound by the GPL v3, and we distribute any portion of the
program in any format other than the preferred form for making
modifications, then we have to b willing to release our entire
corresponding source (including all dependencies).  This means that
any of our dependencies must be relicensable under the GPL v3 with no
additional permissions by anyone who merely makes copies (and does not
modify the program).

My concern is that this would apply to PostgreSQL back-end modules,
possibly the main server, and certainly the client libraries, and that
such relicensing in the absence of modification would be contrary to
the BSD-style license that the project is released under
(historically, the license on the covered copyrights does not change,
but this does not prevent various parties from adding copyrighted
elements and attaching other restrictions to those original elements).
 Again, the Software Freedom Law Center's opinions don't address this
question except to advise against such relicensing.

> Are you saying that the incompatibility you are concerned about re: KT
> is incompatibility of PostgreSQL with GPL 3?

Note that this question doesn't affect connectors between applications
and would seem to cause problems only where fixed dependencies exist
(because there it becomes tempting to do things that could result in
trouble for downstream distributors).

I am saying I would want to see some real legal analysis addressing
the specific question of relicensing verbatim PostgreSQL code (without
modifications) before I would assume that they are compatible.

I am concerned that the licenses may not be compatible and that
various parties may be avoiding substantive questions on compatibility
because such problems were not intentional but resulted from
misunderstandings of what the BSDL-style licenses require.  I don't
think our project would be directly affected, but I would not want to
be seen as encouraging people to violate the rights of other software
developers (that could bring the wrong kind of attention to the
project).\

Note that it would become an issue if we wanted to distribute a shared
db dump of a kt/lsmb database since this could be considered object
code derivative of both projects.

AFAICS, this question doesn't matter regarding whether you are
developing a connector. LSMB is licensed GPL v2+, and the only problem
cases could be found (IMO) if graphical design elements were used from
both projects or if a shared db dump was distributed.
>
> > Finally, I think it is a bad idea for a community-developed project to
> > be dependent on a single-vendor product for certain sorts of
> > functionality.
> >
>
> Yep. I agree it would need to be abstracted in some way plugin or
> whatnot, and you would need to provide some simple storage of
> documents whether KT is there or not.

Agreed.
>
> -- John.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>