Project

Profile

Help

Task #4080

Licensing Options for Plugin Writers

Added by bmbouter about 1 year ago. Updated 6 months ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
No
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

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?

History

#1 Updated by richardfontana about 1 year 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.

#2 Updated by osapryki about 1 year 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).

#3 Updated by bmbouter 12 months 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.

#4 Updated by ttereshc 12 months ago

  • Tracker changed from Issue to Task
  • % Done set to 0

#5 Updated by amacdona@redhat.com 11 months ago

  • Subject changed from Licensing Options fo Plugin Writers to Licensing Options for Plugin Writers

#6 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF