On Mon, Aug 11, 2014 at 8:34 AM, Mike Dewhirst <mi...@dewhirst.com.au> 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. > Firstly, I am not a lawyer, and this is not legal advice. Sounds like you're pretty much describing the terms of the LGPL to me. LGPL is designed to enable the sort of use case where there is a proprietary body of code that needs to use an open source body of code; the LGPL requires that the open source code remains open source; if modifications are made to the open source component and distributed, the modifications are also distributed; but the proprietary code remains proprietary. The only caveat/warning I can think of is one of legal ambiguity when it comes to languages like Python. LGPL was drafted in the times of languages like C, where "linking" clearly means something. What does "linking" mean in the context of Python? Execution? Import? It's unclear. This is a legal ambiguity that hasn't been tested in the courts, and ultimately the terms of a license are only as good as the first case law on the subject. This is uncharted legal territory - I'm not aware of any case law approaching this issue (again, IANAL, but I keep abreast of developments due to my commitments with the DSF) - so the best you can hope for is an interpretation that is consistent with cultural usage. I'd also strongly advise against using a license outside the "big 5" (GPL, LGPL, MIT, Apache 2.0, BSD 3-clause) unless you've got a *really* good reason (like an existing large project requirement forcing you to use MPL or EPL). Yes, the OSI has approved dozens of licenses, but the big ones have received the most legal scrutiny. Given that *no* license has really been tested in the courts, you're best served sticking with one that has had plenty of academic attention. You also do a service to the broader community by reducing license proliferation. If I've got 5 projects that are all BSD, I know they all play together, and as a moderately informed developer I know what my obligations are. A collection of BSD projects plus one LGPL project - it's a little more complicated, but still reasonably well understood. An amalgam of a dozen esoteric licenses? As a project author, I wouldn't be able to guarantee that they're mutually compatible licenses, and as a user I wouldn't feel confident knowing that I'm meeting all the obligations imposed by the complete set of licenses. Yours, Russ Magee %-) -- 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/CAJxq84-JX6Qmz9atiFRfVpnV_oJd%2B08tM%2BbhNFR6tWzO0Vncug%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
