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

urwid LICENSE #41

Closed
tony opened this Issue Dec 18, 2013 · 40 comments

Comments

Projects
None yet
@tony

tony commented Dec 18, 2013

@wardi:

Is there any reason for the LGPL license on urwid? Would you consider changing it to a permissive license like MIT or BSD if there was a good reason?

@wardi

This comment has been minimized.

Collaborator

wardi commented Dec 18, 2013

@tony Yes, some time ago I switched from GPL to LGPL so that applications with any license could be built with Urwid. I'm interested to know how LGPL is not permissive enough for you.

@tony

This comment has been minimized.

tony commented Dec 20, 2013

Hi, Thanks for giving me a chance to respond!

I've been taking time to research licenses lately. I had a conversation about this in another project ScottDuckworth/python-anyvcs#32 (comment).

There was a time when I would stamp LGPL on everything. I thought that doing so would ensure that derived improvements would go upstream, while simultaneously allowing closed-source software to use my library.

What's more is, even the GNU website has an article saying Why you shouldn't use the Lesser GPL for your next library.. They go on to say:

"Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising “more users for this library” if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all.

But we should not listen to these temptations, because we can achieve much more if we stand together. We free software developers should support one another. By releasing libraries that are limited to free software only, we can help each other's free software packages outdo the proprietary alternatives. The whole free software movement will have more popularity, because free software as a whole will stack up better against the competition."

Why do I quote this? Because the notion LGPL is not permissive enough, or relatively permissive at all begs the question that it was permissive in the first place. GNU makes the jump from GPL to LGPL seem hyperbolic. According to what I've found it's not so simple.

At the time LGPL was created, we didn't have the same data on how people contribute to open source. My understanding of open source licenses and their repercussions were superficial at best. Here are some pitfalls on LGPL.

  1. Legal-ese, Contentious

    The license is a lot fine print, a lot of big ideas that (over the years) many have subjectively taken in their ideal way. I feel some people simply accepted that it's possible to include it in closed source software.

    The license isn't categorized as permissive, but copyleft. There is a requirement, should a certain condition be met, the changes must be made available.

  2. Derivative / Copy-left core could be harmful

    I need help finding a better word for this, but from what I understand, underneath LGPL's fine print is whether a project can be considered a derivative.

    Where is the concrete language creates a derivative?

    • Depending on the programming? How do we know?
    • Depending on the programming language, the code can be importing, included and packaged in many ways.

    There are so many possibilities and the wording is ambiguous. So far, I haven't found concrete assurance on what is/isn't an issue.

    Some pages on this:

  3. Risks / unknowns may scare potential developers away

    We don't see it when a coder or legal division decides to go their own way because LGPL posed a risk or was a hassle for them to understand.

    • To a person aware of law and avoiding legal conflicts, I think uncertainty could send people packing (point 2). I'll state some scenarios later in this.
    • As a layman, LGPL's legal writing is above my head. (point 1).
  4. "LGPL encourages upstream contributions"

    Do MIT / BSD / permissive licenses have a reputation for scaring people off? For being too simple and to the point? Easy to understand?

    Do people not give back to them? FreeBSD, Bootstrap, SQLAlchemy, Flask, Tornado are all permissive license. They are very active with many contributes.

    Does GPL/LGPL prevent contributions? Yes, it confuses and distracts people. Developers don't like the license once they read into it. Developers and projects purposely detour around it.
    http://www.freebsd.org/doc/en/articles/bsdl-gpl/gpl-advantages.html

    (An aside: not using GPL/LGPL doesn't make someone anti-GNU. It also doesn't make they don't use the tools, which are superb. FreeBSD uses GNU projects and GPL-licensed projects (https://wiki.freebsd.org/GPLinBase).

    It makes sense for GNU's own project and mission and building the code base that many of use. Outside of certain initiatives, the years have demonstrated open source has more colors and flavors. Projects have enjoyed great contributions, stability, features without the drawbacks of complex legal licenses and forcing redistribution of code changes. From what I see, GNU is an incredible software ecosystem, as are other GPL libraries? How many programmer's directly benefit from GNU and GPL projects while coding software that is unreleased, proprietary or permissive licensed?)

    Most people contribute back because a closed-source fork is too much maintenance to sync with the upstream. It feels good to patch. People care about their program, their code. They want it to be as useful as possible to people. They understand their component will be a piece of a larger project, it feels good to make a mark. That's more powerful and inspiring than create a rule on paper.

  5. Why it's not permissive (Part 1: Library Use)

    • What if I import from site-package/dist-packages as source?
    • What if I import as an egg?
    • What if I vendorize (including it in the source code of my project)?
    • What if I sublcass Urwid classes in my app?
    • What if I monkey patch urwid in my app?

    So far I haven't found anything official on python and LGPL.

    Here is a thread on twisted in 2004 about switching from LGPL to MIT because of concerns about subclassing:

    Question about Twisted's use of LGPL: http://twistedmatrix.com/pipermail/twisted-python/2004-May/007944.html
    Response from Glyph, lead architect of Twisted: http://twistedmatrix.com/pipermail/twisted-python/2004-May/007946.html

    Large software projects are aware of this ambiguity.

  6. Why it's not permissive (Part 2: Source copying)

    Copying source from other python projects is very help. A pocoo app may have a utility method I'd like to borrow.

    I may have an advantage to copy pieces of Urwid to an application piecemeal.

    AFAIK LGPL would definitely not allow this (without triggering derivitive clause). MIT / BSD would allow another python programmer to copy snippets as they please and attribute accordingly.

    I do it in my own apps:

