[SOLVED] Does Community subscription come with deb-src?

[esi_y]

It's stated what you get if you pay for and if that is not to your liking, don't do it. What other commercial open source project in the Debian realm does this?

I am not sure what you are getting at. The whole point of GPL licenses (parts of PVE are arguably derived work products, so is subject to that) requires corresponding sources to be shared. The whole deb-src is exactly for that.

It is also fine to share the said sources in other ways, e.g. git, but if you do share a massive blob without any markings and call it corresponding source, that's not what it is.

Have you seen how the GPL is treated by most of the companies using Linux as their underlying system? You get once a gigantic tar ball and that's it.

Which companies are you getting at? Because I can get specific package's sources off RHEL (alongside the 16GB ISO) at any point:

That's way, way worse than providing a git repository with all its sources and you can track the changes from version to version.

There's nothing wrong with even "massive tarball" as long as it is clear what is "corresponding source" in that. Git is fine too, as long as it is clear what's corresponding to what.

My point being: Nowadays on no-subscription repo, I believe what you get is exactly what got "bump to version" commit message. So you can be building it quite conveniently on your own (not as conveniently as tagging would allow, but it's not impossible).

On the enterprise repo, you cannot - you would have to manually carving out the sources for each and every package based on that bump comment which is not even officially recognised way of doing it.

I've signed papers like this for other OpenSource projects in the past, therefore it is common for me. How would you otherwise forfeit the copyright?

The point is, you absolutely do NOT HAVE TO, not in order to contribute.

At least here in Germany, everything I write is copyrighted by default so that no one can use it directly unless I explicitly forfeit my rights to it.

Not at all - you do not have to assign copyright to contribute. Strictly speaking Proxmox did not even take that version of the CLA, they took the weaker sublicensing one. But you do not have to do that either.

Most people don't know this and think "it's on the internet, therefore it is free", which lead to a lot of written warnings and sueing.

You can also not have CLA, instead rely on e.g. Developer Certificate of Origin. But that said, you can absolutely also have a CLA that:

1) Does not assign copyright (already the case of Proxmox);
2) Does not require granting beyond AGPL rights, e.g. transferability and sublicensing.

EDIT: Coincidentally, other completely comparable projects - ask contributors for the same license that they release their project under and DCO only:
- https://github.com/lxc/incus/blob/main/CONTRIBUTING.md
- https://github.com/chef/chef-oss-practices/blob/main/DCO.md

Just posting a patch somewhere online will not automatically make it AGPL, it's still mine.

It is still yours even if you license it out under AGPL and that's not a problem, never been.

If they would use it directly and I would issue a written warning claiming my copytight, they would be in deep trouble.

This is a misrepresentation how it works, simple example making it trivial: apply the same to the AGPL that you received PVE under - they did not assign you any copyright and they cannot sue you for using it, ever. If you were to sublicense it under other than AGPL license that's a different story then.

it makes total sense to me that you need to sign the papers

The content of the paperwork matters, not the act.

I put the CLA topic here:
https://forum.proxmox.com/threads/pve-licensing-and-contributing.153198/#post-697933

In this thread, I would just stick to the "corresponding sources" topic, but I am happy to reply further if you wish so to both (each separately).

 

[esi_y]

@UdoB I appreciate you liking (all parts?) of @LnxBil post, but what's the problem of having a discussion on the actual topic? Having sources corresponding to what you currently run in production is something everyone claiming "open source" label should be interested in.

This for me is much bigger topic than the Contributor agreement (if I do not like it, sure I can just not contribute).

Imagine you are running lots of application on your smartphone that are "open source", but you cannot build them, how do you really know what you are running? There's people who care about this and beyond even in your "region": https://reproducible-builds.org/events/hamburg2024/

The one important consideration for a NON-PROPRIETARY hypervisor should be that I can build production from source. Not because I do not want to pay for it, that's nothing to do with FREE in the GPL licenses. RHEL has their sources paywalled too, no problem. But there they are.

 

[UdoB]

@UdoB I appreciate you liking (all parts?) of @LnxBil post, but what's the problem of having a discussion on the actual topic?

No problem. I am just not interested in deb-src, so no discussion from me.

And I am fine with the decisions Proxmox - the company - makes. Even though I do not understand all of them. But hey, while we pay for some subscription licenses at my dayjob I am really very happy to get the very same software for my homelab under the chosen license.

 

[esi_y]

No problem. I am just not interested in deb-src, so no discussion from me.

Thanks for the reply.

And I am fine with the decisions Proxmox - the company - makes. Even though I do not understand all of them. But hey, while we pay for some subscription licenses at my dayjob I am really very happy to get the very same software for my homelab under the chosen license.

Just for clarification: I do NOT care as much about the FREE OF CHARGE topic as much as FREE TO MODIFY. I can't modify something I do not have corresponding sources of and I truly do not have it if I cannot rely that I get a fixed set of packages (free or paid) that will build together. I might literally not be able to build from sources my "open source" software that I pay for - that's the offering and that's what my topic was about.

 

[dcsapak]

just to clear up what i feel is the actual misunderstanding here: the packages are the same if the version is the same, and the enterprise repository does not contain any packages that don't also exist on the no-subscription repository. so using git bump commits is the correct way to identify packages

 

[esi_y]

just to clear up what i feel is the actual misunderstanding here

Thanks for the reply! Your feeling is partially right.

the packages are the same if the version is the same

I did not as much suspect they would differ, but that there are packages in the enterprise repo that are not really in git, e.g. something gets hotfixed, you have vX.Y.3 in the enterprise repo, vX.Y.6 in the no-subscription repo, now you need to backport it, but of course do not want to include all the new things in just yes, so create package vX.Y.3-hotfix1 that never gets to be seen in the public git repo.

and the enterprise repository does not contain any packages that don't also exist on the no-subscription repository

This clears it out, but I then wonder how you handle such situation described above.

so using git bump commits is the correct way to identify packages

Thank you very much! This is nowhere documented.

 

[dcsapak]

This clears it out, but I then wonder how you handle such situation described above.

AFAIR there was no need for something like that yet, but i could be wrong of course. In any case, there would be the corresponding bump commit somewhere in the git repo

Thank you very much! This is nowhere documented.

what i also forgot to mention, in addition to the bump commit, there is also '/usr/share/doc/<package>/SOURCE' which also contains the correct repository + commit for the installed package

 

[esi_y]

there is also '/usr/share/doc/<package>/SOURCE' which also contains the correct repository + commit for the installed package

OMG! This is what I needed to know. Thanks a lot, unless this is some under the table secret, I would suggest to add it to the developer documentation.

NB I do not know why some people think I am going after some custom shady builds with this. I actually do not care if it comes as deb-src or otherwise, I just want to be able to custom build e.g. one component and only when my patches need manual intervention, get to do some manual work, otherwise automate it in some error-proof process.

Thanks a lot, Dominik!