Thread: Re: License Question
On Wed, May 30, 2018 at 7:04 PM, Jamie Specter <jamie.specter@gmail.com> wrote: > I would love to use it in an Apache-licensed project but unfortunately, LGPL > licenses are not compatible with Apache 2.0. > > See here for more info: > https://www.apache.org/legal/resolved.html#category-x Is this true? this page leads to <http://www.apache.org/licenses/GPL-compatibility.html>, which says: """ This licensing incompatibility applies only when some Apache project software becomes a derivative work of some GPLv3 software, because then the Apache software would have to be distributed under GPLv3. This would be incompatible with ASF's requirement that all Apache software must be distributed under the Apache License 2.0. """ Is your work a "derivative" of psycopg, or it merely uses psycopg? If you only want to use it you should be fine. -- Daniele P.S. certain Postgres mailing list don't tolerate cross-posting. I don't know about pgsql-general, but I would avoid it anyway.
Great find, Daniele! That appears to be true for GPLv3 but not LGPLv3 which is included on the Category X list. (Have to love how complex licenses can get!)
From the Apache FAQs:
- Apache takes a strong approach against distributing any components under prohibited licenses (i.e. Category X), which includes LGPL. Therefore, we cannot even use LGPL licenses open source in the project. This appears to be regardless of linking.
- While Apache projects cannot distribute Category X components within their releases, a project can provide the user with instructions on how to obtain and install the non-included work if the component is only needed for optional features. In this case, optional means that the component is not required for standard use of the product or for the product to achieve a desirable level of quality. They recommend you ask, “will the majority of users want to use my product without adding the optional components?” In our case, it would not fit Apache’s definition of “optional.”
Unfortunately, GPLv3 license would require us to release the entire project as GPLv3 vs the other options that can be incorporated into an Apache project while keeping the project under the Apache license. (https://www.apache.org/legal/resolved.html#category-a and https://www.apache.org/legal/resolved.html#category-b).
I really appreciate the dialogue as we work on understanding the options and thanks for the tip on cross posting! I didn’t include pgsql-general on this response.
Best,
Jamie
On Wed, May 30, 2018 at 2:28 PM Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote:
On Wed, May 30, 2018 at 7:04 PM, Jamie Specter <jamie.specter@gmail.com> wrote:
> I would love to use it in an Apache-licensed project but unfortunately, LGPL
> licenses are not compatible with Apache 2.0.
>
> See here for more info:
> https://www.apache.org/legal/resolved.html#category-x
Is this true? this page leads to
<http://www.apache.org/licenses/GPL-compatibility.html>, which says:
"""
This licensing incompatibility applies only when some Apache project
software becomes a derivative work of some GPLv3 software, because
then the Apache software would have to be distributed under GPLv3.
This would be incompatible with ASF's requirement that all Apache
software must be distributed under the Apache License 2.0.
"""
Is your work a "derivative" of psycopg, or it merely uses psycopg? If
you only want to use it you should be fine.
-- Daniele
P.S. certain Postgres mailing list don't tolerate cross-posting. I
don't know about pgsql-general, but I would avoid it anyway.
On Wed, May 30, 2018 at 7:44 PM, Jamie Specter <jamie.specter@gmail.com> wrote: > Great find, Daniele! That appears to be true for GPLv3 but not LGPLv3 which > is included on the Category X list. (Have to love how complex licenses can > get!) > > From the Apache FAQs: > > Apache takes a strong approach against distributing any components under > prohibited licenses (i.e. Category X), which includes LGPL. Therefore, we > cannot even use LGPL licenses open source in the project. This appears to > be regardless of linking. Using a Python module doesn't constitute linking in the LGPL sense (IANAL, but read it often). So, in order to understand what we are talking about: what is that your project does? - It uses psycopg? - It modifies psycopg? - It redistributes psycopg? In the first case, to the best of my knowledge, and with the hundreds of proprietary or variously licensed projects which use psycopg, you can just use psycopg, which is a library and doesn't enforce a license on the programs using it. In the second case, we do want whatever improvement you made to psycopg to be available to any other psycopg user, thank you very much for them, and the LGPL is a great license to enforce that. All the above, furthermore, is about distribution, i.e. dumping the psycopg source code into a directory of your program and shipping it with the rest. Is that what you want? Because if a line in `requirements.txt` is fine (pretty much the industry standard), or a git submodule is fine, you can use that, which results in the user going there on github or PyPI and downloading his psycopg copy and we are all happy. You can also consider changing your license to GPL, why not? I'm just speaking for myself, however, not knowing what is your project, not knowing why it supposedly need a change in psycopg license, which has survived almost 20 years of multinationals lawyers nitpicking on it, is not so much of an incentive to do so. -- Daniele