Edit: numerous edits.

@dholth

This comment has been minimized.

dholth commented Jan 3, 2014

As I understand it the LGPL requirements are quite clear.

  1. your program is always a derivative of the library. if you use the library, you have to comply with the terms of the LPGL.
  2. do you have to distribute your source code under the LGPL to comply with its terms?
  3. subclasses: no
  4. editing the library's own files: yes
  5. incorporating greater than ten lines of the LPGL program into your program: yes
  6. make sure it is technically possible (but not necessarily easy) for the end user to replace the LGPL code

However I usually stick to the MIT license for my own projects.

@wardi

This comment has been minimized.

Collaborator

wardi commented Jan 5, 2014

@tony to actually make this change there are a bunch of contributors that would need to be contacted. Are you interested in creating a list of those contributors and how many lines they have contributed (and maybe last commit id etc)? I'd want to be careful to include people that contributed code even if that code has since been edited or moved by someone else.

I could send out the individual emails and collect the results.

@tony

This comment has been minimized.

tony commented Jan 6, 2014

@dholth : Where can I find a citation for those? I have yet to find anything concrete / authoritative on LGPL and python.

@wardi : Are you open to trying http://licenses.beberlei.de/? If not, let me know and I will proceed to collect the emails and commit information.

For reference: twbs/bootstrap#2054 + http://blog.jquery.com/2012/09/10/jquery-licensing-changes/ for prior license change examples.

@dholth

This comment has been minimized.

dholth commented Jan 6, 2014

Citation is [1]https://www.gnu.org/licenses/lgpl-java.html

On Mon, Jan 6, 2014, at 02:03 AM, Tony Narlock wrote:

[2]@dholth : Where can I find a citation for those? I have yet to
find anything concrete / authoritative on LGPL and python.

[3]@wardi : Are you open to trying [4]http://licenses.beberlei.de/?
If not, let me know and I will proceed to collect the emails and
commit information.

For reference: [5]twbs/bootstrap#2054 +
[6]http://blog.jquery.com/2012/09/10/jquery-licensing-changes/ for
prior license change examples.

Reply to this email directly or [7]view it on GitHub.
[208018__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNDUyNDYyMi
wiZGF0YSI6eyJpZCI6MjIyNjY1NTN9fQ==--8286cdbf64fb72efd0d4910c0a170bf96fe
da845.gif]

