Quoting Steve Litt (slitt@???):

> I use copyleft licenses when:
>
> 1) The work is a substantial coding effort
>
> And,
>

> 2) I see very little reason for someone to use parts of my code in
>    proprietary programs.

You know, I do the same thing.

> In theory I'd use lgpl in cases of #2, but lgpl, if I remember
> correctly, forces the person incorporating the code into either
> revealing his source code or submitting very reverse-engineerable
> object code (I don't remember which).

No, this entire 'forcing to reveal' thing is a blatant crock, just like
the 'forcing to open-source' allegation frequently leveled against GPLv2
over the years. There is no legal mechanism available to copyright
holders to compel revelation of source code by creator of a derivative
work, just as there is no legal mechanism to compel open-sourcing of
derivatives. Neither of those is available in civil tort litigation as
a remedy for (proven-in-court) copyright violation. The courts offer
these remedies:

1. Injunction against further violation (an equity remedy)
2. Monetary damages (a remedy 'at law', i.e., one of recompense).

With any copyright licensing, proprietary or open source, the courts
apply the same standard of review and offer the same remedy if the
defendent is found to have violated copyright: Was defendent's actions
a violation of the copyright owner's reserved rights (or in the
alternative did defendent have lawful access to those rights under
licence)? Did defendent's actions touch plaintiff's rights, e.g., by
creating/distributing a derivative work as that term is defined in
copyright law? Did plaintiff have standing to bring suit? If rights
were at stake and infringed, which remedies are merited and how much
money?

Nowhere in that process is 'force the other guy to reveal source code'
or 'force the other guy to open-source a derivative work'. Because
those simply _aren't_ part of the copyright legal process.

No, I'm not a lawyer, and even if I were would not be _your_ lawyer
unless certified to the bar in your jurisdiction and working for you.
But I am the former licensing guy at VA Linux Systems, Inc. and one of
the regulars on the OSI license-discuss and license-review mailing lists
for some decades, now.


> For little projects I just use the Expat license, which practically the
> same as one of the BSD licenses and one of the MIT licenses, except
> there's only one Expat license so there's no ambiguity.

You could avoid your hapless self-trapping into obscurity by specifying
'MIT License as published at https://opensource.org/licenses/MIT' --
and you could _also_ explicitly waive the hidden obligation you're
accidentally imposing on third parties to add in the 'Expat License'
text you omit from your works. I've told you this before.

Show of hands: Is there anyone here except me or Steve who has ever
heard the phrase 'Expat License' uttered by anyone but Steve Litt?
(Anyone, anyone? Bueller?) Steve, there's your main problem. You
bought a line from FSF perspective-challenged dumbasses that the
expression 'MIT License' is 'too ambiguous' and that therefore licensors
should use a term nobody knows, instead.

Don't you know better than to take FSF advice without due wariness for
dumbassery?


> For copyleft stuff I usually use GPLv2 because I understand it, but for
> my recent UMENU2 I used GPLv3 because it addresses software patents. I
> *NEVER* include the words "or later", because I have no idea what kind
> of animals might take over the FSF in later times.

Yes, you do.

FSF is legally constrained _very_ tightly by tax and corporate law to
follow its declared charitable purpose. It literally has no legal power
to be anything but a free-software outfit.

Morever, ignoring that, if Cthulhu arises from R'lyeh, moves to
Cambridge, takes over FSF, and somehow defeats the entire body of
corporate regulatory law to make FSF a House of the Old Gods devoted to
proprietary software or whatever, what do you imagine GPL v. 3.1
could declare that prevents utterly obvious workarounds? Consider
cases:

1.  Evil Future FSF makes GPLv3.1 specify tightly proprietary terms.
    Remedy for copyright owners of GPLv2+ codebases:  Ignore 
    this option.

2.  Evil Future FSF makes GPLv3.1 specify permissive terms.  Remedy for
    copyright owners of GPLv2+ codebases:  Accept that a one-time
    permissive fork can now occur, change the main branch's code
    to GPLv2, and soldier on.  But an option for a permissive fork
    isn't actual horrible, I'd say.

3.  Evil Future FSF makes GPLv3.1 require a giveaway of licensor's patent,
    trademark, or other rights.  Remedy for copyright owners of 
    GPLv2+ codebases:  Same as case 1.

Basically, hypothetical Evil Future FSF has no power to actually
hurt you. If you can think of a way, I'm (as my barber says) all ears.

> I never use licenses with mentions of indemnification.

Um, have you considered that the phrase 'In no event shall the authors
or copyright holders be liable' in Expat License _is_ a mention of
indemnification?