On Mon, 1 Jul 2019 13:34:26 +0200 Richard Brown <RBrownCCB@opensuse.org> wrote:
On Mon, 1 Jul 2019 at 13:19, Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 1 July 2019 12:43 Richard Brown wrote:
1- Almost all code developed by SUSE should be open source 2- All that open source code should be open for collaboration and contributions 3- SUSE-centric locations like github.com/SUSE should only be used when SUSE intends to take full responsibility of the codebase. Else openSUSE-centric locations like github.com/openSUSE should be used. 4- Anything ended up in SLE or SLE based products should be following Factory First
I think the vast majority of the internal tools you are discussing currently do not comply with at least one of the four points above, and until those tools are compliant with SUSE's own public policy, I consider that a hindrance to openSUSE.
We can split hairs about whether or not SUSE should actively submit the tools to openSUSE - I can agree the policy is not clear on that, but it's debating semantics as long as those tools are not open for collaboration and contribution.
I'm afraid you are talking about something different than what I and (the other) Michal meant. We were not talking about internal tools. This was about projects which are open source and publicly available (e.g. on Github) but which do not have packages in Factory.
Many of these projects have actually working and sometimes even well maintained packages for openSUSE and SLE but they are kept in someone's home project (sometimes even in a project which otherwise serves as Factory devel project) but that someone doesn't feel having to deal with Factory review process and bots is worth the extra convenience of having the package "in the distribution".
Fair enough, so then lets talk about non-Factory packages. If a package has not been sent through the Factory process, then it hasn't had the necessary quality or legal reviews, the very reviews which are enforced by the bots being discussed in this thread.
The quality reviews are essential for the package to be considered suitable for openSUSE / SUSE in a trademark/copyright sense, which is essential for ensuring the brands remain popular. Our brand is a topic our lists have shown a great interest in lately so I think it's safe to say that regardless as to whether the Project keeps its name or not, the consensus is that the Project shouldn't take unnecessary risks with it's brand. Redistributing unchecked packages, would be a significant risk with potentially catastrophic consequences.
The legal reviews are even more important, given the responsibility which SUSE / the openSUSE Project take when redistributing software under various licenses, including the GPL. It risks this projects very existence if we were to inappropriately redistribute software with incompatibly, incompletely, or otherwise non-compliantly with the source code licenses of our packages.
What people do in their home project is their own business, but as there is no guarantee a home project package is legally sound, nor that it will be there tomorrow [1], I consider it frankly irresponsible to suggest that approach to software distribution is acceptable.
It is the norm for tools that are not practical to distribute in a release. Either because you always need the latest version regardless of codestream or because it does not make sense for people other than SUSE employees to use them. The only change your policies make is adding to the list tools that might have been practical to have in a release but due to technical difficulties with keeping them there they fell out or never got in to start with.
If a package hasn't gone through the Factory process, ie. it is not in either Tumbleweed or Leap, then the package cannot, should not, and must not be considered an output of the openSUSE Project and therefore it's quality and legal correctness cannot be attested to.
And I'm pretty sure our users only want software that works and that they can use and redistribute legally... or am I way off the mark with that?
Then let's focus the review on quality of the software and legal issues and not on formalism like listing patch files in the changelog. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org