Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open Source License Helper Tool

choosealicense.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Open Source License Helper Tool

#41

Post by abritinthebay »

wglass wrote: post #39

Good comments on each license, but misses a major point about sharing and community. Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users. If you want to encourage a variety of developers to adopt, modify, and share changes, you are much better off with a permis…

Which is why the LGPL exists. Most code that is designed to be shared & incorporated rather than complete/forked should likely be LGPL (if the GPL ideals are what is wanted).

Personally I just go with MIT/X11 but there are good reasons to want to use a GPL-type license

Re: Open Source License Helper Tool

#42

Post by abritinthebay »

megaman22 wrote: post #40
quadrangle wrote: post #37

Earlier quoted context omitted.

The hyperbole in this comment is unwarranted. Furthermore, the GPL isn't even developer-focused. It's downstream, end-user focused. There's a reason many of the most prominent free/libre/open programs are GPL: GIMP, Audacity, Linux kernel, so many others… GPL for developer-focused libraries and tools etc. is where the tension comes in because so many developers want to benefit from the open resources but not pass on…

Well, I'm a developer, and I'm looking at this from the perspective of my upstream dependencies. If your cool library to do xyz is GPL, that means my project that wants to use your library needs to be GPL . If it's MIT or Apache or MSPL, party on. under most CyA lawyer regimes.

Which is why LGPL exists.

Re: Open Source License Helper Tool

#43

Post by megaman22 »

abritinthebay wrote: post #42
megaman22 wrote: post #40

Earlier quoted context omitted.

Well, I'm a developer, and I'm looking at this from the perspective of my upstream dependencies. If your cool library to do xyz is GPL, that means my project that wants to use your library needs to be GPL . If it's MIT or Apache or MSPL, party on. under most CyA lawyer regimes.

Which is why LGPL exists.

LGPL is problematic to some extent outside the original C-ist style of static and dynamic link libraries. At least that's what I've been told.

Re: Open Source License Helper Tool

#44

Post by wglass »

abritinthebay wrote: post #41
wglass wrote: post #39

Good comments on each license, but misses a major point about sharing and community. Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users. If you want to encourage a variety of developers to adopt, modify, and share changes, you are much better off with a permis…

Which is why the LGPL exists. Most code that is designed to be shared & incorporated rather than complete/forked should likely be LGPL (if the GPL ideals are what is wanted). Personally I just go with MIT/X11 but there are good reasons to want to use a GPL-type license

Yes. But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community.

There are two good reasons to go with a gpl or lgpl license.

One is ideological. You believe software should be free and that downstream developers must conform to your ideals. This is the Richard Stallman approach.

The second is control. You actively want to discourage forking and outside contributions. This is Oracle’s approach. This isn’t necessarily bad or evil, but it’s pragmatic. Generally a corporation doing this will offer the license under a separate paid offering as well.

I can’t think of any other good reasons to choose GPL.

Re: Open Source License Helper Tool

#45

Post by daveguy »

wglass wrote: post #44
abritinthebay wrote: post #41

Earlier quoted context omitted.

Which is why the LGPL exists. Most code that is designed to be shared & incorporated rather than complete/forked should likely be LGPL (if the GPL ideals are what is wanted). Personally I just go with MIT/X11 but there are good reasons to want to use a GPL-type license

Yes. But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community. There are two good reasons to go with a gpl or lgpl license. One is ideological. You believe software should be free and that downstream developers must conform to your ideals. This is the Richard Stallman approach. The second is control. You actively want to discoura…

> But the LGPL is still more restrictive as it requires you to share your changes. Not as much of a disincentive but it still discourages community.

Not a fan of GPL (because of developer restrictiveness), but I don't see how requiring changes to be shared implies more restrictiveness or discourages community. Can you explain the reasoning here?

Re: Open Source License Helper Tool

#46

Post by rectang »

wglass wrote: post #39

Good comments on each license, but misses a major point about sharing and community. Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users. If you want to encourage a variety of developers to adopt, modify, and share changes, you are much better off with a permis…

It's not possible to devise framings which will please everyone in both the Free Software and Open Source movements. The disagreements between them are very old, and for some, embittered.

Re: Open Source License Helper Tool

#47

Post by rectang »

megaman22 wrote: post #43
abritinthebay wrote: post #42

Earlier quoted context omitted.

Which is why LGPL exists.

LGPL is problematic to some extent outside the original C-ist style of static and dynamic link libraries. At least that's what I've been told.

The Apache Software Foundation doesn't allow LGPL dependencies for one because the LGPL stipulation that it must be possible to replace the LGPL component imposes a requirement which is not present in the ALv2 -- thus the the ALv2 cannot subsume the LGPL and a bundled package including the LGPL dependency cannot be distributed as ALv2.

This is a policy issue, not a legal one. Such a package would still be legal to distribute, but it would not meet the ASF policy that all ASF products be distributed under the ALv2.

Re: Open Source License Helper Tool

#48

Post by willtim »

wglass wrote: post #39

Good comments on each license, but misses a major point about sharing and community. Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate. A larger code base that contains a GPL component must also be GPL. This is a nonstarter for most business users. If you want to encourage a variety of developers to adopt, modify, and share changes, you are much better off with a permis…

> Despite the rhetoric about "freedom" the GPL is a huge disincentive for developers to participate.

The "freedom" references from GNU are with respect to the users of the software, not necessarily to any entity that may participate. It's perfectly possible for a proprietary closed-source product to leverage code from a BSD/MIT project to remove user freedoms.

Re: Open Source License Helper Tool

#50

Post by ecthiender »

megaman22 wrote: post #40
quadrangle wrote: post #37

Earlier quoted context omitted.

The hyperbole in this comment is unwarranted. Furthermore, the GPL isn't even developer-focused. It's downstream, end-user focused. There's a reason many of the most prominent free/libre/open programs are GPL: GIMP, Audacity, Linux kernel, so many others… GPL for developer-focused libraries and tools etc. is where the tension comes in because so many developers want to benefit from the open resources but not pass on…

Well, I'm a developer, and I'm looking at this from the perspective of my upstream dependencies. If your cool library to do xyz is GPL, that means my project that wants to use your library needs to be GPL . If it's MIT or Apache or MSPL, party on. under most CyA lawyer regimes.

Your comment exactly misses the point of GPL!

If I, as an upstream developer, license my library in GPL, it is exactly because I don't want any random developer to use my library and don't pass on the same freedom to end users. I intentionally want anyone using my library to be in the same freedom sphere (for lack of a better word).

If you think this as problematic/cancerous then it's a pity. This license was designed to retain freedom of software users.

Post reply on HN