License text

[andbz]

Hello,

Could you please provide the exact license text for Python-style license or a link to check it? The LICENSE file only states:

The python-ldap package is distributed under Python-style license. + Standard disclaimer.

Thank you.

[encukou]

That's problematic. As Michael, one of the original authors, said on the mailing list:

Mentioning a Python style license was [bad] for two reasons:

1. It is an obstacle to incorporate python-ldap into Python's standard lib.

2. It's not precise enough as you already said.

Mainly the term "Python style" was used to express that you should be able to do whatever you're allowed to do with Python.

The two authors (David and [Michael]) writing most of the code could agree on a quite liberal open source license. But since we did not insist on written statements to agree upon a license for the few contributions made by others we would have to ask all contributors. Most of them are not subscribed to the list anymore I guess.

Frankly I'm not sure what to do to clarify this unfortunate situation.

[spectejb]

@encukou - I definitely agree it is problematic but it may be worth exploring whether the list of contributors is manageable for this specific repo. Without a specific license identified, people may be unable to use it at all because they are unaware of what requirements must be followed.

If you need a recommendation that would enable the most people (individuals and companies) to benefit from python-ldap, you could add a permissive license like MIT.

[encukou]

may be worth exploring whether the list of contributors is manageable for this specific repo

For me, it's unfortunately not manageable. There is no "list". Note that the project predates this repo. In SVN, patch contributors weren't even tracked – only committer usernames are recorded.

If anyone wants to tackle this, I won't stand in the way.

[ddevault]

In a situation like this, I would recommend picking a license which can be interpreted as matching the text in that file - e.g. PSF-2.0 - ideally a permissive one to avoid stepping on toes, and just switching to it. Then, if someone complains, you can just git blame all their contributions and mark them for a rewrite (I expect no one to complain).

[eli-schwartz]

At the very least you can and should explicitly clarify a license for all reachable contributors, and mandate it going forward. If you're concerned that the new license is incompatible with the current non-license, dual-license everything.

Eventually you'll be able to have a better idea of what still needs doing, and you have the option of just rewriting the parts that are still under "unclear license".

No need to throw the baby out with the bathwater, or give up out of hand.

[encukou]

Thanks for the suggestions, but I don't really want to wait for someone to complain if that complaint can be a lawsuit :) Note that you can't “git blame all their contributions”. The project was migrated from SVN which lacks autorship information. The problem is, again, in listing contributors, not (yet) reaching them.

[eli-schwartz]

I don't recommend giving people the opportunity to complain, hence why I suggested dual licensing under "the old license text" and "explicitly license XXXX" so that the overall state improves as time goes by, rather than deteriorates.

Can you think of even one reason why that might have any downsides?

[tiran]

I strongly suggest to involve a lawyer who is an expert in OSS license before we take any action.

[Fnux]

I strongly suggest to involve a lawyer who is an expert in OSS license before we take any action.

I think we can apply 'common sense' here, in all good faith, and try to keep things as simple as possible. Both Drew's and Eli's options sound sane from my point of view.

@encukou I fear that this issue will stay open/unresolved forever if we/you don't make a decision or plan to go forward. This issue blocks a few things on my side, and will force me to move away/rewrite if no workaround is found.

[tiran]

I think we can apply 'common sense' here, in all good faith, and try to keep things as simple as possible. Both Drew's and Eli's options sound sane from my point of view.

@encukou I fear that this issue will stay open/unresolved forever if we/you don't make a decision or plan to go forward. This issue blocks a few things on my side, and will force me to move away/rewrite if no workaround is found.

No, we really need legal advise from a lawyer here. You wouldn't use common sense and a Google search to perform a heart transplant operation either, would you?

If you truly care about license issue then please get legal advise from a professional. Otherwise it's just window dressing. I might be able to get legal advise from a company lawyer but that may take a while.

[eli-schwartz]

I have got to say it's pretty shocking to hear anyone claim that you need to purchase the advice of a lawyer in order to figure out whether dual licensing works.

This is not exactly a novel concept, you're hardly the first people to ever need to relicense a project. My recommendation is very much decidedly not the same as the YOLO advice from Drew to "just tell people you're changing the license and hope no one complains" (which is definitively not legal, you don't need to ask a lawyer about it).

Dual licensing is a perfectly sound legal concept. All you're doing is adding additional permissions. The license continues to be "The python-ldap package is distributed under Python-style license" but you add the additional text "for all future contributions, you may additionally choose to accept the software under the $LICENSENAME instead". And over time you add the additional license terms "for past contributions by XXX consenting contributor, you may accept those contributions under $LICENSENAME".

You may then collect more opt-ins to dual-license code under $LICENSENAME from various contributors. It is still not legal to redistribute the software under $LICENSENAME due to it not being fully covered by that license (and thus having no choice but to accept older contributions under the unclear license option, thereby forming a combined work that may be incompatible), but that was never the point. The point is to gradually collect relicensing info. And arguably, no one may use the software today at all, because the whole project is illegally licensed under "the We Have No Idea Public License" and different contributors have different ideas of what this means. As per the original issue.

You are certainly not making things any worse for yourself by adding a dual license unless you mean to suggest the entire legal concept of a dual license is invalid. I'd love to hear your reasoning, and there are numerous companies which would also love to hear your reasoning.

But claiming you aren't going to consider anything without first having someone find you a lawyer, sounds like an excellent way to stonewall and deflect, and make sure nothing ever happens. Sorry for sounding suspicious, but this stinks of weeks-old fish.

[encukou]

@eli-schwartz, Sounds reasonable. Could you open a concrete PR for your idea? The PSF license is a reasonable interpretation of "Python-style license", but something like MIT would be better if we go for dual-licensing.

