Awesome-go: Contribution Guidelines mention about software license

[xhit]

Extracted from Contribution Guidelines:

The package or project had to be maintained under open source license ( we make a brief review of the code before the link enters the list ), see list of allowed licenses.

I have some questions:

¿Package and projects are similar?, despite the answer, Why GoLand is in the list?

Can a contributor share a software made in pure Go but is not open source despite the user can use all the software only restricted with time like GoLand?

I'm investigating if https://dixer.stgo.do could apply to this awesome list.

Thanks!

[ceriath]

Hi,
the sentence in question is a very recent addition to the contribution guidelines (actually it was added 3 hours before this issue was created 9196c76). Therefore, it is very possible that some projects, like GoLand, would not meet this requirement. However, i personally would consider GoLand - and tools in general - not part of the list itself, more like an addendum. That's why there are three "chapters": awesome go, tools and resources. Those guidelines mainly apply to the awesome go part. The main goal of this list is to provide libraries and tools for go developers, while the latter in my opinion do not necessarily have to be open sourced.

Package and projects are similar
I do not agree with this, a project can consist of multiple packages, actually most are.

I'll leave this discussion open for other maintainers to voice their opinions on this.

[avelino]

@ceriath how to guarantee minimum software quality without being able to see the code?

in my opinion the packages and projects should be with open source license, that's what I understood from this issue https://github.com/avelino/awesome-go/issues/2712 (that's why I generated this commit https://github.com/avelino/awesome-go/commit/9196c7660cfeaf654b8be1d80888a009fd471f09)

[xhit]

Ok, only open source projects, I got it.

In the future will be a section to closed source tools made in Go? I think will be great this section but also I think that projects needs to share more info like dependencies, Go version and other stuff.

For example, Dixer is a tool that uses a lot of Go open source libraries, and do things that in many cases the script generated could be or not open source.

I made the tool to be very clear in open source packages used.

Some times the tools can be an example of the power of Go and can catch developers to build a better alternative and, maybe, open source it.

[avelino]

How would we do to guarantee the minimum quality if we don't have access to the code? If the closed source software has a network monitoring, malware or anything from the team, who would be recommending it is awesoem-go (community).

That's a complicated issue.

[xhit]

Well, if it's mandatory to see the code of project to be part of awesome go community, i got it, this community wants open source software.

Closing the issue because we don't have nothing to do here.

Thanks for this awesome repository.

[avelino]

@xhit thank you for bringing questions that make us look at our review flow and reflect on whether we are on the best path.
Feel invited to help us keep awesome-go.