Re: a Free Platform License?
The tl:dr version: just use the GPL, or the AGPL if you must.
I don't think whether your license is DFSG-compliant is the important
issue here; I think the important issue is that your proposed license is
not well-understood, has practical problems, and is contributing to
license proliferation. (Thoughts on DFSG compliance later.)
By being a copyleft license with more restrictions than the GPL, I believe
your proposed license is non-GPL-compatible. This isn't necessarily a barrier
to DFSG compliance, but it's a major practical problem. You can't use
GPL'd libraries in a non-GPL-compatible but copyleft work, and libraries
under weak-copyleft licenses like the LGPL - particularly version 2, less
so for version 3 - can give you subtle licensing interactions that are
difficult to disentangle.
I for one would be reluctant to contribute significantly to a package under
the license you propose; I'm already somewhat concerned about the AGPL,
which raises some interesting practical problems (particularly if parts
of an AGPL webapp are re-used in something that isn't a webapp).
On Mon, 28 Nov 2011 at 10:00:05 -0500, Clark C. Evans wrote:
> The work in question is a complete medical informatics system.
> It is written in Python, requires PostgreSQL and is typically
> deployed on FreeBSD.
Suppose you'd licensed this under the (A?)GPL. I don't know much about
medical informatics, but it seems to me that the options for a potential
user of this software (a medical practitioner?), in increasing order of
Free-ness, would be:
(A) pay for a proprietary medical informatics system and run it on
a proprietary (or perhaps even Free) OS;
(B) fork your system (since presumably you're not making much effort to be
portable to Windows or Mac OS X), or a competing Free system if there is
one, and port it to Windows or Mac OS X;
(C) run your system, or a competing Free system, on a Free OS.
The only thing you seem to be trying to prevent is that someone does option
(B) using your system. If a proprietary OS doesn't have some sort of benefit
to them (perhaps just familiarity, perhaps they need to run something
else on that computer that requires a proprietary OS, or perhaps there's some
misguided government/regulatory requirement that they use a proprietary OS),
they'd do (C) regardless of your license, rather than going to the considerable
effort involved in (B).
Is your system really sufficiently far ahead of its proprietary competitors
that you think a medical practitioner with such a strong preference or
requirement for a proprietary OS would prefer (C) over (A)?
(Of course, if you have Free competitors with a more normal license, the
second choice for a user with a proprietary OS is easy - use the competing
Free system instead.)
Some interesting corner cases for you to think about:
* If your software is ported to run on Wine, an LGPL implementation of the
Windows API, is that a free platform? (How could it not be, given that
its license is the same as glibc?) If it turns out the same binaries run
correctly on a Windows machine, have you achieved anything by using this
license, apart from annoying your users?
* If your software is ported to run on GNUstep on Darwin, is that a free
platform? If it turns out the same binaries run correctly on Mac OS X,
have you achieved anything by using this license?
* If I run your software in a FreeBSD or Linux virtual machine (e.g.
VMWare or VirtualBox) on a Windows host, is that allowed? Why/why not?
* A PC running your software has a non-free BIOS, and runs FreeBSD with
binary-only drivers (nVidia!). Is that allowed? Why/why not?
What if the binary-only drivers are needed to boot (network card firmware)?
Since I promised I'd mention DFSG-compliance-or-not: some debian-legal
regulars disagree with the ftpmasters' decision to allow AGPL software
into Debian. I personally think the AGPL is a Free license, but one with
significant practical problems.
S
Reply to: