Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

licensing review: drop non-commercial and no-derivates terms? #18

Open
dkg opened this issue Jan 13, 2023 · 13 comments
Open

licensing review: drop non-commercial and no-derivates terms? #18

dkg opened this issue Jan 13, 2023 · 13 comments

Comments

@dkg
Copy link
Contributor

dkg commented Jan 13, 2023

Over in https://bugs.debian.org/1028570, i observed that the licensing for these files is not compatible with the debian free software guidelines (DFSG).

Is it possible to relicense it from CC 4.0 BY-NC-ND to just CC 4.0 BY? or CC 4.0 BY-SA?

I contributed 015-arabic/* and I'm certainly fine with those files being relicensed in such a way. I'm not sure of the origins of the other files in question.

Without relicensing, it's going to be a challenge to ensure that the package's tests run correctly in Debian, since all build and test infrastructure in the project is intended to use only DFSG-free material.

@MartinThoma
Copy link
Member

The van run the tests without the sample files.

I have to think about changing the license. It might be that only the two of us have contributed so far.

@dkg
Copy link
Contributor Author

dkg commented Jan 13, 2023

Not sure what you mean by "the van run the tests" -- can you elaborate? Are you saying i should just run the tests without the sample files? I assume there will be less coverage in that case.

If it's possible to change the license, that would simplify matters a lot for me. Thanks for considering it!

@dkg
Copy link
Contributor Author

dkg commented Jan 13, 2023

fwiw, the scope of coverage is already limited because debian test suites don't use the internet at all , and we have a patch to disable the network-reliant tests. The more the tests can be done on local copies of files that share similar licensing terms to the software itself, the more likely we'll be able to have the full test suite run on all the different architectures that debian's testing infrastructure supports.

@MartinThoma
Copy link
Member

I don't see the point of running the tests on different architectures as this is all about Python. If (and only if) it works for any architecture with a given Python version, it will always work for all architectures with that Python version.

@MartinThoma
Copy link
Member

Or in other words: pypdf runs its tests on Python 3.6 - Python 3.11 (see GitHub CI) and officially supports 3.6 - 3.11 (see trove classifiers).

The main thing that might be interesting to test is stuff that requires additional packages (pycryptodome / Pillow) to check if the Debian packaging broke anything 🤔 I'm not sure how that actually works.

@MartinThoma
Copy link
Member

I hope I find the time at the end of the day to go over all files / make up my mind if this change of license is possible / a good idea.

The license you propose would be more permissive, but people could sell the stuff in there without having ever contributed, right?

@dkg
Copy link
Contributor Author

dkg commented Jan 15, 2023

Yes, with standard CC BY licensing it would be completely permissive. with CC BY-SA it would be closer to a copyleft situation: anyone transmitting the file to anyone else would need to "share alike".

@dkg
Copy link
Contributor Author

dkg commented Mar 1, 2023

Any progress on this? In debian, i've moved ahead by just dropping tests on these sample files, but if they get a DFSG-free license, i'd be happy to ship them as a corpus and the nexpand the pypdf test suite; or we could include them as a "second tarball" for the source package for pypdf directly.

@MartinThoma
Copy link
Member

Sorry, I forgot this one. Let's go through it:

@mergezalot
Copy link

Hello @MartinThoma,

yes. CC 4.0 BY-SA for https://github.com/py-pdf/sample-files/tree/main/018-base64-image is fine.

regards

@joeywang4
Copy link
Contributor

Hi @MartinThoma,

Sure, that's fine.

@ediamondscience
Copy link
Contributor

@MartinThoma It's fine with me too.

@dkg
Copy link
Contributor Author

dkg commented Mar 10, 2023

@mtd91429 can you follow up here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants