Disclaimer: the following is my opinion and not intended to be legal advice -- consult a licensed attorney for that.
In general, using psycopg2/PostGIS with your GeoDjango project does not make it subject to the GPLv2. I'll speak about PostGIS since others have already addressed the question as it relates to psycopg2.
Unlike the other geospatial libraries that it uses, GeoDjango does not 'link' to PostGIS. PostgreSQL is what is linked to the PostGIS library (liblwgeom.so), and in doing exposes a wide selection of SQL functions. GeoDjango calls the SQL functions and uses their output to do what it does. Let's examine term 0 of the GPLv2:
This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.
...
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
Because GeoDjango is just running PostGIS (by calling its public SQL API functions), and the output of PostGIS is geospatial data and/or numeric values (not source code based on PostGIS) it's clear to me that GeoDjango (or an app built with it) is not covered by the GPL because it is not copying, modifying, distributing, nor a derivative work of GPL code.
Notice I said "in general" at the beginning. If you are distributing your GeoDjango application including psycopg2 and PostGIS, then your code may be subject to the GPL. For web applications this is typically not a problem, because the code is almost never distributed to others like traditional shrink-wrapped software. The code is running on your server, and the only thing your distributing is output of your program (e.g., HTML) to the users (sidebar: this is why I avoid GPL-licensed JavaScript libraries like the plague). This is how Google can keep their heavily-modified Linux kernel to themselves, because their modifications never leave the servers at Google.
Bottom-line: if you are actually selling/distributing a GeoDjango application to end-users (they get a copy of the application), then do not include the GPL-licensed prerequisites to avoid triggering the licensing requirements on your proprietary code. In other words, install those libraries on-site so that you cannot be considered to be "distributing" GPL source/object code with your closed-source application.
Foreward: You need to ask your company's lawyers about this. Few of us are qualified to answer. Another option is to ask the owners of each of these projects what is and is not an acceptable use.
That out of the way, the license of your project is only affected by the licenses of works from which it is derived. A good test for this is how easily the supposed origin work could be substituted for an alternative.
PostGIS is gpl, but as it turns out, geodjango has support for MySQL and Oracle. If these other databases can work for your project, even if that causes some minor loss of functionality, ("queries are slow!?"), you are probably ok. Since psycopg2 is your interface to PostgreSQL, then if you substitute another db, you also are substituting psycopg2 for something else as well.
On the other hand, your project is likely to integrate rather tightly with Django. fortunately, the BSD license allows you create derivative works, so long as you follow some fairly friendly requirements.
仅使用提供的 API 从 Python 调用 psycopg （即，不与 C 代码链接，也不基于它的 C 模块）； 和
GPL 的所有其他要点均受到尊重（您提供一份副本 psycopg2 的源代码等等。）
Concerning psycopg2, the situation seems clear. From its LICENSE file:
Note that the GPL was chosen to avoid proprietary adapters based on psycopg code. Using psycopg in a proprietary product (even bundling psycopg with the proprietary product) is fine as long as:
psycopg is called from Python only using only the provided API (i.e., no linking with C code and no C modules based on it); and
all the other points of the GPL are respected (you offer a copy of psycopg2's source code, and so on.)
Are you or your client redistributing the code? If there is no redistribution, then your client (assuming they'll own the IP) won't need to provide source to anyone and thus no cause for concern with the licenses you listed.
发布评论
评论（5）
免责声明：以下是我的观点，并非法律建议——请咨询有执照的律师。
一般来说，在 GeoDjango 项目中使用 psycopg2/PostGIS 并不意味着它受 GPLv2 的约束。 我将谈论 PostGIS，因为其他人已经解决了与 psycopg2 相关的问题。
与它使用的其他地理空间库不同，GeoDjango 不会“链接”到 PostGIS。 PostgreSQL 链接到 PostGIS 库 (
liblwgeom.so)，并在此过程中公开了多种 SQL 函数选择。 GeoDjango 调用 SQL 函数并使用它们的输出来执行其操作。 让我们检查一下 GPLv2 的第 0 项：因为 GeoDjango 只是运行 PostGIS（通过调用其公共 SQL API 函数），并且 PostGIS 的输出是地理空间数据和/或数值（不是基于 PostGIS 的源代码），所以我很清楚 GeoDjango（或用它构建的应用程序） ）不受 GPL 保护，因为它不是复制、修改、分发，也不是 GPL 代码的衍生作品。
请注意，我一开始就说“一般而言”。 如果您分发您的 GeoDjango 应用程序包括 psycopg2 和 PostGIS，那么您的代码可能受 GPL 的约束。 对于 Web 应用程序来说，这通常不是问题，因为代码几乎不会像传统的收缩包装软件那样分发给其他人。 代码在您的服务器上运行，您分发的唯一内容就是向用户输出程序（例如 HTML）（侧边栏：这就是为什么我像瘟疫一样避免使用 GPL 许可的 JavaScript 库）。 这就是 Google 能够保留其经过大量修改的 Linux 内核的方式，因为他们的修改永远不会离开 Google 的服务器。
底线：如果您实际上向最终用户销售/分发 GeoDjango 应用程序（他们获得应用程序的副本），那么不要包含 GPL 许可的先决条件，以避免触发许可要求在您的专有代码上。 换句话说，现场安装这些库，这样您就不会被视为通过您的闭源应用程序“分发”GPL 源代码/目标代码。
Disclaimer: the following is my opinion and not intended to be legal advice -- consult a licensed attorney for that.
In general, using psycopg2/PostGIS with your GeoDjango project does not make it subject to the GPLv2. I'll speak about PostGIS since others have already addressed the question as it relates to psycopg2.
Unlike the other geospatial libraries that it uses, GeoDjango does not 'link' to PostGIS. PostgreSQL is what is linked to the PostGIS library (
liblwgeom.so), and in doing exposes a wide selection of SQL functions. GeoDjango calls the SQL functions and uses their output to do what it does. Let's examine term 0 of the GPLv2:Because GeoDjango is just running PostGIS (by calling its public SQL API functions), and the output of PostGIS is geospatial data and/or numeric values (not source code based on PostGIS) it's clear to me that GeoDjango (or an app built with it) is not covered by the GPL because it is not copying, modifying, distributing, nor a derivative work of GPL code.
Notice I said "in general" at the beginning. If you are distributing your GeoDjango application including psycopg2 and PostGIS, then your code may be subject to the GPL. For web applications this is typically not a problem, because the code is almost never distributed to others like traditional shrink-wrapped software. The code is running on your server, and the only thing your distributing is output of your program (e.g., HTML) to the users (sidebar: this is why I avoid GPL-licensed JavaScript libraries like the plague). This is how Google can keep their heavily-modified Linux kernel to themselves, because their modifications never leave the servers at Google.
Bottom-line: if you are actually selling/distributing a GeoDjango application to end-users (they get a copy of the application), then do not include the GPL-licensed prerequisites to avoid triggering the licensing requirements on your proprietary code. In other words, install those libraries on-site so that you cannot be considered to be "distributing" GPL source/object code with your closed-source application.
您可以直接询问 GeoDjango 的创建者 Justin Bronn。 他也是一名专门从事知识产权的律师。
http://djangopeople.net/jbronn/
You might ask Justin Bronn, the creator of GeoDjango, directly. He is also a lawyer that specializes in intellectual property.
http://djangopeople.net/jbronn/
前言：这个问题你需要询问你公司的律师。 我们很少有人有资格回答。 另一种选择是询问每个项目的所有者什么是可接受的用途，什么是不可接受的用途。
顺便说一下，您的项目的许可证仅受其衍生作品的许可证的影响。 对此的一个很好的测试是，假设的原始作品可以多么容易地被替代品所取代。
PostGIS 是 gpl，但事实证明，geodjango 支持 MySQL 和 Oracle。 如果这些其他数据库可以为您的项目工作，即使这会导致一些轻微的功能损失（“查询很慢！？”），您可能没问题。 由于 psycopg2 是 PostgreSQL 的接口，因此如果您替换另一个数据库，您也将 psycopg2 替换为其他数据库。
另一方面，您的项目可能与 Django 集成得相当紧密。 幸运的是，BSD 许可证允许您创建衍生作品，只要您遵循一些相当友好的要求。
Foreward: You need to ask your company's lawyers about this. Few of us are qualified to answer. Another option is to ask the owners of each of these projects what is and is not an acceptable use.
That out of the way, the license of your project is only affected by the licenses of works from which it is derived. A good test for this is how easily the supposed origin work could be substituted for an alternative.
PostGIS is gpl, but as it turns out, geodjango has support for MySQL and Oracle. If these other databases can work for your project, even if that causes some minor loss of functionality, ("queries are slow!?"), you are probably ok. Since psycopg2 is your interface to PostgreSQL, then if you substitute another db, you also are substituting psycopg2 for something else as well.
On the other hand, your project is likely to integrate rather tightly with Django. fortunately, the BSD license allows you create derivative works, so long as you follow some fairly friendly requirements.
关于psycopg2，情况似乎很清楚。 来自其 许可证文件：
Concerning psycopg2, the situation seems clear. From its LICENSE file:
您或您的客户是否重新分发代码？ 如果没有重新分发，那么您的客户（假设他们拥有 IP）将不需要向任何人提供源代码，因此无需担心您列出的许可证。
Are you or your client redistributing the code? If there is no redistribution, then your client (assuming they'll own the IP) won't need to provide source to anyone and thus no cause for concern with the licenses you listed.