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

81–90 of 93 posts

Re: Open Source License Helper Tool

#81

Post by DannyBee »

Avamander wrote: post #67
JoshTriplett wrote: post #30

Earlier quoted context omitted.

Sounds like the license did its job quite nicely. If those companies cared enough to negotiate new license terms, they could pay you for such a license.

It's not only companies who ask for license changes, Google and other employees ask licences to be changes too simply because the corporation they work for forbids even looking at the source otherwise. For example: https://github.com/pebble-dev/rebblestore-api/pull/31

This is false for Google (I created and owned the relevant policies).

Google publishes it's open source docs, so you can just look: https://opensource.google.com/docs/using/agpl-policy/

We also banned patching agpl projects, I'm just too lazy to find that link for you.

Re: Open Source License Helper Tool

#82

Post by abritinthebay »

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…

LGPL only requires you to share changes to the LGPL code that you publish (you don't even have to submit them back, just make them available).

And yeah, that comes down to "well if you want to use our stuff and base new work on our stuff... share it to the world" but it has no effect on the wider application.

Re: Open Source License Helper Tool

#83

Post by mlinksva »

SeanLuke wrote: post #73

MIT/X11 come from a kindler, gentler era, and so lack a patent release, which is a huge flaw nowadays. Is there any legitimate reason one would select MIT/X11 over Apache?

One or more of: one might prefer MIT's simplicity (both the text itself, and the what's needed to comply) relative to Apache-2.0, one might not like the specifics of the latter's patent terms, one might consider the former's arguable implicit patent license good enough https://opensource.com/article/18/3/patent-grant-mit-license

Re: Open Source License Helper Tool

#84

Post by Midnightas »

vortico wrote: post #10

May I recommend replacing The Unlicense with CC0? ( https://creativecommons.org/publicdomain/zero/1.0/legalcode ). It has all the same bullet points except is a bit tighter in countries where a public domain release is not legally valid. Unfortunately it is more difficult to release works into the public domain than The Unlicense addresses. The Unlicense is likely sufficient for all foreseen cases in countries except…

Doesn't CC0 have patent issues (IAALN)?

Re: Open Source License Helper Tool

#85

Post by belorn »

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.

Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games.

The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice".

The license however do not mention static and dynamic, so like any other copyright license it is up to the copyright author to decide when and how to protect their work. The license text of LGPLv2.1 calls the distinction a "work that uses the Library" vs distributing a "portion or derivative of it". LGPLv3 skips it all together and instead describe instead a "suitable shared library mechanism", which is very open to non-C languages. Basically any package distribution system with dependencies should work for LGPLv3 if the work is independently packaged.

Re: Open Source License Helper Tool

#86

Post by miguelrochefort »

hawski wrote: post #71
vortico wrote: post #10

May I recommend replacing The Unlicense with CC0? ( https://creativecommons.org/publicdomain/zero/1.0/legalcode ). It has all the same bullet points except is a bit tighter in countries where a public domain release is not legally valid. Unfortunately it is more difficult to release works into the public domain than The Unlicense addresses. The Unlicense is likely sufficient for all foreseen cases in countries except…

I find the Zero Clause BSD [0] the simplest for the purpose. Here it is in its entirety: Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR A…

Also known as the "Free Public License 1.0.0".

It's also officially recognized by the OSI.

https://opensource.org/licenses/FPL-1.0.0

Re: Open Source License Helper Tool

#87

Post by megaman22 »

belorn wrote: post #85
megaman22 wrote: post #43

Earlier quoted context omitted.

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.

Its obviously not that problematic since it is quite common for both large and small game developers to use LGPLv2 and v3 for PC games. The static vs dynamic aspect of LGPL is rather simple: the FSF has somewhat said that they will enforce C programs in the GNU project that is under LGPL based on the distinction of static vs dynamic. It can also be seen as the promoted "best practice". The license however do not ment…

Thank you, that's probably the best explanation I've seen of the distinction.

Still, it's an uphill battle to fight with bosses that don't understand the licensing, and are gunshy of liability.

Re: Open Source License Helper Tool

#88

Post by icebraining »

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…

Here's a third reason:

"I used to be worried about fragmentation, and I used to think that it was inevitable at some point," said Torvalds. “Everyone was looking at the history of Linux and comparing it with UNIX. People would say that it’s going to fail because it's going to fragment. That's what happened before, so why even bother?"

What made the difference was the license. "FSF and I don't have a loving relationship, but I love GPL v2," said Torvalds. "I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint."

https://www.cio.com/article/3112582/linux/linus-torvalds-say...

Re: Open Source License Helper Tool

#89

Post by icebraining »

ubernostrum wrote: post #63
JetSpiegel wrote: post #15

Why not turn this around and default to GPL as "nice and simple"? The introduce the "I don't care about sharing improvements" option for BSD style licenses?

The GPL is anything but "nice and simple". There's a reason why it's such a huge wall of text, compared to the much shorter BSD and MIT licenses. And FSF's preferred interpretations of the GPL, and various ambiguous things in it (especially with respect to dynamic linking and implementations of standard interfaces) make it even less "nice and simple". Let's take an example: Django is a web framework that, among its c…

I agree with your overall point, I just want to point out that the FSF can't come after anyone, only the copyright holders of the driver modules can.

Re: Open Source License Helper Tool

#90

Post by icebraining »

deathanatos wrote: post #22
dankohn1 wrote: post #14

Earlier quoted context omitted.

WTFPL is not OSI-approved and so briefly held up containerd coming into CNCF. https://github.com/chanezon/toml#about-this-fork

IANAL, this is not legal advice, etc. If you disagree that the WTFPL is a useable license, how does forking & relicensing work? Changing the license requires having a license that allows you to do so to the new target license (or ownership of the copyright). But if our assumption is that we reject the WTFPL as a valid license, how can we simultaneously use it to relicense? I.e., instead of a needing a legal debate ab…

Yes, clearly you can't change the license of a project you don't have a valid license to.
Post reply on HN