Code Monkey home page Code Monkey logo

Comments (45)

dbrgn avatar dbrgn commented on July 20, 2024

BSD provides greater freedom, it's closer to Public Domain. LGPL ensures that Jedi modifications are contributed back.

I'd vote for LGPL.

See also: http://daisy-trac.cvsdude.com/tobi/wiki/LGPLvsBSD

from jedi.

asmeurer avatar asmeurer commented on July 20, 2024

My vote probably doesn't count here, because I haven't really contributed yet, but please consider a BSD style license. GPL style licenses, even LGPL, really limit who can use your software. And it's not just preventing the code from being included in proprietary software. The biggest issue is that (L)GPL'd code cannot be included in other, non-GPL'd code open source code bases!

To quote myself on David's blog, "You'll find a much wider audience for the library if it is BSD or MIT, and nobody will be "stealing" your code. I am a lead developer of a popular BSD Python library, and I can assure you that we get plenty of changes pushed back. It's matters much more how open and inviting you are to contributors, not what your license is. You don't get contributors by forcing them to contribute, you get them by having a welcoming mindset in everything that you do."

And by the way, if you are unsure, you should go with BSD, because it's easy to go from BSD to (L)GPL later, but very hard to go the other direction (you have to get permission from every contributor to go in the other direction).

from jedi.

tek avatar tek commented on July 20, 2024

agreed. I'd advocate MIT.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

@dbrgn @tkf What do you think? I really have no strong opinions on this.

from jedi.

tkf avatar tkf commented on July 20, 2024

Does Apple contribute back to FreeBSD?

from jedi.

tkf avatar tkf commented on July 20, 2024

It seems so: https://news.ycombinator.com/item?id=2083723
I was surprised :)

from jedi.

yyr avatar yyr commented on July 20, 2024

@tkf Apple will only contribute when & if necessary.

FWIW, I think I don't find the need to change license now, especially given that nobody is in a position where they can't use Jedi because of LGPL (so far atleast).

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

For me this is the strongest argument:

if you are unsure, you should go with BSD, because it's easy to go from BSD to (L)GPL later, but very hard to go the other direction (you have to get permission from every contributor to go in the other direction).

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

Licensing is a mess. See http://lucumr.pocoo.org/2013/7/23/licensing/.

How would the LGPL prevent the library from being included in proprietary programs? Shouldn't that be possible as long as Jedi itself is not modified?

If you'd switch to a permissive license, I'd favorite MIT over BSD. It's simpler. And there aren't different variants of it around.

I like copyleft, but it should not prevent the use (without modifications) in proprietary software.

And when staying with (L)GPL, another open question would be a contributors agreement. Although I don't really like those.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

Why would a project such as Django (BSD licensed) have a "contributors agreement"?

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

Wait, what? Looks like they really do have a CLA: https://www.djangoproject.com/foundation/cla/

I never signed it though and my contributions were accepted into Django.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

It just doesn't make sense because if it's BSD, they can always change the license.

from jedi.

tkf avatar tkf commented on July 20, 2024

My understanding is that you don't need CLA even for GPL. CLA is for making easier to fight in court: http://www.gnu.org/licenses/why-assign.html

Re: BSD vs GPL. I see no point for changing to BSD for open source projects. Down stream projects can easily develop core code in BSD and distribute Jedi-bundled version in LGPL. You just need to put a sentence in COPYING file. For proprietary projects, they may or may not contribute back to Jedi. Looking at PyCharm, I think no contribution scenario could happen. But if some company make IDE using Jedi and if they contribute back, that could be a big gain for us. I think the point is to which scenario we want to bet.

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

