[Python-Dev] Sumo (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Thu May 27 18:31:56 CEST 2010

Lennart Regebro writes:

If licensing is a problem I guess you'd need to have permission to relicense them all to the Python license,

Licensing compatibility is only a problem for copyleft, but most copyleft licenses have "mere aggregation is not derivation" clauses.

Corporate concern about knowing what the license is, is a problem. The XEmacs experience I've referred to elsewhere doesn't apply because all our stuff is GPL, and therefore all our stuff has to be GPL. :-( It's not obvious to me what the resolution is, although lots of distributions now have some way to find out what licenses are. GCC (and soon GNU Emacs) even have a way to check GPL-compatibility at runtime (inspired by the Linux kernel feature, maybe?)

Perhaps the sumo infrastructure could provide a license-ok-or-fatal feature. Eg, the application would do something like

sumo_ok_licenses = ['gplv2','bsd','microsoft_eula']

and the sumo version of the package's init.py would do

sumo_check_my_license('artistic')

and raise LicenseError if it's not in sumo_ok_licenses. In theory it might be able to do more complex stuff like keep track of declared licenses and barf if they're incompatible.

This scheme probably doesn't save lawyer time. The lawyers would still have to go over the actual packages to make sure the licenses are what they say etc. before going into distribution. Its selling point is that the developers would be warned of problems that need corporate legal's attention early in 90% of the cases, thus not wasting developer time on using packages that were non-starters because of license issues.

which would be problematic. But otherwise having a team of people overseeing and bundling all this might not be that much work, and you'd avoid the bloat by not installing all of it. :-)

As I've argued elsewhere, bloat is good, for some purposes.

Or would this not fool the company trolls?

It will satisfy some, and not others, in my experience, described elsewhere.

More information about the Python-Dev mailing list