= phenomenon = For the windows build of Fedora Media Writer there is bundled a few open source tools, dd, python, qt. The change did not lay out but there is massive release engineering implications and it has come to our awareness late and has not been a priority for us as we are working on our own changes.
We are working to resolve the how we build issue, we will not sign and ship code built on a computer under someone's desk. we want to have logs of the build, know where the code came from etc. The change owner had planned to include pre built copies of python, qt, etc we would like FESCo to decide if it is okay to ship copies of open source projects built by third parties(upstreams). Mostly this about making sure everyone has their eyes open around this choice
https://fedoraproject.org/wiki/Changes/LUCasPrimaryDownloadable
= background analysis = In the past I have had guidance (from spot over u-boot builds from vendors) that we can not ship pre built code. If we can build it we must. however in this case we have something used to make it easy for people to deploy fedora. The burden of building and maintaining the whole stack used would be really high for something that gets used very rarely. I feel it would take away resources from building and maintaining the same things inside of fedora. We will be running clamav on the final builds.
= implementation recommendation =
We acknowledge that it is okay for the windows and OSX versions of FMW are using native builds of open source projects from the upstream providers. It has some risk but that is outweighed by the cost of building up and maintaining it all ourselves.
For windows, at least, there's the whole set of mingw packages which as I understand things can build complete windows programs up to and including an installer without any need for an actual windows machine. But I've no idea if it is up to the task of building enough of the stack to make the program in question function.
Who is the developer and why aren't they on CC for this ticket?
I took the package after Luke Macken. I'm putting myself to the cc list now.
Regarding MinGW, you can't build Python with it unless you apply a a huge patch blob that didn't really have any proper review by us. You can see it on [1], there's about 80 patches modifying quite a lot of code. For some reason, the Python upsteram prefers building using MSVC.
[1] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2
I think we can make an easy distinction between rules for shipping code in the Fedora distribution and Fedora-provided code distributed separately, as this is.
I don't think we want to be dropping upstream binaries into the distro proper (at least not yet!), but for the separate case it seems reasonable, provided
The rules I presented in the meeting were basically:
This is a lower priority, since the OS X tool is pushed to Fedora 25, but rather than have the same discussion come up at the last minute:
To get the FMW tool past OS X's Gatekeeper feature, it has to be signed by an Apple issued certificate; to get that cert the developer has to be part of the Apple developer program; and to be part of the developer program requires signing at least two agreements (developer program license agreement, and developer agreement). What I wonder is, a.) whether those agreements are acceptable/advisable for mbriza or some other Fedora developer responsible for the FMW tool to agree to; b.) whether additionally, the Apple app store terms and conditions are compatible with any Fedora approve licenses? e.g. VLC iOS uses LGPL and MPLv2.0 both of which are listed as Fedora approved licenses.
a.) is necessary to get a Apple signed FMW tool that passes OS X code signing check; b.) is necessary to get the FMW tool into the Apple store, and while that's not necessary and hasn't even been suggested by anyone, if it's possible, it reduces hassle and effort by Fedora releng. It'd be built and signed on the developer's system with xcode, and then distribution and installation is all done by Apple.
Obviously all of this assumes the developer (mbriza) wants to deal with OS X and xcode at all. In theory > 99% of the development can happen elsewhere, it just gets code signed and packaged up for submission within xcode.
Replying to [comment:9 chrismurphy]:
This is a lower priority, since the OS X tool is pushed to Fedora 25, but rather than have the same discussion come up at the last minute: To get the FMW tool past OS X's Gatekeeper feature, it has to be signed by an Apple issued certificate; to get that cert the developer has to be part of the Apple developer program; and to be part of the developer program requires signing at least two agreements (developer program license agreement, and developer agreement). What I wonder is, a.) whether those agreements are acceptable/advisable for mbriza or some other Fedora developer responsible for the FMW tool to agree to; b.) whether additionally, the Apple app store terms and conditions are compatible with any Fedora approve licenses? e.g. VLC iOS uses LGPL and MPLv2.0 both of which are listed as Fedora approved licenses. a.) is necessary to get a Apple signed FMW tool that passes OS X code signing check; b.) is necessary to get the FMW tool into the Apple store, and while that's not necessary and hasn't even been suggested by anyone, if it's possible, it reduces hassle and effort by Fedora releng. It'd be built and signed on the developer's system with xcode, and then distribution and installation is all done by Apple. Obviously all of this assumes the developer (mbriza) wants to deal with OS X and xcode at all. In theory > 99% of the development can happen elsewhere, it just gets code signed and packaged up for submission within xcode.
This is up to discussion. If we want to have it signed by Apple and in the Apple Store, I'm willing to be the one to bite the bullet. Regarding license of the code, I'm approaching having 100% of the code being written by me so relicensing to whatever license is compatible with both Fedora and Apple will be possible too. (And I don't even mention a possible C++ port of the tool to reduce the overall hassle with building.)
The legal side of the thing, on the other hand, is a problem others will help with. And that's not only the signing of the agreements themselves but how such action stands from the Fedora point of view.
So, since we deferred this to F25, can we have a new updated change proposal with what is intended to ship for f25 that we can evaluate?
ie, is there going to be a re-write to c++? Will mingw work for the windows binary? What licenses and such do we need to sign on the platforms we have? Will cross compile work for osx? etc.
Login to comment on this ticket.