Cross posting again to thank everyone for responding ...
I'm going with LGPL.
Oliver suggested I consider Mozilla Public License and part of a
stackexchange conversation goes [1] ...
The major difference is how MPL / LGPL licensed code must be linked
into the project. MPL source code files can be directly copied into a
(possibly) proprietary software project (static linking), while LGPL
licensed code must be dynamically linked (loosely linked to the
possibly proprietary software project, so that end-users can switch
out the licensed software library for another version of the licensed
software library).
... but in the context of Python running in a server (IANAL) I can't see
"linking" being applicable to the point where it would prevent the real
objective of ensuring my source (modified or not) is available for the
end user of the whole work. Running on someone else's server makes it
moot and on the end-user's server it is fait accompli.
Russ suggested staying within the big five and that was why I was
leaning towards LGPL anyway. My thought was about who might be
interested in helping if the license is breached. MSF or FSF? I assume
FSF because that is their entire mission.
In truth I was originally going for GPLv3 until I realised it would
prevent some of my intended users from interfacing their software with mine.
Again - thanks to all
Cheers
Mike
[1]
http://programmers.stackexchange.com/questions/221365/mozilla-public-license-mpl-2-0-vs-lesser-gnu-general-public-license-lgpl-3-0
On 11/08/2014 10:34 AM, Mike Dewhirst wrote:
Apologies for cross-posting
I'm getting near to open sourcing a Django project and have to choose
an appropriate license. Can anyone help me choose?
I have settled on the following requirements ...
1. Project source must be freely available for end users to view and
download and modify and further distribute to others
2. But if user modified source is distributed the modified source
must be freely available for others to view and download and modify
and be subject to the identical license as the project source
3. However, if the user modified source is kept in-house and not
further distributed the changed source may be kept private or offered
back to the project as a patch at the whim of that user.
4. Project (and user modified) source may be combined with
proprietary software but the project (or user mofified) source
component remains subject to the same license. It cannot be
distributed as a combined whole under any other license than the
project license.
5. But it can be distributed as a combined whole with proprietary
software provided the project (or user modified) source component is
freely available for end users to view and download and further
distribute to others under the project license even if the
proprietary component is not.
BTW, Django doesn't require that my project use the Django license
and of course I won't be distributing Django.
I'm leaning towards the LGPL but would appreciate feedback from
anyone with contrary views.
Thanks
Mike _______________________________________________ melbourne-pug
mailing list melbourne-...@python.org
https://mail.python.org/mailman/listinfo/melbourne-pug
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/53E9631C.6050700%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.