References

  1. https://www.gnu.org/licenses/lgpl-java.html
  2. https://github.com/dholth
  3. https://github.com/wardi
  4. http://licenses.beberlei.de/
  5. twbs/bootstrap#2054
  6. http://blog.jquery.com/2012/09/10/jquery-licensing-changes/
  7. #41 (comment)
@techdragon

This comment has been minimized.

techdragon commented Feb 20, 2014

As a user of urwid id much rather it be BSD/MIT or Apache v2. Id even do what I could to replace code if that became necessary as part of a re-licensing effort.

@wardi

This comment has been minimized.

Collaborator

wardi commented Mar 27, 2014

@dholth sorry I left this hanging for so long. Yes, http://licenses.beberlei.de/ seems like a good tool to use.

@geier

This comment has been minimized.

Contributor

geier commented Apr 3, 2014

So is the consensus that if I use the current version of urwid (and even subclass some of its classes) my whole project needs to be LGPL (and not MIT as it currently is)?

@wardi

This comment has been minimized.

Collaborator

wardi commented Apr 3, 2014

@geier no, I can't see the argument that subclassing causes the LGPL to apply to your code. Copying large portions of code seems to be the grey area.

I've tried to use http://licenses.beberlei.de/ last week to start switching urwid over to the MIT license but there hasn't been a response yet.

@tony

This comment has been minimized.

tony commented Apr 6, 2014

@beberlei: is the license site still operating? This project is looking to do a conversion to MIT.

@techdragon

This comment has been minimized.

techdragon commented Aug 18, 2014

@tony @wardi the code for the license change tool is available on github, if there is no prompt response, do we want to consider self hosting a copy of the tool? https://github.com/beberlei/license-manager

@shackra

This comment has been minimized.

shackra commented Aug 30, 2014

huh, I would say that having here somebody from the FSF for a rebuttal of this comment would be good idea instead of reading just one side's argument...

@horazont

This comment has been minimized.

Collaborator

horazont commented Aug 31, 2014

@tony tony referenced this issue Mar 19, 2015

Closed

License #17

@tony

This comment has been minimized.

tony commented Mar 19, 2015

@wardl Where does this stand?

@wardi

This comment has been minimized.

Collaborator

wardi commented Mar 20, 2015

@tony someone or some service need to contact all the contributors to get them to sign off on the license change.

@tony

This comment has been minimized.

tony commented Mar 26, 2015

@nyov nyov referenced this issue Jul 13, 2015

Open

urwid permissive relicensing effort #135

44 of 49 tasks complete
@nyov

This comment has been minimized.

nyov commented Jul 13, 2015

It's really nice to see the responses, especially so fast, and willingness of people to go with a permissive license (even though it's not everyone's cup of tea).
Great community, was worth my effort in writing the script ❤️

If anyone cares about the script used to get the repo statistics, it's a bit fugly but here it is: https://gist.github.com/nyov/5d085ec49d4497bb97ba

@jeblair

This comment has been minimized.

Contributor

jeblair commented Jul 13, 2015

I certainly don't want to argue with tony about his feelings on licensing. I'll just say that I am happy with urwid being licensed under the LGPL and I haven't seen any problems with that in practice (including its use with ASL licensed programs).

@nyov

This comment has been minimized.

nyov commented Jul 13, 2015

I've been on both sides of the fence myself.
In fact at times it's hard for me to prefer one over the other.

@nyov

This comment has been minimized.

nyov commented Jul 14, 2015

Half the contributors responded in under 6 hours, that is just awesome!

So far there is a chance this might be happening.
But the coin could quickly flip either way, with a few heavy contributors still on the fence.

@jeblair

This comment has been minimized.

Contributor

jeblair commented Jul 14, 2015

Also, if you really would rather use a non-copyleft license, you may want to consider the Apache license in preference to MIT. It, like the LGPL, has some patent protections that you would be giving up if you moved from LGPL to MIT.

@ssokolow

This comment has been minimized.

