Should included packages have any particular license?

[flimzy]

One generally assumes that Go libraries are open source, but this isn't always true. Some may be require a commercial (pay) license, others may simply not be licensed for re-use at all.

What are/should be the guidelines for including non-open-source code in this list?

Would it perhaps be reasonable to add (perhaps optionally) license information for listings?

[ceriath]

Since our rules require us to review the quality of code and a test coverage, it requires the code to be open sourced. Also, this is mainly a place for go developers, who are searching for a tool or library, to help with their own work. Therefore closed source code would be pretty much useless on this list.

[kirillDanshin]

Actually, I think we should go further on that question.

Think of it like this: developers frequently work for a company. Some licenses could be dangerous to use in commercial projects.
For example, GPL, AGPL etc. are dangerous for use in commercial products in some cases due to the fact that license requires you to disclose source code publicly without requiring a special password or key for unpacking, reading or copying, and in case of a trial the court may decide that the company must disclose proprietary source code of its products.

I'd personally strongly recommend Apache 2.0 over other options due to the fact that this license does not require you to disclose source code including the case of commercial usage.

In the same time, I saw some projects that have LICENSE file with an opensource license, but it wasn't applied to the sources (missing license headers) or a proprietary license was applied instead.

[flimzy]

Since our rules require us to review the quality of code and a test coverage, it requires the code to be open sourced.

That's some comfort :)

Is this documented somewhere? It would be nice to know what the guidelines are, for those consuming the list, even if they aren't part of the submission criteria.

[flimzy]

In the same time, I saw some projects that have LICENSE file with an opensource license, but it wasn't applied to the sources (missing license headers) or a proprietary license was applied instead.

As usual, IANAL, but AFAIK, "license headers" aren't usually required. I know many projects choose to use them, but I think that's more a CYA approach than a legal requirement. Many file formats don't even allow these sorts of headers (JSON files, images, etc), but are generally considered to fall under the license terms provided in the package.

Some license guidelines do request/"require" license headers, but as I understand, this is a matter of policy, not legality. See here for some examples/discussion.

Having said that, if there are ever conflicts (i.e. LICENCE.md says MIT, the file says GPL), it should raise red flags, and is perhaps a sign of (unwitting) plagiarism.

[ceriath]

@flimzy you can find the guidelines here https://github.com/avelino/awesome-go/blob/master/CONTRIBUTING.md

also, about the license headers, they are defintely not required, at least with common licenses

[flimzy]

@flimzy you can find the guidelines here https://github.com/avelino/awesome-go/blob/master/CONTRIBUTING.md

Yes, I'm very aware of those guidelines. But they don't mention licensing. I was asking if you had licensing guidelines somewhere.

[ceriath]

Oh, sorry for the missunderstanding. I am not aware of any that exist. Maybe we should create that...

[flimzy]

Since our rules require us to review the quality of code and a test coverage, it requires the code to be open sourced.

I'm re-reading this, and I think what I hear you saying is that, by virtue of code-reviewability, the code is by nature open-source. Is that right?

This isn't really true, except perhaps in the most liberal sense of "open source."

Many commercially-licensed libraries have their source public, but cannot be used or redistributed without a fee, so not really "open".

In other cases, such as this library are on GitHub, and probably intended to be open sourced, but have no license, and the author has not responded to requests to clarify the license. My understanding (of course, IANAL) is that this means the code is not open sourced, and cannot be used without permission.

[kirillDanshin]

also, about the license headers, they are defintely not required, at least with common licenses

I think Apache 2.0 is common enough :)

ref: https://opensource.org/licenses/Apache-2.0

IANAL, but I was consulting a lawyer company on that stuff, and they actually loose a case due to missing headers in sources.

speaking of images, they're usually licensed under different licenses, more appropriate for media, but anyway we have EXIF metadata, and CIPA DC-008-2019 lists the Copyright attribute, author can just put a license there, but actually it looks like too much to me :)

[flimzy]

I think Apache 2.0 is common enough :)

Hrm, if that's a requirement for the Apache license, I need to update a few of my packages. :/

Anyway, the real point should be: Does this list care about the licensing? (IMO, it should) And if so, what criteria ought to be met for inclusion? Or if not for inclusion, should licensing info be included in the listing (perhaps including "Unknown")?

[kirillDanshin]

@flimzy actually, you can't get in the list with really bad goreportcard score, which includes license lint :) I'm trying to check if package actually opensourced and if the license includes copyright notice of previous authors, but with our current rules I can't, for example, require project to switch from a dangerous license

[flimzy]

you can't get in the list with really bad goreportcard score, which includes license lint

Oh that's good to know. So the license requirements are indirectly documented at goreport card. But it looks like that only checks for the existence of a license file. That file could, in theory say "No permissions granted, Go away, geezer!" and still pass :)

Example: https://goreportcard.com/report/github.com/flimzy/test
LICENSE file: https://github.com/flimzy/test/blob/master/LICENSE.md

[kirillDanshin]

@flimzy

oh my f~~~~~~~~~ ~~~~~~~ 🤯

ok, I'll get us a real license checker as soon as I can

[flimzy]

I think Apache 2.0 is common enough :)

Not to beat a dead horse, but I found myself in a minor panic about my potential non-compliance with the Apache license. In case this thread shows up in the Googles, to save future readers from the same concern, the "header per file" requirement does apply to official ASF projects (source), but this strict requirement doesn't apply to non-ASF projects (source), and even as a legality, doesn't apply to ASF projects, in case of omission (source):

All packages produced by the ASF are implicitly licensed under the Apache License, Version 2.0, unless otherwise explicitly stated.

In fact, one of the stated goals of the Apache 2.0 license (as opposed to 1.x) was specifically (source)

to allow the license to be reusable without modification by any project (including non-ASF projects), to allow the license to be included by reference instead of listed in every file.

[kirillDanshin]

@flimzy it's a tricky question, but I'd really recommend to include the boilerplate header where it's possible just in case

[kirillDanshin]

@flimzy speaking of license headers, check out go-kivik/kivik#418 (although I probably needed to wait and open issue 451 later lol)

[ceriath]

@kirillDanshin i had no idea that this was an apache requirement. Guess i violated it regularly then and need to fix some stuff