OS license requirements

[Mike Dewhirst]

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

[Paul Greenberg]

Hi Mike,

I will be able to help you out. Are you local to US?

Best Regards,
Paul Greenberg, Esq.

Law Office of Paul Greenberg
530 Main Street, Suite 102
Fort Lee, NJ 07024
E-mail: pa...@greenberg.pro
Tel: 201-402-6777
Fax: 201-301-8876
Cell: 212-380-7343
Web: http://www.greenberg.pro/
Twitter: @nymetrolaw

CONFIDENTIALITY NOTICE: The information contained in this email, including any attachment(s), is confidential information that may be privileged and exempt from disclosure under applicable law, and is intended only for the exclusive use by the person(s) mentioned above as recipient(s). If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is strictly prohibited and may be unlawful. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.

CONFIDENTIAL: ATTORNEY/CLIENT PRIVILEGED; ATTORNEY WORK PRODUCT The information contained in this email is intended for the individual or entity above. This email is protected by the Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521 and is legally protected by the attorney/client privilege and/or work product doctrine. If you are not the intended recipient, please do not read, copy, use, forward or disclose this communication to others; further, please notify the sender by replying to this message and then delete this message from your system. Thank you.

________________________________________
From: django...@googlegroups.com <django...@googlegroups.com> on behalf of Mike Dewhirst <mi...@dewhirst.com.au>
Sent: Sunday, August 10, 2014 8:34 PM
To: Melbourne Python Users Group; django...@googlegroups.com
Subject: OS license requirements

Apologies for cross-posting

Thanks

Mike

--
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...@googlegroups.com.
To post to this group, send email to django...@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/53E80F97.8030008%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

[Collin Anderson]

LGPL sounds the closest to me.

[Paul Greenberg]

Perhaps, OSL would work better in this case?

http://en.wikipedia.org/wiki/Open_Software_License

Open Software License The Open Software License (OSL) is a software license created by Lawrence Rosen. The Open Source Initiative (OSI) has certified it as an open-source license... Read more...

---

From: django...@googlegroups.com <django...@googlegroups.com> on behalf of Collin Anderson <cmawe...@gmail.com>
Sent: Monday, August 11, 2014 9:45 AM
To: django...@googlegroups.com
Cc: melbou...@python.org
Subject: Re: OS license requirements

 

LGPL sounds the closest to me.

--

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...@googlegroups.com.
To post to this group, send email to django...@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/1fbc42b4-7f95-4d70-8a96-acd79ae27844%40googlegroups.com.

[Russell Keith-Magee]

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 %-)

[Mike Dewhirst]

Thanks Paul - no, Melbourne Australia

Cheers

Mike

[Paul Greenberg]

Hi Mike,

To give you the advice you are looking for I would need to have an idea of what your project consists of. Sometimes, the subtleties related to inner-workings between different software/hardware modules or components may change your approach to licensing.

As such, you may create your open source license. After all, a license is a simple contract. A canned approach is not always better.

Perhaps, you could let us know what is your project about?

Regards,
Paul

________________________________________
From: django...@googlegroups.com <django...@googlegroups.com> on behalf of Mike Dewhirst <mi...@dewhirst.com.au>

Sent: Monday, August 11, 2014 7:58 PM
To: django...@googlegroups.com

Subject: Re: OS license requirements

Thanks Paul - no, Melbourne Australia

Cheers

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53E958A4.8080704%40dewhirst.com.au.

[Mike Dewhirst]

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

> Mike _______________________________________________ melbourne-pug
> mailing list melbou...@python.org
> https://mail.python.org/mailman/listinfo/melbourne-pug
>

[Tom Evans]

On Tue, Aug 12, 2014 at 1:43 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote:
> 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.

Affero GPL covers this. Bear in mind that each license that adds
protection also adds restrictions and reduces the potential number of
users. I love BSD licensed software, it is easy to integrate in to all
projects. LGPL software is usable in less projects, GPL in even less,
and Affero GPL is so restrictive I tend to rule it out without
consideration.

>
> 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.
>

I very much doubt either of them would be particularly interested
beyond publicising the alleged breach for you. As the license holder,
responsibility for enforcement would belong to you.

Cheers

Tom

[Russell Keith-Magee]

I think you'd be surprised. The MSF position isn't as clear, but the FSF and SFLC have both filed amicus curiae briefs in defence of the goals of the GPL, covering issues of  patent law, copyright reform, and so on. The FSF exists to make sure Free software is possible at all, the (L)GPL is the instrument they've chosen to achieve that, and from what I've seen they're willing and able to defend that position. 

Don't get me wrong - I'm not expecting the FSF to ride in and cover all your legal costs for every potential violation - but if there was any risk that case law was about to be made that undermined the GPL, I think you'd find some big guns at your disposal.

Yours,

Russ Magee %-)

[Mike Dewhirst]

Further to this, for the SharedSDS project licensing is now settled on GNU GPL v3 for the bulk of the software. API code will be GNU LGPL v3

Mike