Le lundi 05 mars 2018 à 10:07 -0500, Lokesh Mandvekar a écrit :

When you ship a Go binary like cri-o, do you need to include the licenses of all vendored dependencies at %license? Or does it suffice to specify just the license file of the main package itself?

You *must* follow Fedora licensing guidelines for everything you ship, whether it is built or not. That includes license files and package licensing tag.

There used to be some tolerance for items removed as first step in %prep (ie rm -fr vendor), as long as they were under a Fedora-friendly license. For stuff Fedora actually forbids, packagers were required and are probably still required to regenerate the archive used by the spec file without the offending content before uploading to koji.

Apart from Fedora requirements, that go a bit beyond the law to simplify maintenance, from a legal POW, you should never state a package is under a particular license before making sure all the licenses in play actually devolve to this license.

And lastly any time you ship other people's code, either built or not, it is good taste to document and preserve its licensing.

Which is why, vendoring (bundling) and static linking (when all the code ends up a single binary) is a terrible idea from a legal POW.

So:

1. for devel-only Go packages: don't ever vendor, rm all traces of bundled code, that will save you loads of legal problems

2. for Go packages that build binaries: if you don't vendor anything, (rm -fr vendor as first step or better get an upstream archive without third-party code) and you have satisfied yourself all the licenses devolve to a single one, it's probably ok to document just this one

3. it is *way* simpler with dynamic linking where all the objects are nicely separated, in different packages, with separate documentation, and legal analysis can be made at the time you assemble the packages, not at the time you ship them. Volunteers willing to convert Fedora packages to dynamic linking are welcome.

4. if you publish a Go project: don't vendor, use stable releases of other components, and if you do vendor don't include the vendored files in you git repo, just the vendor config file.

But do ask spot or fedoral-legal when in doubt.

Regards,

Le 2018-03-06 11:49, Jakub Cajka a écrit :

----- Original Message -----

...

From: "Nicolas Mailhot" 3. it is *way* simpler with dynamic linking where all the objects are nicely separated, in different packages, with separate documentation, and legal analysis can be made at the time you assemble the packages, not at the time you ship them. Volunteers willing to convert Fedora packages to dynamic linking are welcome.

Hi Jacub,

I would much appreciate if you could help me to convert Fedora to dynamic linking in regard to the the Go packaging. May I count you in?

If no one steps in I will probably look at it someday, but right now my Fedora priorities are:

1.finish wrapping up the current macros with Jan till it builds our existing packages without workarounds

(really not happy right now about golist trying to parse, install and test non production code such as examples, tesdata and _dirs by default, all of those should be ignored, trying to parse and install them breaks many of our packages, as most example code is quite unmaintained by upstreams and will pull needless requires if it does work, tesdata is data that will contain broken code if it contains any code at all, and _dirs are supposed to be ignored by the compiler so trying to parse in in golist often panics.)

2. update the wiki documentation to reflect the changes we did with Jan (of course, anyone doing it before me is welcome)

3. get our packages in Fedora

$ ls -l golang-*/*spec | wc -l 562

$ ./find-not-in-fedora.sh | cut -d " " -f 1 | wc -l 365 (counting specs that provide an import path completely absent from devel right now)

And even those that are in Fedora in some form, will need switch to new form of packaging, eventual update to the new version/commit the other specs need, eventual renaming and layout change to be consistent with the other new packages

That includes, identifying the packages that break with Go 1.10 and fix them one way or another

4. process the requests that accumulated on my other Fedora packages while I was taken with Go packaging

I will only have space cycle to try new Fedora Go endeavors afterwards. Wich is unlikely to be soon given the amount of remaining work (of course, helping someone else to do it would demand a lot less commitment)

Regards,

On 03/06/2018 01:33 PM, Nicolas Mailhot wrote:

Le 2018-03-06 13:24, Nicolas Mailhot a écrit :

...

(really not happy right now about golist trying to parse, install and test non production code such as examples, tesdata and _dirs by default, all of those should be ignored, trying to parse and install them breaks many of our packages, as most example code is quite unmaintained by upstreams and will pull needless requires if it does work, tesdata is data that will contain broken code if it contains any code at all, and _dirs are supposed to be ignored by the compiler so trying to parse in in golist often panics.)

I should also say, from a theoretical POW golist may be doing the right thing, the main difference between Jan and me is that I have a large pool of specs for existing Go projects, so I tend to notice when the theory and the practice do not match (like: upstreams commit working examples, upstreams don't put broken code in testdata of _dirs)

The golist is implemented to recognized the same set of resources as the upstream go list (since it's built on that). As long as the go list does not recognizes the testing resources, I can extend the implementation to go beyond the default go list behavior as we discussed offline. Yet, providing the solution as an experimental one. I am in favor of whitelisting anything that we consider as part of the testing or examples resources. I will need the functionality anyway so all the Go projects can be processed automatically without a manual intervention.

I want Fedora Go macros that work by default on real-world Go projects without needing to specify in all specs to ignore parts we know are most often broken and clearly unneeded in production.

Regards,