License Framework: Develop Best Practices

[Janne Snabb]

On Mon, 14 Jun 2010, Chuck Swiger wrote:

> Where I live, someone without a legal degree cannot offer legal
> advice
[..]
> It might also not be a bad idea to not display anything about
> licensing until a human enables some Makefile switch which acknowledges
> the limitations of the system (ie, license description coverage is
> incomplete, etc, etc).

IMHO it might make sense to add some sort of disclaimer that the
license information is not to be considered as legal advice.
Otherwise people who redistribute the ports in some country with a
ridiculous legal system might become liable for something if they
are unlucky. I am not sure if this should be in the documentation,
or if it should be displayed every time when anything license related
appears on the screen.

Regarding the Makefile switch I would rather have it the opposite
way if it is seen necessary (IMHO not needed if there is a disclaimer
somewhere). If you want to disable it, you could define:

I_LIVE_IN_A_COUNTRY_WITH_A_RIDICULOUS_LEGAL_SYSTEM_WHICH_REQUIRES_DISCLAIMER_FOR_EVERY_SILLIEST_POSSIBLE_THING_TO_AVOID_LEGAL_LIABILITY_AND_THEREFORE_I_WANT_TO_DISABLE_THE_LICENSE_THING=yes


As a previous poster pointed out, I also think that the different
BSD licences should be separated. The 4-clause version puts heavy
burdens on someone who redistributes and does marketing. In case a
redistributor does any marketing, they need to figure out some
acknowledgement to be added in marketing materials for every piece
of 4-clause licensed software.

I also second the previous posters' opinion that in specifying GPL
related licenses, it is necessary to distinguish between "this
version only" and "or any later version". It makes a big difference
in license compatibility.

If these distinctions are not made, the whole framework is not very
useful. I would rather see it to be useful.


DISCLAIMER: I am writing this in a country where I can give legal
advice to anyone I want and also freely talk about anything else
and therefore the readers of this message may freely make any
interpretations they whish about the contents of this post. :)

--
Janne Snabb / EPIPE Communications
snabb at epipe.com - http://epipe.com/