Task #4080
closed
Licensing Options for Plugin Writers
0%
Description
The state of things¶
Pulp3 has two Python software packages. One is the "core" which provides the HTTP API for users to use, and the other is a "plugin API" which is Python API that "plugin writers" will import into their plugin package and use.
pulpcore - the core, depends on nothing.
pulpcore-plugin - the Python plugin API. It provides lots of objects, e.g. Artifact or RepositoryVersion. It has a Python dependency on pulpcore-plugin.
Both packages ^ are licensed as GPLv2 + Common Cure
Plugin writer usage of GPLv2 licensed code¶
Plugin writer's would both "use" and "subclass" plugin-API code (the GPLv2 code).
Use¶
Plugin writer's code would "use" code from the plugin API as-is with code statements like:
from pulpcore.plugin.models import Artifact
my_artifact = Artifact(data=data).save()
Subclassing¶
Plugin writer's code would "subclass" from the plugin API objects.
from pulpcore.plugin.models import Content
class MySubclassedNewContentObject(Content):
field1 = ...
field2 = ....
Who is distributing the plugin code?¶
The plugin writers distribute their plugin code directly to their users. The pulpcore and pulpcore-plugin packages need to be present for that code to work.
Questions from plugin writer¶
Assuming a plugin writer's code both "uses" and "subclasses" a GPLv2 asset from Pulp's plugin API, may a plugin, be licensed with a non-GPL license, e.g. MIT or Apachev2?
Updated by richardfontana over 5 years ago
I consider it clear that a plugin to a GPLv2-licensed project could at least use (a) GPLv2 itself, or (b) a GPLv2-compatible open source license, such as the MIT license. There remains a question whether the plugin could be proprietary, or could use a GPLv2-incompatible open source license. One way to address that would be to declare explicitly that GPLv2 does not extend beyond the plugin interface.
Updated by osapryki over 5 years ago
I consider it clear that a plugin to a GPLv2-licensed project could at least use (a) GPLv2 itself, or (b) a GPLv2-compatible open source license, such as the MIT license. There remains a question whether the plugin could be proprietary, or could use a GPLv2-incompatible open source license. One way to address that would be to declare explicitly that GPLv2 does not extend beyond the plugin interface.
Disclaimer: I'm not a lawyer.
AFAIK it's not entirely true. License compatibility means that a project licensed under GPL license can use project licensed under other compatible license. However if a project is based (depends) on GPL-licensed code it has to be released under GPL license as well.
Which simply means that as a pulp plugin developer I cannot release my plugin under any other than GPL v2 license (including permissive licenses like MIT, BSD or Apache-2.0).
Updated by bmbouter over 5 years ago
- Description updated (diff)
IANAL
@richardfontana, I didn't adequately describe the issue the first time. I rewrote it just now if you can take another look. I think the subclassing aspect is significant from what I'm reading here so I clarified the question.
AFAICT, since all plugins must subclass to work, all plugins will be GPLv2. If that's the case, that is unfortunate because subclassing is intended only as mechanism of use in our Python API. We never considered plugin code a derivative work as a goal. We're used more like a library, that just happens to use subclassing because ... Python.
Given all ^, is issuing a statement that GPLv2 is not intended to extend beyond the plugin interface still viable? That aligns most closely with the community goals of reducing plugin writer friction including licensing friction.
Updated by ttereshc over 5 years ago
- Tracker changed from Issue to Task
- % Done set to 0
Updated by amacdona@redhat.com over 5 years ago
- Subject changed from Licensing Options fo Plugin Writers to Licensing Options for Plugin Writers
Updated by bmbouter over 3 years ago
- Status changed from NEW to CLOSED - WONTFIX
Since we are not lawyers, I now believe we should not be making a recommendation on re-licensing paths. We provide the default of the same license, and if users are interested in re-licensing they need to understand the ramifications themselves.
.