ssokolow commented Jul 14, 2015

But it's incompatible with the GPL 2.0 so, if you want to be compatible with "GPL 2.0 only" stuff, you need to license under "your choice of GPL 2.0 or later or Apache 2.0"

@horazont

This comment has been minimized.

Collaborator

horazont commented Jul 15, 2015

I agreed because I would also have contributed if the project had been under the MIT at that time. I view the transition critically though.

@tony

This comment has been minimized.

tony commented Jul 16, 2015

This LGPL stuff also causes complications with other libraries, a few that
come to mind are https://github.com/PySide/PySide, pygame and
https://github.com/libgit2/pygit2.

Sometimes well-intentioned devs coming from a background in compiled
languages mistakenly believe the permissiveness passes into the world of
interpreted languages. This simply isn't the case, since code sharing in
python and node, for instance, is more complicated than the simple linking
of a header file.

I emailed the Python Foundation about how LGPL is interpreted with python,
the reality is LGPL hasn't been tested in court (even with a compiled
language) let alone an interpreted language.

But it's incompatible with the GPL 2.0 so, if you want to be compatible
with "GPL 2.0 only" stuff, you need to license under "your choice of GPL
2.0 or later or Apache 2.0"

Is BSD with an optional patent exception (golang-style) compatible with GPL
2.0?

On Wed, Jul 15, 2015 at 3:22 PM, Jonas Wielicki notifications@github.com
wrote:

I agreed because I would also have contributed if the project had been
under the MIT at that time. I view the transition critically though.


Reply to this email directly or view it on GitHub
#41 (comment).

@ssokolow

This comment has been minimized.

ssokolow commented Jul 16, 2015

Is BSD with an optional patent exception (golang-style) compatible with GPL 2.0?

I'm not sure. What GPL 3.0 and Apache 2.0 offer is a patent pledge (a guarantee that the contributor will not exercise any patents they hold which may cover the code they contribute).

Whether that conflicts with the GPL 2.0 in a golang-style BSD license will depend on whether it runs afoul of the GPL's "you may not impose any additional restrictions on people to whom you distribute this" clause.

@aszlig

This comment has been minimized.

Contributor

aszlig commented Jul 16, 2015

I'm disagreeing with this, because I really don't see a problem with LGPL, especially for Python libraries, but maybe I'm wrong.

Let's say I'm working for a company and want to include urwid code in my proprietary software. If I'm going to only distribute .pyc or .pyo files or use other means to compile and/or obfuscate the results, including (L)GPLed source code is going to be a problem (which I'd certainly want as a free software author). Otherwise I just need to include the source code with the software I'm distributing.

And it won't be a problem at all if I'd only want to use the software in-house, it only applies if you distribute software, right?

Same applies for subclassing, as long as the code is available (usually it is anyway in an interpreted language).

@nyov

This comment has been minimized.

nyov commented Jul 16, 2015

So, while there are still outstanding responses, it's clear that even if they respond eventually, a relicensed release now would be somewhat crippled.

Whether to go through with it (and unpatching all the code) is something I'll leave others to decide and deal with.

[aszlig] Otherwise I just need to include the source code with the software I'm distributing.

I'm not sure whether that is true or not, but I know a BSD licensed python project which has rejected including or depending on LGPL'd code. Maybe because it presents issues further downstream in a library?

@aszlig

This comment has been minimized.

Contributor

aszlig commented Jul 16, 2015

@nyov: Which project is it and what is the reasoning behind this?

@ssokolow

This comment has been minimized.

ssokolow commented Jul 16, 2015

I believe the issue is typically fear over how the courts would define "library" and "object file" in an interpreted language (even more worrying lately, given the way the Oracle API copyrightability battle has been going).

Maybe MPL 2.0 would be a suitable compromise if MIT/BSD is off the table? It's explicitly compatible with LGPL 2.1+, GPL 2.0+, and Apache 2.0+ and it bounds the copyleft-ness on a per-file basis rather than per-library, which is less ambiguous in a non-C/C++ language.

