License Considerations for Python Module
jacobagilbert opened this issue · 19 comments
Currently this repository (housing the specification AND the example python module) is licensed under Attribution-ShareAlike (CC BY-SA 4.0) however even the originator of this license discourages its use for code.
I believe the specification being CC licensed makes sense, however we should probably consider a GPL variant for the python module. Given this is simply a reference implementation to access an open source specification, I don't think there are any real concerns with this code being used commercially... however we may want some copyleft guarantees.
Summarizing my thoughts:
- The CC license is exactly the right thing for the specification, but when I selected it originally, I hadn't planned on merging code into this repo, and after we did that, it just didn't occur to me to re-assess.
- I very much agree, the CC license is not appropriate for the Python code.
- I'm generally against maintaining two separate licenses in a single repo. Is it possible? Yes. Can be it confusing and painful? Also yes.
- I think splitting the code out into it's own repo is still the best remedy for our issues with the spec / code intermingling (likewise with the spec releases getting held-up by the code not being up-to-date). I know @Teque5 was not a fan of that, though.
- @jacobagilbert suggested submoduling the code, which I think is a reasonable compromise.
- In terms of the license for the code, I would say GPLv3, which enforces both the Attribution and ShareAlike clauses we currently have on the CC license.
One reason this came up was because I was trying to select an appropriate license for a new piece of software. In the spirit of making the lawyer step easier, I said to myself, if I select a license that is identical to other stuff that is related, then that's one less piece of legalese that will have to be reviewed by lawyer types -- in any organization (not just my own).
That's why I first considered selecting CC for my software, and then determined that it was in appropriate.
Anyway, that same rationale could be used to select a license for the python code -- if it's identical to whatever python or numpy is using, then it's just less to deal with at legal review time, for everyone (well, for all commercial enterprises that want to consider using it).
If the code is a reference implementation, and we want non-GPL code to adopt SigMF, then I would think a more permissive license would be useful.
@bhilburn wrote:
@jacobagilbert suggested submoduling the code, which I think is a reasonable compromise.
At first I agreed, that a submodule would be a nice compromise -- but then I thought, "Which is the sub?"
Assuming that the python code changes more often than the spec (which I think is a good assumption) then if the python-repo were the submodule, then the spec-repo would need new commits in order to reference the latest python.
If the spec-repo were to be the submodule, then it feels like the spec isn't the General Contractor around here, but instead just a sub. Maybe there's nothing to that feeling and it should be disregarded though.
I have mentioned before that I hope to someday contribute a MIDAS-to-SigMF converter. One complication I found was that the bluefile.py I got from another github repo is LGPL. My plan was to include (in that same tools/ directory) a LICENSE_bluefile.py.txt with the intent to redistribute that file under that file under that license -- but I really don't know what I'm doing in this domain.
Regardless, the possibility exists (I hope) of covering different parts of a single repo with different licenses.
The python module would be moved into it's own repository and included as a submodule in the SigMF repo. Releases to the SigMF spec would update to point to the latest python module release.
It's not perfect but would be pretty functional. They don't need to (and are not now) in perfect lock step anyway.
If we split the repos, I don't think the code has to be a submodule. I almost think the repo with JUST the spec and the example corresponding SigMF logo file is the best way forward. The python implementation should just referenced as a good implementation of the spec. This can be expanded to other good implementations in GNU Radio, Rust, whatever. Within the python module we will clearly state it corresponds with the spec version X.Y.Z.
@gmabey We spent some time recently building a modern Bluefile <-> SigMF converter, but I wouldn't say it is of the highest quality yet. If it starts covering most use cases I will start the process for public release from my org. Might be a topic for a separate issue.
As for the license, we (my org) have decided LGPL is the best way to get code into the wild while keeping the cartoon Richard Stallman on our shoulder happy.
To summarize the latest developments with this as of December 2022:
- There seems to be a strong consensus that we split the python module out of the specification repository (or vice versa). If we intend to keep the same python package name (e.g.:
sigmf) It might make sense to keep the python module here and creategnuradio/sigmf-spec.gitthough I don't feel strongly about this - The spec will remain under the current CC license
- LGPLv3 is the leading license choice for the sigmf package, but this requires some additional consensus from the SigMF stakeholders.
- Issues will be tracked separately for code and spec (another benefit!)
- To submodule or not... pip should be the primary place folks get the python sigmf module from, so submoduling is probably not necessary. Looking for input here also though.
To summarize the latest developments with this as of December 2022:
- There seems to be a strong consensus that we split the python module out of the specification repository (or vice versa). If we intend to keep the same python package name (e.g.:
sigmf) It might make sense to keep the python module here and creategnuradio/sigmf-spec.gitthough I don't feel strongly about this- The spec will remain under the current CC license
- LGPLv3 is the leading license choice for the sigmf package, but this requires some additional consensus from the SigMF stakeholders.
- Issues will be tracked separately for code and spec (another benefit!)
- To submodule or not... pip should be the primary place folks get the python sigmf module from, so submoduling is probably not necessary. Looking for input here also though.
- Between these options I think having the spec called
sigmfmakes more sense. Maybe ii? In that case we can "move" the repo and it should preserve history, wiki, et cetera.
i.sigmfandsigmf-spec
ii.sigmfandsigmfpy
iii.sigmfandpysigmf
iv.sigmfsigmf-python - k
- k
- k
- I always find submoding a pain & confusing for new users so let's not.
I can't imagine a ton of people will be cloning the spec repo, so doesn't make much difference if we submodule or not
Regarding submodule, I lean in this direction of not including it in the spec repo as well.
Of those choices @Teque5 either sigmf-spec and sigmf, or SigMF and pysigmf seems to make the most sense to me. I lean toward keeping the spec repo as-is.
We can definitely preserve git history with a new repository, its the issues and stuff that will need to change for the python module.
LGPL for the code is good by me.
Also, I think the spec repo (this one) should remain unchanged in name.
I agree keeping this (spec) repository name as a preference.
How do we feel about changing the name of the python module to pysigmf? I think it is conventional for the name of the repo to match the package. I guess we could have a git repo python-sigmf which contained the python module sigmf and it would not be too confusing.
pysigmf definitely clears up any ambiguity
is everyone in favor of keeping the python module the same -- like import sigmf? I am; I hate those pesky two wasted characters for modules like pymongo, pyside, pysword, pyclustering not to mention numpy and scipy LOL.
Actually, I've never used pysword or pyclustering -- I just looked them up har har.
No seriously I don't object to the name numpy but I do like import sigmf in which case I don't agree that the new repo name be pysigmf, since in my mind that would imply import pysigmf.
How about sigmf-python?
I do prefer import sigmf myself... sigmf-python for the new repository name is also reasonable as far as I am concerned. It would be nice not to break pypi / pip / everyones everything using sigmf.
Yea I would support that too
Done. https://github.com/gnuradio/sigmf-python
I am going to wait for the final merge requests related to the python module to be closed out before I make this move (#261, #262)
I do prefer
import sigmfmyself...sigmf-pythonfor the new repository name is also reasonable as far as I am concerned. It would be nice not to break pypi / pip / everyones everything usingsigmf.
Regardless of the project name we will still be using import sigmf and pushing to that same pypi project.