Most compatible license with LPPL?
Bil Kleb
I'm trying out Google's project hosting service for
a couple of LaTeX projects,
http://aiaa-latex.googlecode.com
http://nato-rto-latex.googlecode.com
but apparently due to their campaign to reduce the
proliferation of Open Source licenses, they only give
you a choice of 8:
Apache 2.0
Artistic/GPLv2
GNU GPLv2
GNU GPLv3
GNU LGPL
MIT
Mozilla Public 1.1
New BSD
Which one is most compatible with LPPL?
Or when I make releases to CTAN, can I just choose to
release those under LPPL?
License clueless,
--
Bil Kleb
http://fun3d.larc.nasa.gov
Will Robertson
>
> Which one is most compatible with LPPL?
It's not so much which is most compatible as opposed to which one
suits your purposes. I'm pretty vague on the technical details of
those licenses, but I'd think that either New BSD or MIT is probably
the closest -- essentially anyone "inspired" by your code can use it
in any way they wish, even if the end result is not free itself.
Note that TeXLive is happy to include any such freely licensed code,
so LPPL or not isn't a problem concerning various TeX distributions.
> Or when I make releases to CTAN, can I just choose to
> release those under LPPL?
Probably a bad idea -- the Google guys are pretty unhappy with people
hosting the project under one of their canonical licenses and
releasing it under another... (dunno about dual-licensing, though).
Hope this helps,
Will
Frank Mittelbach
> I'm trying out Google's project hosting service for
> a couple of LaTeX projects,
>
> http://aiaa-latex.googlecode.com
> http://nato-rto-latex.googlecode.com
>
> but apparently due to their campaign to reduce the
> proliferation of Open Source licenses, they only give
> you a choice of 8:
>
> Apache 2.0
> Artistic/GPLv2
> GNU GPLv2
> GNU GPLv3
> GNU LGPL
> MIT
> Mozilla Public 1.1
> New BSD
>
> Which one is most compatible with LPPL?
there isn't really something like "most compatible" with LPPL.
LPPL attempts to preserve the fact that something like LaTeX is a language
which is used for communication, that is if you write a LaTeX document you
expect to be able to send it to me and to work at my end like it does at
yours. This is like when people writing a program in C or whatever they
expect it to compile with the same meaning (as far as statements of the
language are concerned) in different places.
While with most languages it is a reasonable assumption that thier compilers
work in the same way in different places (within limits, I know how much
you have to adjust :-)) the situation with LaTeX as a language is worse:
nearly every package defacto extends the language and so arbitrary changes
to packages will severely limit the use of that language for exchange.
So what LPPL does in a nutshell is to say, ok this piece of software is free
for you do use/modify etc but if you modify you have to ensure that it will
be clear to the users that they are using a variation of the original (in
case of packages the suggestion is, use a different package name, then
things can coexist, though since LPPL 1.3 this isn't a requirement) ---
this is a more formalized (and nowadays perhaps more flexible version) of
Don Knuth original approach with TeX: do what you like with the program and
its algorithms but if you modify it call it something other than TeX.
so if you are, for example, writing a class for some journal or publisher
then the use of LPPL makes a lot of sense, since it really doesn't help
your users if somebody thinks that your "margins", say, are having far too
much space, and is therefore distributing the package with changed values
under its original cover (perhaps with some comment saying so in the file)
and then a user writes an article to fit the required 8 pages an>
> Or when I make releases to CTAN, can I just choose to
> release those under LPPL?
>
> License clueless,
> --
> Bil Kleb
> http://fun3d.larc.nasa.gov
d at the publisher it comes out as nine or ten as there they use their
original version of the file.
none of the above licences would prohibit this kind of behavior and soon you
might find different versions in different distributions making reliable
exchange and communication difficult to impossible.
so you have to take your pick: for certain type of programs, GPL etc etc are
by far the simpler to use and probably more appropriate licenses, for
language extensions (and LaTeX code usually falls in this category) LPPL in
my opinion is the better choice, but then I'm biased.
cheers
frank
Will Robertson
project.org> wrote:
> So what LPPL does in a nutshell is to say, ok this piece of software is free
> for you do use/modify etc but if you modify you have to ensure that it will
> be clear to the users that they are using a variation of the original (in
> case of packages the suggestion is, use a different package name, then
> things can coexist, though since LPPL 1.3 this isn't a requirement)
Essentially I think of LPPL as like a BSD license with an enforced
politeness clause, in that you can change the file and distribute it
however you like, even with a different license -- as long as the
users of the file are told that they're using a modified work.
Say I took array.sty, mucked about, and added the line
\typeout{This is Will's version of array, not Frank&David's!}
That's enough to abide by the terms of the LPPL, right?
But not really in the spirit of the license.
Whereas if it were all BSD-licensed, changes like this would generally
be made simply out of politeness but not necessarily. On the other
hand for something like LaTeX you really want to ensure that people
are aware of and striving for compatibility.
Will
(struggling to actually work out what the differences between all
these licenses actually are!)
Robin Fairbairns
>On Sep 24, 2:37 am, Frank Mittelbach <frank.mittelb...@latex-
>project.org> wrote:
>> So what LPPL does in a nutshell is to say, ok this piece of software is free
>> for you do use/modify etc but if you modify you have to ensure that it will
>> be clear to the users that they are using a variation of the original (in
>> case of packages the suggestion is, use a different package name, then
>> things can coexist, though since LPPL 1.3 this isn't a requirement)
>
>Essentially I think of LPPL as like a BSD license with an enforced
>politeness clause, in that you can change the file and distribute it
>however you like, even with a different license -- as long as the
>users of the file are told that they're using a modified work.
>
>Say I took array.sty, mucked about, and added the line
> \typeout{This is Will's version of array, not Frank&David's!}
>That's enough to abide by the terms of the LPPL, right?
no; if you change it, and you're not the designated author, you have
to change the file name. that way, a document that wants array gets
it, and documents that want wills-array aren't in danger of getting
array at some other site.
>But not really in the spirit of the license.
a fortiori, yes.
>Whereas if it were all BSD-licensed, changes like this would generally
>be made simply out of politeness but not necessarily. On the other
>hand for something like LaTeX you really want to ensure that people
>are aware of and striving for compatibility.
indeed, there's nothing to stop you distributing a revised version of
a c++ compiler that only compiles java. it would be a big deal to
make such modifications, but there's nothing to stop you doing so.
lppl recognises the fact that modifications to the language are much
easier to do in latex. your patched array.sty could change the
semantics of arrays in a document, or it could define a command that
clashed with some other major software; the school of users who don't
ordinarily read logs could be seriously confused by such changes.
>(struggling to actually work out what the differences between all
>these licenses actually are!)
but frank's already explained all of the above (either in the text of
the licence, or in his earlier post).
--
Robin Fairbairns, Cambridge
Will Robertson
> Will Robertson <wsp...@gmail.com> writes:
> >On Sep 24, 2:37 am, Frank Mittelbach <frank.mittelb...@latex-
> >project.org> wrote:
> >> So what LPPL does in a nutshell is to say, ok this piece of software is free
> >> for you do use/modify etc but if you modify you have to ensure that it will
> >> be clear to the users that they are using a variation of the original (in
> >> case of packages the suggestion is, use a different package name, then
> >> things can coexist, though since LPPL 1.3 this isn't a requirement)
>
> to change the file name.
Isn't this no longer true since v1.3 of the license? (See Frank above)
It's recommended -- and you'll be making a rather poor name for
yourself if you don't do it -- but the license no longer strictly
requires it.
> >(struggling to actually work out what the differences between all
> >these licenses actually are!)
>
> but frank's already explained all of the above (either in the text of
> the licence, or in his earlier post).
Oh, I mean in general. Like what the difference between releasing
something under the BSD license as opposed to saying "Public Domain"
in the source. And the difference between the MIT license and the BSD
license. Or Apache vs. GPL. Or LGPL vs. GPL :) What a mess...and
reading through legalese isn't my idea of pleasure.
(I do like the formalisation of maintainership in the LPPL. That seems
rather unusual in comparison to the other licenses I've read.)
Cheers,
Will
Frank Mittelbach
> Robin Fairbairns wrote:
>> Will Robertson <wsp...@gmail.com> writes:
>> >On Sep 24, 2:37 am, Frank Mittelbach <frank.mittelb...@latex-
>> >project.org> wrote:
>> >> So what LPPL does in a nutshell is to say, ok this piece of software
>> >> is free for you do use/modify etc but if you modify you have to ensure
>> >> that it will be clear to the users that they are using a variation of
>> >> the original (in case of packages the suggestion is, use a different
>> >> package name, then things can coexist, though since LPPL 1.3 this
>> >> isn't a requirement)
>>
>> no; if you change it, and you're not the designated author, you have
>> to change the file name.
>
> Isn't this no longer true since v1.3 of the license? (See Frank above)
> It's recommended -- and you'll be making a rather poor name for
> yourself if you don't do it -- but the license no longer strictly
> requires it.
correct.
The license (v1.3) states
If a component of this Derived Work can be a direct replacement for a
component of the Work when that component is used with the Base
Interpreter, then, wherever this component of the Work identifies itself to
the user when used interactively with that Base Interpreter, the
replacement component of this Derived Work clearly and unambiguously
identifies itself as a modified version of this component to the user when
used interactively with that Base Interpreter.
so technically you are ok with changing say the the \ProvidesPackage
argument to idenfiy your version as not being array but something else (and
that is most easily achieved by changing the file name, though that isn't a
requirement any more). whether you are ok if you simply drop in some
\typeout note is a matter of opinion I guess.
but in any case this is different from expecting people to do this out of
politeness (as often people simply don't realize that they change semantics
with their "harmless" improvements and thus see no reason to indicate their
change prominently)
> (I do like the formalisation of maintainership in the LPPL. That seems
> rather unusual in comparison to the other licenses I've read.)
well that is another major differenciator and it was in fact a hard piece of
work to get it to the state it is now (which I too think is one of the
better parts) ... trying to get to some maintance support model that
doesn't let things try up)
cheers
frank (who doesn't like the legalese either but was forced to spend horrible
amount of time on it to find some commonly accepted ground (in legalese)
for Don's original idea of preserving stability while allowing evolvement
--- and for precisely this reason I will now stop contributing to that
discussion)
Jonathan Fine
> Hi,
>
> I'm trying out Google's project hosting service for
> a couple of LaTeX projects,
>
> http://aiaa-latex.googlecode.com
> http://nato-rto-latex.googlecode.com
>
> but apparently due to their campaign to reduce the
> proliferation of Open Source licenses, they only give
> you a choice of 8:
>
> Apache 2.0
> Artistic/GPLv2
> GNU GPLv2
> GNU GPLv3
> GNU LGPL
> MIT
> Mozilla Public 1.1
> New BSD
>
> Which one is most compatible with LPPL?
If I were in your situation, I think I'd use Apache 2.0.
For why, see http://www.python.org/psf/contrib/
--
Jonathan
Luis Rivera
> Hi,
>
> I'm trying out Google's project hosting service for
> a couple of LaTeX projects,
>
> http://aiaa-latex.googlecode.com
> http://nato-rto-latex.googlecode.com
>
> but apparently due to their campaign to reduce the
> proliferation of Open Source licenses, they only give
> you a choice of 8:
>
> Apache 2.0
> Artistic/GPLv2
> GNU GPLv2
> GNU GPLv3
> GNU LGPL
> MIT
> Mozilla Public 1.1
> New BSD
>
> Which one is most compatible with LPPL?
>
> Or when I make releases to CTAN, can I just choose to
> release those under LPPL?
>
A somewhat sketchy comparison may be found here:
http://en.wikipedia.org/wiki/Comparison_of_free_software_licences
In short, it seems to me that the GPL family of licenses (Artistic,
GPL, LGPL), may be incompatible with LPPL (if you release under *GPL,
you force other users to stick only to *GPL). I found Mozilla's too
labyrinthic, so Apache, BSD or MIT are your best bets. They all let
you use dual licenses, AFAIK; GPL doesn't.
Good luck.
Luis.
P.S. By the way, where is that restriction that you can only use these
licenses for your proyect? (a link is useful.)
Joost Kremers
> Apache, BSD or MIT are your best bets. They all let
> you use dual licenses, AFAIK; GPL doesn't.
it does.
<http://www.fsf.org/licensing/licenses/gpl-faq.html#ReleaseUnderGPLAndNF>
--
Joost Kremers joostk...@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)
Luis Rivera
> Luis Rivera wrote:
> > Apache, BSD or MIT are your best bets. They all let
> > you use dual licenses, AFAIK; GPL doesn't.
>
> it does.
>
> <http://www.fsf.org/licensing/licenses/gpl-faq.html#ReleaseUnderGPLAndNF>
>
I see...
So, that means that if I don't want to distribute a derivative work
under GPL I must use any of the other licenses. Right?
Thanks for your clarification.
Luis.
Will Robertson
>
> P.S. By the way, where is that restriction that you can only use these
> licenses for your proyect? (a link is useful.)
The new project page:
<http://code.google.com/hosting/createProject>
<http://groups.google.com/group/google-code-hosting> has some
discussion at various times about why they only offer 8 licenses
(search for "license proliferation").
Cheers,
Will
Joost Kremers
> So, that means that if I don't want to distribute a derivative work
> under GPL I must use any of the other licenses. Right?
i'm not sure what you mean. if you own the copyright to a certain work, you
may release it under any license you like. if you release it under the gpl,
you are nonetheless not bound by it: you, as the copyright holder, may also
release the same code, or a derivative work, under another license.
someone who does not own the copyright to your work, does not have that
right, of course.
Luis Rivera
> <http://groups.google.com/group/google-code-hosting> has some
> discussion at various times about why they only offer 8 licenses
> (search for "license proliferation").
>
Neat! Thank you!
However, from browsing through a couple of threads it seems that the
"dual license route" I mentioned above has been ruled out from google-
code, and it is very unlikely that they will support LPPL; so,
deprived from LPPL, the OP may consider MIT, BSD or Apache as viable.
Good luck,
Luis.
Luis Rivera
Jane Doe releases the package Foo under dual GPL and LPPL licenses. I
find the package useful and develop Bar with code borrowed from Foo;
if I don't like either GPL or LPPL, may I release my derivative work
Bar under the other license? It seems to me that, to fall in the safe
side, I must comply with both licenses; my question is whether I can
dodge one of them by embracing the other. Otherwise, I see no point in
releasing under dual license terms. (BTW, it seems that google-code
forbids this dual license scheme.)
This point is particularly relevant as the FSF explicitly states that
LPPL 1.2 is incompatible with GPL, and the OP is wondering what
license to choose. See
http://www.gnu.org/philosophy/license-list.html
I can see why avoiding license proliferation and dual licensing makes
sense...
Luis.
Will Robertson
> However, from browsing through a couple of threads it seems that the
> "dual license route" I mentioned above has been ruled out from google-
> code, and it is very unlikely that they will support LPPL; so,
> deprived from LPPL, the OP may consider MIT, BSD or Apache as viable.
Yes; furthermore, from <http://blogs.zdnet.com/Burnette/?p=192>:
"That is one of the reasons that Google chooses the Apache License
(2.0) as the default for the software it open-sources. It is
permissive like BSD, but (unlike BSD) actually happens to mention the
rights under copyright law and gives you a license under those rights.
In other words, it actually knows what it is doing unlike some of the
other permissive licenses."
So it seems that people in the know reckon that Apache is the one to
go with. BSD and MIT are only supported (by Google Code) due to their
sheer ubiquity.
Can you tell I was reading about this yesterday? :)
Will
Joost Kremers
> On Sep 24, 5:35 pm, Joost Kremers <joostkrem...@yahoo.com> wrote:
>>
>> i'm not sure what you mean.
>
> Jane Doe releases the package Foo under dual GPL and LPPL licenses. I
> find the package useful and develop Bar with code borrowed from Foo;
> if I don't like either GPL or LPPL, may I release my derivative work
> Bar under the other license? It seems to me that, to fall in the safe
> side, I must comply with both licenses; my question is whether I can
> dodge one of them by embracing the other.
ah, i see now what you mean.
well, there was a case like this a few weeks ago, when a linux kernel
developer took some dual-licensed BSD/GPL-code, stripped the BSD-license
and released his modifications under GPL only. IIRC the outcome of the
ensuing discussion was that it wasn't a nice thing to do, but in principle
not illegal.
this was code that had *both* licenses written in the files, with text
stating that you could use either one. legally, it would seem that you can
indeed strip out one license, but the spirit of F/OSS is such that you
should give the users of your modified code the same rights that you got,
which is in this case the right to use the code under either license.
things are of course different when a developer offers different downloads,
one with the source under GPL, one with the same source (or binaries
thereof) under a different license. then you just use the one with the
license you prefer. (i think that sort of option is generally used by
people releasing their code as F/OSS and under a commercial license at the
same time, not really by people that want to release their code under two
different F/OSS licenses.)
> Otherwise, I see no point in
> releasing under dual license terms.
i do think it can have its advantages. e.g. if you write code that you want
to integrate with two different projects, which have different,
incompatible licenses. in that case, releasing your code under both
licenses makes it available to both projects.
IIRC GPL'ed code has sometimes been dual-licensed as BSD to allow the F/OSS
BSDs to use it.
> I can see why avoiding license proliferation and dual licensing makes
> sense...
yeah...
Bil Kleb
>
> there isn't really something like "most compatible" with LPPL.
I noticed that the Mozilla Public License 1.1 has this clause
as the bottom of its boilerplate notice:
Alternatively, the contents of this file may be used under the terms
of the _____ license (the "[___] License"), in which case the
provisions of [______] License are applicable instead of those
above. If you wish to allow use of your version of this file only
under the terms of the [____] License and not to allow others to use
your version of this file under the MPL, indicate your decision by
deleting the provisions above and replace them with the notice and
other provisions required by the [___] License. If you do not delete
the provisions above, a recipient may use your version of this file
under either the MPL or the [___] License.
which would seem to indicate that I could fill the blanks with "LPPL",
have a dual license, and still live within the bounds laid down by the
Google Code folks?
Regards,
Will Robertson
>
> which would seem to indicate that I could fill the blanks with "LPPL",
> have a dual license, and still live within the bounds laid down by the
> Google Code folks?
No, Google Code will not allow dual-licensed projects. Stick with
Apache, I'd say, and if you want to make it more LPPL-like just add a
sentence saying something like "In the interest of document
compatibility it is advised that any modified versions of this package
should also bear another name."
I'm not a lawyer have only understood these things for about 24 hours,
now, (!) but I think that conveys the intent of the LPPL (vaguely)
without actually making it a binding clause in the copyright license.
(Does anyone else know about this? I don't actually know if this is a
good idea...)
Will
Bil Kleb
>
> No, Google Code will not allow dual-licensed projects.
But Google Code allows the Mozilla Public License
version 1.1, which allows dual licensing?
> Stick with Apache [...]
That's what I've done for now.
Regards,
--
Bil Kleb
http://tufte-latex.googlecode.com
Will Robertson
> Will Robertson wrote:
>
> > No, Google Code will not allow dual-licensed projects.
>
> But Google Code allows the Mozilla Public License
> version 1.1, which allows dual licensing?
You can dual license many combinations of open source licenses such as
GPL+BSD, MPL+whatever, whatever+whatever but it becomes messy when
derivative works are produced and then want to contribute back to the
original sources. Or so I believe. (See recent Linux/BSD conflicts on
problems with dual GPL/BSD licensed code.)
Google is doing what they can to clean up the mess of prolific open
source licenses, and disallowing dual licensing (or worse! multi-
licensing) is part of that.
Cheers,
Will
Scott Pakin
>>> (struggling to actually work out what the differences between all
>>> these licenses actually are!)
>> but frank's already explained all of the above (either in the text of
>> the licence, or in his earlier post).
>
> Oh, I mean in general. Like what the difference between releasing
> something under the BSD license as opposed to saying "Public Domain"
> in the source. And the difference between the MIT license and the BSD
> license. Or Apache vs. GPL. Or LGPL vs. GPL :) What a mess...and
> reading through legalese isn't my idea of pleasure.
My limited understanding is that "public domain" disavows all intellectual-
property rights. That is, I can take wills-array.sty, cross out "Will
Robertson" everywhere it appears, hack the code to bits, sell the code for
vast sums of money, and do whatever else I want with it. BSD requires me
to acknowledge you as the copyright holder, but I can otherwise do as I
please with the code. MIT seems pretty much the same as BSD. I'm not as
familiar with the Apache license but now that I look at it, I think it's
actually the license that most closely matches the OP's original question:
Which license is most compatible with the LPPL? Both Apache and LPPL
contain a clause that requires derived works to distinguish themselves from
the original. That is, I can hack up wills-array.sty and redistribute it
(even for money), but I'm required to state that you own the copyright and
that my version is not the same as your version. The GPL is a "sticky"
license (or, as Microsoft's FUD machine calls it, a "viral" license). That
means that I can hack up wills-array.sty and redistribute it (even for
money), but my version must acknowledge you as the copyright holder *and*
must also be released under the GPL, which implies that all of the source
code must be made available. The other licenses allow me to release binaries
(not applicable to a LaTeX style file, obviously) while keeping my
source-code modifications secret. The LGPL is a slight relaxation of the
GPL that allows unmodified LGPLed libraries to be used in non-LGPLed and
non-GPLed software.
-- Scott