Well, you need a CLA for GPL if you want to be able to change your license in the future. Otherwise you need to ask every single copyright holder / contributor for permission. (That's btw what OpenStreetMap did, all contributors needed to agree to a license change, contributions without agreement were removed. The process took several years.)

from jedi.

asmeurer avatar asmeurer commented on July 20, 2024

My original concern was with using this in spyder.

Shouldn't that be possible as long as Jedi itself is not modified?

That's exactly true. But this restriction doesn't make sense. Sometimes the library needs to be modified. And it doesn't always make sense for it to be pushed back or even rereleased. As a random example for Jedi, suppose a company has an internal proprietary DSL that's a superset of python, and they want to extend Jedi to work with it. With the LGPL, they would have to release their modification, meaning they essentially have to make their DSL public, which they might not want to do for competitive purposes. As a more stupid example, suppose Jedi needs to be modified to work around a bug in something else, which is either hard or impossible to fix directly, but that something else is internal, so it doesn't make sense for it to be upstreamed.

And btw, some companies won't even touch GPL or LGPL software regardless of what they would do with it for legal concerns.

Regarding contributing back, in my experience, you have to contribute back, unless you either want to freeze the software where you modified it, fork it, or spend a ton of man hours. The reason is that a healthy project will quickly become incompatible with any change, unless it is pushed upstream, at which point it will become "officially supported".

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

What about the cases where Jedi is embedded into an IDE and improved in some area that could benefit other editors / IDEs, but the change is not made public because this way the current proprietary IDE has an advantage over the other ones?

In general I agree with you, but we have to decide on the case above (I'm not quite sure whether it's absurd or not) before we could move to MIT.

from jedi.

tkf avatar tkf commented on July 20, 2024

you need a CLA for GPL if you want to be able to change your license in the future.

Probably changing from GPL is against FSF's will :)
Just saying that. I understand your point.

Shouldn't that be possible as long as Jedi itself is not modified?

That's exactly true.

My understanding is that that is true if user install LGPL library by himself. If you distribute some software with LGPL and then software as a whole will be LGPL, right?

(On the other hand, user can't link/import GPL library to non-free software even if both are installed by the user separately.)

you have to contribute back,

Yea I know the dynamics. I just want to mention that you could decide to not merging Jedi anymore; PyCharm write Jedi-like functions (from scratch?). Forking from Jedi will be far more easier than that.

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

Yea I know the dynamics. I just want to mention that you could decide to not merging Jedi anymore; PyCharm write Jedi-like functions (from scratch?). Forking from Jedi will be far more easier than that.

And that's exactly the case I'm thinking of :) It's really hard to make software free to use everywhere, but to guarantee that improvements "flow" back to the original project...

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

Looking at PyCharm, I think no contribution scenario could happen

you could decide to not merging Jedi anymore; PyCharm write Jedi-like functions (from scratch?). Forking from Jedi will be far more easier than that.

See not merging is stupid. Have you seen the last 50 commits? They are all sith.py corrections. It took a lot of time, that's just nothing you would do as a commercial company (not for autocompletion). I just think it's a stupid move to not contribute back, clearly that happens, but what's the problem?

In the end my goal in the beginning was to improve autocompletion in Python for Python users. If it also improves it in PyCharm (even if that doesn't help us), we're still fine, it's not "bad" for Jedi.

Also PyCharm is still a product that I like, it's commercial and I wouldn't use it, because I love simple tools, but in the end we're all fighting for a big Python adoption,

So in my opinion, I don't see anything that could "hurt" us. Maybe something "unfair", but open source isn't about fairness anyway. I mean we're working on a project for hours that people with salaries of >100'000$ are using to improve their speed. And even worse, we want and encourage that :-)

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

I fully agree. I'd rather have some people not contribute back than to hinder the integration of Jedi into software where it can be useful and help people.

I'd vote for MIT. But in order to do that you need to get the permission from every contributor so far. You have mine. (Simply mentioning them all in this thread should be enough to to get their attention... Then they can comment here. Or create a new issue for the license change.)

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

let's wait for @tkf. If he is also in favor of that, we can ask the other ones.

from jedi.

tkf avatar tkf commented on July 20, 2024

LGPL library can be imported from proprietary software. So you can imagine that some project could contribute back if Jedi were LGPL but would not if it were BSD. We will lose such "marginal" case if we go to BSD.

But, it seems that the choice to use LGPL is done without "philosophy" (like FSF has) to protect human rights (freedom to use software). If so, I guess we don't have enough power to refuse switching BSD.

Anyway, I was defending LGPL as to make this discussion fair. As it seems defending LGPL with purely practical point of view (i.e., without philosophy stuff) is not possible, I guess going to BSD (or MIT) is a logical choice.

from jedi.

tkf avatar tkf commented on July 20, 2024

(BTW I am not trying to say you don't have any philosophy. It just seems not similar to the one FSF has. I am not trying to piss you off or something :))

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

The FSF philosophy is good, but has some negative impractical downsides. http://lucumr.pocoo.org/2013/7/23/licensing/ is a good post about some of the problems with it.

You're absolutely right, in this case, I'd vote for MIT due to practical reasons, not philosophical ones.

from jedi.

tkf avatar tkf commented on July 20, 2024

I'd favorite MIT over BSD. It's simpler. And there aren't different variants of it around.

I think "2-clause BSD" or "3-clause BSD" is more specific than "MIT" because:

Because MIT has used many licenses for software, "MIT License" is considered ambiguous ...
-- https://en.wikipedia.org/wiki/MIT_License

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

In my experience if people use MIT/X11, then they refer to it as "X11 license". If you read "MIT License" it refers to this one: https://en.wikipedia.org/wiki/MIT_License#License_terms It's also the one that the OSI refers to when they're talking about the MIT license: http://opensource.org/licenses/mit-license.php

With BSD you have the "Prior BSD License", the "BSD License / 4-Clause BSD License", the "New BSD License / 3-Clause BSD License / Modified BSD License" and the "Simplified BSD License / 2-Clause BSD License / FreeBSD License". https://en.wikipedia.org/wiki/BSD_licenses There are also modified versions of the 2-Clause license used by NetBSD. I find MIT much clearer.

But in the end, it comes down to whether you want the endorsement clause in the license or not. I don't think we need it. Which would make the MIT license compatible to be used in BSD-3-clause licensed Projects, but not vice versa.

Licenses are way too complicated 😖

from jedi.

tkf avatar tkf commented on July 20, 2024

it comes down to whether you want the endorsement clause

2-clause does not have endorsement stuff so I always thought it is equivalent to MIT.

Anyway, we should have COPYING. If it is only the name issue then it does not worth discussing.

Licenses are way too complicated

Agree :)

from jedi.

asmeurer avatar asmeurer commented on July 20, 2024

Jedi is probably not a name that you guys can claim any copyright to anyway :)

