kaptan
kaptan copied to clipboard
emre
BSD license text used in here deviates from standard BSD-3-clause (on a semantic level)?
Hi!
It came to my attention that while Kaptan intends to use the BSD-3-clause license judging from #11, the license text does not match official BSD-3-clause text. The difference is beyond cosmetics, but on a semantic level, e.g. Kaptan's version adds "and documentation" at three places.
As a result, systems who take licensing seriously for legal reasons currently have to treat Kaptan as having its one custom license, and I have seen one such case. Is that intended? @tony could you share where you got the license text from and whether that deviation was intended?
PS: I think that difference in license text is also why GitHub doesn't recognize the license as BSD, see:
Thanks and best, Sebastian
@hartwork Thank you, good catch!
I prefer that we stick to a standard license that is recognized and typical among python projects
Original ref: https://github.com/emre/kaptan/commit/f1f7166b20c202de864ac1371e94a89bd5a91720#diff-c693279643b8cd5d248172d9c22cb7cf4ed163a3c98c8a3f69c2717edd3eacb7
I believe I know why, this was used in Flask, where I got a significant influence at the time. Google this: "Redistribution and use in source and binary forms of the software as well as documentation"
I'm contemplating what to do. I think it'd be safe to just update the license.
In the mean time, can you think of any reason the language would cause conflict? Is it blocking you in any way from using the library?
@tony I appreciate your quick and positive reply, thank you!
I think it'd be safe to just update the license.
That would be great!
In the mean time, can you think of any reason the language would cause conflict? Is it blocking you in any way from using the library?
The practical conflict was that I am using a distribution of GNU/Linux that let's the user configure a license inclusion list to something like @FSF-APPROVED @OSI-APPROVED (..) and Kaptan has it's own license that is in neither set (at least not today) and hence a package that (I think) started depending on Kaptan was blocked during installation for license reasons and needed manual investigation. While the issue is defacto-fixed now on that box, if it had been original BSD-3-clause there would have been no error, no license reading and diffing, and so on. Not the end of the world (and not meant to be whining), but all goes away with plain BSD-3-clause for all users.
@hartwork This was autoclosed, let's see if GitHub updates the badge (we'll give it 24 hours). Ping me here if I forget
Do you need a pypi release as well, or is it okay as-is?
@hartwork This was autoclosed, let's see if GitHub updates the badge (we'll give it 24 hours). Ping me here if I forget
Nice!
Do you need a pypi release as well, or is it okay as-is?
I don't "need" one but if there was some I could (bump the version and) change the license from Kaptan to BSD in the distro package for everyone.
@hartwork I will leave a note here to update on PyPI - I believe I have access to publish there if I remember correctly (late by me)
and also as an update (night time by me)
https://img.shields.io/github/license/emre/kaptan.svg?fjewofjweo
[](https://github.com/emre/kaptan/blob/master/LICENSE)