The licence statement from original contributors is available, and all information I have regarding this issue them is present in this repository. Legally, my position is not much different from any other contributor. I do have control over what goes into the repo, but that's more of a technical detail than it seems.

If anyone wishes to contact all reachable contributors and clarify the licence with them, that looks like a good way to help this project. It's not something I want to do in my free time, but I'll be happy to help if something is truly blocked on me.

@fnux, if you believe it is OK to simply use the PSF-2.0 licence and wait until someone complains, go ahead!* I am not prepared to take that risk myself without a lawyer, but it's your risk to take; I don't see why I'm blocking you.

* (Obviously, none of this is legal advice and I'm not a lawyer.)

[Fnux]

You may then collect more opt-ins to dual-license code under $LICENSENAME from various contributors. It is still not legal to redistribute the software under $LICENSENAME due to it not being fully covered by that license (and thus having no choice but to accept older contributions under the unclear license option, thereby forming a combined work that may be incompatible), but that was never the point. The point is to gradually collect relicensing info. And arguably, no one may use the software today at all, because the whole project is illegally licensed under "the We Have No Idea Public License" and different contributors have different ideas of what this means. As per the original issue.

I think it's a safe/good plan to improve the situation and will eventually reach something that works for everyone.

[tiran]

But claiming you aren't going to consider anything without first having someone find you a lawyer, sounds like an excellent way to stonewall and deflect, and make sure nothing ever happens. Sorry for sounding suspicious, but this stinks of weeks-old fish.

Personal attacks are not going to change my opinion that we must get the advise of an expert first. Otherwise any change to the license situation can make the situation even worse. scio me nescire

[mvanderkolff]

Is this going anywhere? It would be nice if we could have clear licensing terms for this library.

Thanks!

[eli-schwartz]

I believe this is hard blocked on @tiran speaking with a lawyer to clarify e.g. whether dual licensing is legal or "can make the situation even worse".

As @encukou indicated an inability make this decision for the project ("Legally, my position is not much different from any other contributor. I do have control over what goes into the repo, but that's more of a technical detail than it seems.") I am of the opinion that opening a concrete PR for my idea is a waste of time unless the only person authorized to make such a decision indicates some degree of willingness to consider the idea.

Hence we are waiting for 7.5+ months (I do not care to imagine how much longer in the future it might be) for @tiran's lawyer before considering any attempt to make progress on proposing my industry standard dual license proposal.

[tiran]

Correction: I never said I want to get my (tiran's) lawyer involved. I said that I want to get the opinion of an OSS licensing expert first.

@eli-schwartz, did you find and contact an OSS license expert to assist and advise us?

[eli-schwartz]

No, we really need legal advise from a lawyer here.

I'm definitely not going to hire a lawyer on my own for this. Are you asking if I found one to work Pro Bono?

If you really think a lawyer is that important here then yes I'm pretty sure it means it will have to be your (tiran's) lawyer.

If your sudden switch from the word "lawyer" to "license expert" is meant to indicate a change of intent from your original statement about lawyers back in October, then please state exactly what your (current) requirements are?

[tiran]

My intention has not changed. I want legal advise from an OSS license expert. In most (if not all) countries legal systems are heavily regulated. It's just plain illegal to give legal advise unless you are an accredited lawyer. I was under the impression that this was obvious to everybody.

There are multiple organizations that provide legal support for FOSS pro-bono, for example https://www.softwarefreedom.org/ . I also said that I can involve the legal department of @encukou's and my employer.

[encukou]

@eli-schwartz: your dual-licensing idea (requiring a concrete licence for new contributions) still looks sound. The trouble with it is the "for past contributions by XXX consenting contributor" part, because we don't have authorship information for much of the project's history. That doesn't mean new contributions can't start using a better license; it does mean that, down the road, I don't see how the project can switch to only that new licence. Still, dual licencing for new contributions sounds like a step forward.

I won't be driving this, but let me know if I'm blocking you from getting that PR in.

[mvanderkolff]

https://mail.python.org/pipermail/python-ldap/2014q2/003374.html seems to be the best attempt at chasing down other contributors.

[encukou]

So, it looks like I will be driving this. Here's the PR for introducing a MIT licence for new contributions: https://github.com/python-ldap/python-ldap/pull/417

[stroeder]

Any particular reason why you chose "MIT license" and not considered Apache-2.0 license?

Don't get me wrong: I appreciate if this gets clarified. My personal opinion on this is that python-ldap should be distributed under a liberal license allowing everything for which python-ldap is used out there including non-free commercial products.

But given the hints here I wonder whether choosing the term "MIT license" is yet another ambigous trap: https://www.gnu.org/licenses/license-list.en.html#Expat https://www.gnu.org/licenses/license-list.en.html#X11License

Personally I'd strongly prefer Apache-2.0 license because I was adviced that this is one of the licenses which would allow added a module to Python's standard library. Would have to dig my mail archive to find a reference...

[encukou]

The actual licence for python-ldap is very specific:

https://github.com/python-ldap/python-ldap/blob/69867f5817bc81194fdb45fc478f7ec2b36f27cf/LICENCE.MIT#L31-L51

SPDX, opensource.org, and pretty much everyone but FSF/GNU call it the MIT licence. Yes, MIT the university has used other licences too, but at this point that's a historical detail.

The lawyer I consulted recommended MIT. IMO, Apache 2.0 is much more complex but doesn't add much benefit.

MIT-licenced code can be and is added to Python's standard library, see e.g. https://docs.python.org/3/license.html#expat (It is very unlikely that LDAP support would be added to the standard library, but the MIT licence is not a blocker.)