@ids1024

This comment has been minimized.

Contributor

ids1024 commented Jul 16, 2015

Otherwise I just need to include the source code with the software I'm distributing.

You have to include the source code under the LGPL. If LGPL code is mixed with code under a BSD, MIT, etc. license, the resulting code base would have to be LGPL. As stated before, it is unclear if subclassing would legally count, and thus require any program subclassing classes from urwid to be licenced under the LGPL.

@jeblair

This comment has been minimized.

Contributor

jeblair commented Jul 16, 2015

"Ian D. Scott" notifications@github.com writes:

Otherwise I just need to include the source code with the software I'm distributing.

You have to include the source code under the LGPL. If LGPL code is
mixed with code under a BSD, MIT, etc. license, the resulting code
base would have to be LGPL. As stated before, it is unclear if
subclassing would legally count, and thus require any program
subclassing classes from urwid to be licenced under the LGPL.

Fortunately, I think that has been clarified in LGPL3. From section 0:

Defining a subclass of a class defined by the Library is deemed a mode
of using an interface provided by the Library.

So an application using an LGPL3 library is in the same position whether
it subclasses from the library or not, which is to say, one can
distribute the LGPL3 library, even in binary form, with the application.

At least, that's my reading of the situation, though I am not a lawyer,
and this is not legal advice.

@ids1024

This comment has been minimized.

Contributor

ids1024 commented Jul 16, 2015