from jedi.

dbrgn avatar dbrgn commented on July 20, 2024

Haha, good point :)

from jedi.

tkf avatar tkf commented on July 20, 2024

It seems that character name is different issue to copyright:
http://writers.stackexchange.com/questions/291/are-names-of-characters-copyrighted-by-authors

I guess we can safely assume so as Debian (GPL) uses names from toy story.

from jedi.

asmeurer avatar asmeurer commented on July 20, 2024

Yeah, I don't think there's any possible legal issue, especially since jedi has nothing to do with star wars or science fiction in general.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

So as far as I can tell we're switching to MIT? I will ask the other contributors for permission.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

@tkf Do I have your permission to release Jedi under an MIT license?

from jedi.

tkf avatar tkf commented on July 20, 2024

@davidhalter Sure.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

We're changing the license of Jedi from LGPL to MIT. You can find the discussion and the reasoning above. IMHO there are two main reasons:

  • We can always switch back, a switch away is getting harder and harder, because we need the agreement of all contributors
  • MIT/BSD licensing allows everyone to use Jedi, even if they don't want LGPL/GPL licenses in their software packages. We want to encourage using Jedi and contributing back. If the contributions don't flow back, we don't lose, but we can win if they do.

Read the discussion above for other points.

The following contributors are asked to take a stand:

@lvh
@Astrac
@ganwell
@tek
@JJay
@andviro
@floppym
@asmeurer

Please answer ASAP if you're ok with your contribution being released under an MIT license. Also answer if you're not.

from jedi.

lvh avatar lvh commented on July 20, 2024

Yes! MIT or ISC would be great. +1!

from jedi.

andviro avatar andviro commented on July 20, 2024

Sure, I'm OK with license switch.
29.07.2013 13:57 ÐÏÌØÚÏ×ÁÔÅÌØ "David Halter" [email protected]
ÎÁÐÉÓÁÌ:

We're changing the license of Jedi from LGPL to MIT. You can find the
discussion and the reasoning above. IMHO there are two main reasons:

  • We can always switch back, a switch away is getting harder and
    harder, because we need the agreement of all contributors
  • MIT/BSD licensing allows everyone to use Jedi, even if they don't
    want LGPL/GPL licenses in their software packages. We want to encourage
    using Jedi and contributing back. If the contributions don't flow back, we
    don't lose, but we can win if they do.

Read the discussion above for other points.

The following contributors are asked to take a stand:

@lvh https://github.com/lvh
@Astrac https://github.com/Astrac
@ganwell https://github.com/ganwell
@tek https://github.com/tek
@JJay https://github.com/jjay
@andviro https://github.com/andviro
@floppym https://github.com/floppym
@asmeurer https://github.com/asmeurer

Please answer ASAP if you're ok with your contribution being released
under an MIT license. Also answer if you're not.

Reply to this email directly or view it on GitHubhttps://github.com//issues/5#issuecomment-21709839
.

from jedi.

Astrac avatar Astrac commented on July 20, 2024

Sounds good to me!

from jedi.

ganwell avatar ganwell commented on July 20, 2024

Yes. I agree to switch to a MIT license.

from jedi.

jkb0o avatar jkb0o commented on July 20, 2024

Yeah, I agree.

from jedi.

tek avatar tek commented on July 20, 2024

I'm in.

from jedi.

davidhalter avatar davidhalter commented on July 20, 2024

I forgot the following authors:

@hattya and @srusskih

Are you ok with switching from LGPL to an MIT license? (see discussion above)

from jedi.

asmeurer avatar asmeurer commented on July 20, 2024

I'm obviously ok.

from jedi.

floppym avatar floppym commented on July 20, 2024

My contribution was pretty trivial and I am surprised you added me to the AUTHORS file in the first place.

I am ok with any license change you would like to make, including MIT.

from jedi.

srusskih avatar srusskih commented on July 20, 2024

I'm in

from jedi.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.