*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 >