@jeblair Well, that is good. Since urwid is LGPL 2.1 or any later version, that should make it fine for my current use and many others. (Though I too am not a lawyer, and won't guarantee that to anyone.) But @tony made some other good points in favor of a more permissive license earlier in this discussion, which are also worth considering, such as twisted going from LGPL to MIT due to how the license may apply to python code.

@garrison

This comment has been minimized.

Contributor

garrison commented Jul 16, 2015

The main reason I disagree with the licensing change is that (from my perspective) the points given above seem to create unwarranted Fear, Uncertainty, and Doubt about the LGPL. Surely each point raised is a legitimate question, but they should be reason to talk to a lawyer, not to try to relicense a project without having sought clarification. I myself am not a lawyer, but I see no reason why the LGPL should be unclear as applied to Python libraries. As @shackra mentioned above, the entire conversation here (perhaps until @aszlig's comment) seems pretty one-sided. It seems that nobody has attempted to contact one of the pro-bono lawyers in this community to seek clarification. (One example of such a law firm is the Software Freedom Law Center, where I was previously employed.) The conversation years ago in the Twisted project seems to have had no clarification from lawyers either, as best I can tell.

@horazont

This comment has been minimized.

Collaborator

horazont commented Jul 17, 2015

@garrison I agree with you entirely.

Do you have any remaining contacts to the Software Freedom Law Center or similar organizations? This matter should be settled by a professional taking a look, if it is possible to settle it at all. If it is not possible to settle this matter in the general case, that would also be a valuable thing to know.

@nyov

This comment has been minimized.

nyov commented Jul 17, 2015

I feel this might go nowhere fast here. I believe everyone should agree to disagree. Different people have different views and preferences in Licenses, for whichever reasons (be they informed or misinformed). It is unlikely that we can resolve this by converting everyone to prefer one license over the other, when it hasn't happened so far -- both licenses are very widespread.

If we say for a second that everyone who agreed or disagreed to the MIT license was also expressing their preference of using such license, there is a clear vote. Of course that won't be so, some people will have decided for the benefit of the greater group and since I (badly maybe) formulated the request as a question of acceptance, not preference. But it's the only indicator to go on now (short of doing a full vote on preferred licenses which might do more harm than good by fracturing the consensus).

Being pragmatic, the MIT does allow relicensing, so it would be a possibility to have a MIT licensed codebase, and keeping a patchqueue with the LGPL contributions on top. People can keep using the software LGPL'd, as now, or use and contribute to the MIT codebase.
(Eventually one would be resolved by either people contributing LGPL only, outdating the MIT base, or by contributing MIT only, consuming the patchqueue. Though maintaining the patchqueue might not be appreciated.)

I agree that some reasoning in the initial posts may be thin and far-fetched at best, badmouthing the LGPL at worst; if someone is unsure whether they may use LGPL'd software somewhere, they should get legal advice, IMHO discussing here what is or is not legally possible and legal corner-cases will be open-ended and unproductive; only showcasing the uncertainties people might be troubled with when considering LGPL'd code.

I would like to think those contributors who voted, did so from their own views and beliefs, not the reasons given by the thread starter here, so shouldn't be considered invalid by arguing that one person's reasonings.

.

I personally support the standpoint that the software community is growing up, companies better understand the value of supporting free software for their own good (they get a better foundation to build better products on, faster, with community-proven and unified concepts).

So being more free and permissive and unencumbered doesn't detract from contributions much, or encourage stealing, for the most part.
But it frees people from headaches when considering license issues and reuseability, therefore is more a kind of mature gentlemans agreement.
(Wish we could get to the same point with this software patent uglyness. So I agree a license like Apache 2.0 might be preferrable.)

There will always be black sheep, intent on keeping code locked up, their own and yours if they can, for some IP protection reason or other.
But the same holds true for copyleft software - companies will reason that some GPL software
runs on their own cloud, inhouse, and modifications need not be opened up.
Or they might consider themself above law and disregard the license alltogether (wikipedia: gpl-violations.org), after all who would even know?

In contrast, consider possible values of re-use of free software in proprietary products (much as we hate them):
E.g. if BSD sockets had been GNU sockets, Microsoft et al couldn't have based the winsock API on it, and there would have been a vastly more different sockets beast in Windows. Or multiple incompatible stacks even still.
Does the convenience of a similar API for programmers, across OS', outweight "stealing" the concept? (One might argue if they hadn't, Windows could be less popular these days, and the *NIX world better off.)

And making proprietary code build on permissive/free software (and they will, because it's free) will eventually suck them in; the free software outbreeding their proprietary head. So in their own interest they will keep their closed-source "patchset" small and contribute to the free portions of the code, simply for a better TDC/TCO, or be left behind.
So free software will still prevail, not always necessary to be militant about it in your license.
In contrast, for a copyleft codebase, the company would (possibly have to) develop their own derivative, potentially multiple competitive versions by different vendors, fracturing the software landscape instead of unifying it. No gain for the copyleft codebase that is already around.
(Examples: OpenStack vs. AWS, GitHub and GitLab, ...)

@techtonik

This comment has been minimized.

Contributor

techtonik commented Dec 30, 2015

I am not a GPL fan, because I didn't understand all the implications of the word "Free" in time, but as a contributor I'd feel kind of betrayed if project switched license in the middle. For me the ethical solution could be to jump to urwid2 or something even if I all for MIT and even CC-0 style of things with non-enforced crediting.

@tony

This comment has been minimized.

tony commented Dec 30, 2015

I wrote the PSF about LGPL last year. Alluding to @garrison mentioning of having a lawyer view the particulars, I asked them if they'd fund an attorney. I don't want to quote them, but the conversation boiled down to there isn't caselaw either way.

@techtonik : SDL2 did something very similar. They were LGPL and went zlib when version 2 came out.

https://www.youtube.com/watch?v=MeMPCSqQ-34&feature=youtu.be&t=435

I made this issue over 2 years ago and since moved on to different things.

I'm closing this issue, if you still want to change the license, feel free to open it.

@tony tony closed this Dec 30, 2015

@techtonik

This comment has been minimized.

Contributor

techtonik commented Dec 30, 2015

MIT is cool, I'd like to submit my Windows support stuff under MIT or CC-0.

@tony

This comment has been minimized.

tony commented May 29, 2016

@wardi Can you add a clause that forthcoming commits are licensed MIT in the mean time?

@tony tony referenced this issue Jun 26, 2016

Closed

license #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment