Great thanks Jarek. So am I right in saying in the source release we vote for: 1. we include all source files (easy) 2. we need to include the code to generate the convenience package(s) in the source release.
Clarification: do we need to have the build process automated as in automated via github actions? Or is it enough to just include the code that would be run to create the convenience packages? Cheers, Stefan On Sun, Oct 19, 2025 at 11:34 PM Jarek Potiuk <[email protected]> wrote: > *TL;DR; What you publish in PyPI are not "source packages" releasing of > which is a legal act of the Foundation. They are convenience packages, so > they do not have the same "restrictions" - however you should make sure > that whatever you release as "convenience packages" also referred to as > "compiled packages" that can be automatically built from the sources. See > [1] * > > More details: > > You can see what we do in Airflow. We have different packages. Sources are > -sources.tar.gz, and there it's simply git-archive - which includes all > typescript files, but none of the resulting "processed" and "minified" > javascript. > This is also why in airflow we have `hatch` as build backend - as there we > have a "custom' hook that: > > * installs node and all the tools and transpiles the javascript > * also produces git hash when run from sources so that we have commit hash > info, not only version available in the UI when you look at version > > Then, we have separate whl and sdist packages. And when we release and vote > and do all the verifications by PMC members (including reproducibility > checks), we do that for all of those: > > * sources.tar.gz > * sdist.tar.gz > * .whl > > Also this is fine to vote on because the code in .whl and .sdist has been > really "automatically produced" (given the right tools and environment) > from the sources, so as long as this condition is met, it's ok to release > it. In fact the `.whl` and `sdist` packages are not the "source release" > that you are supposed to vote on in the release process (only sources are) > - they are "convenience packages" that are result of processing those > sources - even if pretty much all regular users would use those convenience > packages, this is the "sources.tar.gz" which is legally and officially > released by the ASF and this is what legally three PMC members voting on > make a "legal act of the Foundation". The convenience packages are just ... > convenience. > > We (in Airflow) do all the voting and releases and PMC checks of checksums, > signatures and reproducibility (our sdist and whl package are bit-to-bit > reproducible) so that we know that the convenience packages were simply > result of automated process applied to the sources - and 3 PMC members > confirm it independently (this way we know that release manager did not > inject anything - i.e. "trust no one" aka prevent "xz" kind of thing) - but > this is not technically required by ASF, this is something we do extra as > "additional security measure". We do not do it (reproducibility check) for > container images (which are another type of convenience packages) produced > in DockerHub (but there we have automated action that builds such > images and we use the PyPI packages released as convenience images. We > decided to host those whl and sdist packages also in "downloads.apache.org > " > (https://downloads.apache.org/airflow/3.1.0/ for example) alongside the > -sources.tar.gz but technically we do not have to. In our case, also > because of binary reproducibility it's really nice because even if you are > using PyPI to install those packages, you can binary compare those PyPI > packages with those that are in "downloads" and they are **the same**. > > Again - the important part is the "automate" part. If you can take source > packages released as -sources.tar.gz - and (using appropriate tools and > environment) - produce the files that you package in convenience packages, > this is "OK" - automatically generated files are not even supposed to have > licence information. > > I hope it helps. > > [1] https://www.apache.org/legal/release-policy.html#compiled-packages > > J. > > > On Mon, Oct 20, 2025 at 5:21 AM Stefan Krawczyk <[email protected] > > > wrote: > > > Hey All, > > > > I think we're pretty much there to make a release: > > > > 1. Docs have ASF (download page will come once we release) > > 2. Files have headers > > 3. Removed dependency on mozilla licensed JS lib -- so all JS libs are > > apache 2 compatible. > > 4. Added requisite files: license, disclaimer. > > > > My only question is, what is considered "source" for burr since we > package > > JS into the python? > > > > Options: > > 1. We don't package the JavaScript. This requires someone to npm install > > things. But IIUC this means that what we upload to pypi would be > different. > > i.e. it would contain "code" that wasn't voted on because we add in the > JS > > bundled code? > > 2. We do package the JavaScript. The JavaScript would be minified -- so > it > > would be a transformation of the originally licensed code. This then > means > > what is in pypi matches, however we'd need to make sure that the license > > file contains mentions to the code that is not licensed with apache 2. > > > > I think option (2) should work. > > > > Any thoughts? Mentors? I'm happy to ask on the main incubator list about > > this too. > > > > Cheers, > > > > Stefan > > >
