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.

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to