Live data from Hacker News

Open Source License Helper Tool

choosealicense.com

31–40 of 93 posts

Re: Open Source License Helper Tool

#31

There's a disturbing trend that's similar to Microsoft's Shared Source [1] initiative from last decade, used by GitLab Enterprise [2] and Greensock [3]. The code is available for anyone to download, but is not under an Open Source license. They have the option of accusing their competitors of looking at their source code. [1] https://en.wikipedia.org/wiki/Shared_source [2] https://gitlab.com/gitlab-org/gitlab-ee/ [3]…

It's useful to note that the term "open source" does not require an OSI-approved license. It is conventional that the term implies an OSI license, but there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones. All that can be said today formally about a project is whether or not it's OSI-licensed, rather than whether it's open source. So…

Only because it isn't trademarked. Anyone who has the slightest shred of respect for open source community uses the term properly. They coined the term.

As for SQLite, it's compatible with OSI licenses. It has been folded into a larger work that's licensed under an OSI approved license countless times. There are some projects that might throw around the term public domain but I'd have to examine the details to see if it's ready to be used as part of an open source project.

Re: Open Source License Helper Tool

#32
post #27

Some of these licenses are like kryptonite for enterprises. For example, I once wrote an ip address manager in python and licensed it AGPLv3. Two companies reached out to me through Github not to talk about features or bugs, but to demand I change the license to BSD. after a dozen or so random bug reports insisting I had no right to use AGPL, AGPL was not a real license, and even a handful of Outlook meeting invites…

GPL is kryptonite if you want anybody outside a narrow slice of developers to use or care about your work. Unless idealogical purity trumps practicality in your mind, it's a nonstarter.

NPM or Nuget under more restrictive license regimes would never get off the ground.

Re: Open Source License Helper Tool

#33

There's a disturbing trend that's similar to Microsoft's Shared Source [1] initiative from last decade, used by GitLab Enterprise [2] and Greensock [3]. The code is available for anyone to download, but is not under an Open Source license. They have the option of accusing their competitors of looking at their source code. [1] https://en.wikipedia.org/wiki/Shared_source [2] https://gitlab.com/gitlab-org/gitlab-ee/ [3]…

It's useful to note that the term "open source" does not require an OSI-approved license. It is conventional that the term implies an OSI license, but there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones. All that can be said today formally about a project is whether or not it's OSI-licensed, rather than whether it's open source. So…

> there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones

SQLite is public domain. The OSI recommends against using a simple public domain declaration, but at the same time, does effectively say "for practical purposes it more or less works, though we recommend using a license instead": https://opensource.org/faq#public-domain

Re: Open Source License Helper Tool

#34
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…

[deleted]

Re: Open Source License Helper Tool

#35

Earlier quoted context omitted.

It's useful to note that the term "open source" does not require an OSI-approved license. It is conventional that the term implies an OSI license, but there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones. All that can be said today formally about a project is whether or not it's OSI-licensed, rather than whether it's open source. So…

Only because it isn't trademarked. Anyone who has the slightest shred of respect for open source community uses the term properly. They coined the term. As for SQLite, it's compatible with OSI licenses. It has been folded into a larger work that's licensed under an OSI approved license countless times. There are some projects that might throw around the term public domain but I'd have to examine the details to see if…

>They coined the term.

The term was coined by Christine Peterson who was not part of OSI, AFAIK. [1]

[1] https://opensource.com/article/18/2/coining-term-open-source...

Re: Open Source License Helper Tool

#36

Earlier quoted context omitted.

Only because it isn't trademarked. Anyone who has the slightest shred of respect for open source community uses the term properly. They coined the term. As for SQLite, it's compatible with OSI licenses. It has been folded into a larger work that's licensed under an OSI approved license countless times. There are some projects that might throw around the term public domain but I'd have to examine the details to see if…

>They coined the term. The term was coined by Christine Peterson who was not part of OSI, AFAIK. [1] [1] https://opensource.com/article/18/2/coining-term-open-source...

I wasn't using the terms "open source community" and OSI interchangeably.

Re: Open Source License Helper Tool

#37
post #27

Some of these licenses are like kryptonite for enterprises. For example, I once wrote an ip address manager in python and licensed it AGPLv3. Two companies reached out to me through Github not to talk about features or bugs, but to demand I change the license to BSD. after a dozen or so random bug reports insisting I had no right to use AGPL, AGPL was not a real license, and even a handful of Outlook meeting invites…

GPL is kryptonite if you want anybody outside a narrow slice of developers to use or care about your work. Unless idealogical purity trumps practicality in your mind, it's a nonstarter. NPM or Nuget under more restrictive license regimes would never get off the ground.

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 the freedoms downstream.

Re: Open Source License Helper Tool

#38

There's a disturbing trend that's similar to Microsoft's Shared Source [1] initiative from last decade, used by GitLab Enterprise [2] and Greensock [3]. The code is available for anyone to download, but is not under an Open Source license. They have the option of accusing their competitors of looking at their source code. [1] https://en.wikipedia.org/wiki/Shared_source [2] https://gitlab.com/gitlab-org/gitlab-ee/ [3]…

It's useful to note that the term "open source" does not require an OSI-approved license. It is conventional that the term implies an OSI license, but there are projects that are undeniably open source which are not issued under an OSI license. SQLite being one of the most prominent ones. All that can be said today formally about a project is whether or not it's OSI-licensed, rather than whether it's open source. So…

GitLab can only fairly claim they are "open source" because they do have a fully-functional core of the project that is truly open source.

Whether a license is specifically OSI-approved, isn't the point. The point is that "open source" means something as a term, and that is widely respected as the standard. If someone claims a license to be "open source" when it doesn't meet the definition, they can and will be rightly criticized for being deceptive in using the term wrongly.

Re: Open Source License Helper Tool

#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 permissive license such as MIT or Apache.

Paradoxically, the fact that you aren't forcing developers to share changes to the code encourages more use and makes it more likely you'll get a community contributing to the project.

Good examples of open source projects with diverse developer communities and permissive licenses include Hadoop, Apache webserver, Tomcat, NPM, Kubernates, TensorFlow and many more.

If you want to keep tight control over the code base and dictate all future changes, choose GPL. This was the choice for the JDK, MySQL, and many other projects controlled by corporate entities with little outside contribution.

(Yes, Gnu/Linux is a major exception as a GPL licensed ecosystem with diverse contributor base. But it's the exception rather than the rule).

Re: Open Source License Helper Tool

#40

Earlier quoted context omitted.

GPL is kryptonite if you want anybody outside a narrow slice of developers to use or care about your work. Unless idealogical purity trumps practicality in your mind, it's a nonstarter. NPM or Nuget under more restrictive license regimes would never get off the ground.

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.

Post reply on HN