Open Source License Helper Tool • Hacker News Board

Re: Open Source License Helper Tool

#91

Post by belorn » Thu, Jun 07, 2018, 2:21 PM UTC

megaman22 wrote: post #87

belorn wrote: post #85

Earlier quoted context omitted.

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.

It depend on the industry and how competitive it is. It is relative known that the game industry is rather saturated and delaying a launch for a few months can be extremely costly, so its a rather costly mistake to re-implement a parsing library when there is a free alternative that is compatible with the business model. If its not compatible, it is still cheaper on the average to have a lawyer/developer send a email asking the project authors for an exception. For PC games its not uncommon to see third-party license text that is larger than the credits, occasionally put after the credits or in a file in the install directory.

Not all industries are like that, and places like Google and Apple can afford to put years of developer time on re-implementing stuff for which they don't even know the outcome of. If you are dominant enough then delaying a product by months or years is not a big deal, and as seems common, companies like that has a reputation for throwing money and employees at the problem. I would guess that it is easier, quicker and "cheaper" for a Google project leader to get more people on a team rather than get a custom software license through the approval process.

Re: Open Source License Helper Tool

#92

Post by quadrangle » Thu, Jun 07, 2018, 3:30 PM UTC

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.

Right, and as I said in my comment, the GPL isn't for developers per se, it's for the freedom of end-users. That's THE point.

Re: Open Source License Helper Tool

#93

Post by Avamander » Tue, Jun 19, 2018, 9:46 AM UTC

DannyBee wrote: post #81

Avamander wrote: post #67

Earlier quoted context omitted.

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.

Can you please share why patching is forbidden for AGPL? To avoid what?