Re: GeForce nvidia driver license for commerical use?

[Simon McVittie]

On Mon, 03 Oct 2022 at 21:12:50 +0200, Roberto A. Foglietta wrote:
> Are you referring to the special permission given by e-mail by Donald Randall
> in 2003?

I think you're misreading the copyright file. Randall Donald is a Debian
contributor who asked Nvidia for permission to redistribute their driver,
and got a reply (which is quoted in the copyright file) from someone
named Andy.

smcv

Re: GeForce nvidia driver license for commerical use?

[Simon McVittie]

On Mon, 03 Oct 2022 at 19:52:23 +0200, Roberto A. Foglietta wrote:
>  reading this link here below, it seems that compilation and repackaging the
> content is prohibited by their license. What's your opinion on this?

Please note that the Debian maintainers of nvidia-graphics-drivers have
received special permission from Nvidia beyond what is allowed by the
license in the .run archive. Please see
https://tracker.debian.org/media/packages/n/nvidia-graphics-drivers/copyright-510.85.02-2
(or equivalent for other versions) for details.

If you plan to repackage this driver outside Debian or distribute it
commercially, you will need to talk to Nvidia directly, or obtain your
own legal advice.

smcv

Re: Binary file inside fruit package

[Simon McVittie]

On Mon, 27 Jun 2022 at 13:23:41 +0100, Sebastian Crane wrote:
> What would you say the preferred form of modification should be for
> chess opening books?

I think talking about "the" preferred form for modification is often an
oversimplification when discussing content that is not executable code,
and thinking about it in terms of "a" preferred form for modification
sometimes leads to more reasonable results.

smcv

Re: GPL-2-only packages using GPL-3+ readline

[Simon McVittie]

On Sat, 02 Jan 2021 at 00:48:43 +0100, Bastian Germann wrote:
> There are some packages with GPL-2-only licensed binaries that link with
> GPL-3+ licensed libreadline.so.8. I do not know Debian-legal's current
> interpretation on that matter.

debian-legal is purely advisory, does not control what is in Debian, and
does not necessarily contain any actual lawyers. The archive administrators
 are the group that controls what is and isn't
accepted into Debian.

smcv
(not a lawyer either)

Re: Maxmind GeoIP/Geolite license change

[Simon McVittie]

On Sat, 04 Jan 2020 at 03:08:29 +0100, Patrick Matthäi wrote:
> Am 04.01.2020 um 01:53 schrieb Faidon Liambotis:
> > the libraries are free-libre, the file format
> > is open and freely documented (CC-BY-SA 3.0), and there are both readers
> > and writers for those formats in the archive. There are even
> > free-as-in-beer databases available in the wild, although that wouldn't
> > even be a requirement IMO. There is nothing in the DFSG that says that
> > software is free-libre only if it operates on publicly available
> > free-libre data.
> 
> We have got many similar examples in another category: games
> Old games like Quake, Red Alert, Roaler Coaster Tycoon etc etc, the game
> code now itself is free: sometimes reverse engin., new code or open
> sourced by the publisher itself. But often the required game data
> (images, videos, etc) are not distributable and required from the
> original cd-rom.
> 
> So the game code itself is free, but we have to put it in contrib,
> because it is only useable with non-free data.

That's only the case for game engines that are particularly tightly
coupled to a particular game or games, like yquake2 for Quake II and
openjk for Jedi Knight II and Jedi Academy.

Many game engines are in main, not in contrib, because Free data in a
compatible format exists or would be feasible to provide. We don't require
that the game data is conveniently packaged in Debian, or even that it's
sufficiently complete to be a worthwhile game in its own right, only that
it's possible (and even that rule might be more conservative than it needs
to be). For example, quakespasm is mostly a Quake 1 engine, and we don't
have any Quake-1-compatible data in the archive; but it's in main anyway,
because it can also be used to play Quake-like games such as OpenQuartz
(analogous to OpenArena, but a lot less complete, and for Quake 1).

Similarly, darkplaces (another Quake 1 engine) and ioquake3 (a
Quake III Arena engine) would be OK for main even if nexuiz and
openarena were removed from Debian.

The .desktop file, etc. for Quake 1 *are* in contrib, because they're
for Quake 1 specifically, not just "a Quake-like game".

Packages in main also include viewers and editors for specific file
formats like aylet and cpmtools (without requiring examples of those
file formats to exist in Debian main), clients for specific websites
and web-APIs like lgogdownloader, youtube-dl and git-hub (the websites
are obviously outside the scope of Debian), emulators for specific
computers like aranym and cen64 (without requiring those computers'
operating systems to exist in Debian), and email clients that are used
to read non-Free emails like this one.

If in doubt about the boundaries of main vs. contrib, talk to the ftp
team, which is the team that makes the actual decisions about where the
line is drawn. If I remember correctly, the games team consulted the
ftp team before we uploaded quakespasm, to confirm that it would be
considered acceptable for main.

smcv

Re: anti-tarball clause and GPL

[Simon McVittie]

On Wed, 24 Jul 2019 at 02:34:13 +0200, Adam Borowski wrote:
> > > ##
> > > I do not consider a flat tarball to be a preferred form for modification. 
> > > Thus, like any non-source form, it must be accompanied by a way to obtain
> > > the actual form for modification.  There are many such ways -- unless you
> > > distribute the software in highly unusual circumstances, a link to a
> > > network server suffices; see the text of the GPL for further details.
> > > ##

Are you asking this hypothetically, or is there a piece of software that
someone intends to apply this to?

As always for legal questions on whether something is allowed in Debian,
asking -legal will only get you some speculation: the ftp team is the
authority on what can and can't be in Debian. However, I think this would
be an unwise precedent to set, with undesirable practical implications,
and I suspect the ftp team would think the same.

Remember that GPL-2 §3c is only allowed for non-commercial redistribution,
so commercial redistributors have to use §3a or §3b. This means they have
to take steps to redistribute the preferred form for modification themselves
(e.g. copy it to *their* network server).

In the GPL-3 case, a commercial redistributor could rely on §6d (GPL-3
§6 is the equivalent of GPL-2 §3), but it's unwise to rely on a third
party for this without some sort of contractual relationship, because
"you remain obligated to ensure that it is available for as long as
needed to satisfy these requirements" (so linking to upstream's network
server is not enough, because if upstream stop distributing source,
you would be in violation of the license unless you immediately stop
distributing binaries). Debian and its derivatives are longer-lived
than many of the packages we include, so we need to know that we are
already distributing source for all our binaries.

Redistributing the entire history of a third-party project is practically
problematic because it is no longer enough to check that there is nothing
you don't want to distribute (e.g. non-free software) in the HEAD commit:
you also have to check that there is nothing that you don't want to
distribute anywhere in the history. If I remember correctly, this is
why the ftp team do not allow "3.0 (git)"-format source packages in the
Debian archive: if a git-based source package format is allowed in future,
it will have to be "shallow", which makes it functionally equivalent to
a tarball plus metadata.

For established projects, the complete history is also inconveniently
large: my git clone of glib2.0 has a 57M .git, which compares poorly
with a 4.5M source tarball (and glib2.0 isn't even particularly big or
old by the standards of projects like glibc and the Linux kernel).

> By this logic, a pile of .c files with comments removed or preprocessed
> with cpp would be allowed as well.  The VCS is also a means to store
> human-readable comments.

We have to draw a line somewhere. You could equally well say the software's
bug tracking system and mailing lists, which also store human-readable
comments, are part of the preferred form for modification - but those
don't normally have any copyright license granted (I certainly didn't
put this email under a copyright license!) so they are non-free.

> Another piece of [meta]data that a flat tarball lacks is authorship
> information.

Projects that consider this to be important put copyright notices in
source files, lists of authors in source files and/or lists of authors
in ./AUTHORS.

smcv

Re: Missing source in firefox-esr: EME module

[Simon McVittie]

On Tue, 02 Jul 2019 at 15:20:37 -0400, Nat Tuck wrote:
> It'd probably be necessary to go through the packages in main and see
> if any other packages download and install proprietary software at all,
> or if this is just Firefox even in the more general case.

I want to head this off right now, because continuing this train of
thought could lead to us removing all the email clients from Debian
(because they are willing to download this email[1], which I have not
placed under a Free license), and if that's the standard we are aiming
for then we might as well give up on producing a practically useful
Free Software distribution.

A program that *can* download and install proprietary software, but does
not depend on doing so, is definitely allowed in main: general-purpose
HTTP clients like Firefox and wget download whatever you tell them to,
proprietary or otherwise, and so will software package managers like
apt, Docker and pip. Even within the scope of installing executable
code through an interface specifically designed for executable code, the
extensions available from addons.mozilla.org and third-party sources are a
mixture of Free and non-Free, just like the dpkg packages available from
deb.debian.org and third-party apt sources, the Docker images available
from Dockerhub and third-party Docker registries, and the Python packages
available from PyPI and third-party pip-compatible repositories. Some
distribution points have a strict policy of Free Software only (Debian
main is one such distribution point, and I think PyPI aims for this?),
but any downloader that can't cope with multiple compatible distribution
points (federation) has an obvious missing feature, and any downloader
that *can* cope with multiple compatible distribution points can be
pointed to a distribution point that offers non-Free software.

Now, I do agree that Firefox's Widevine module is not the same as (for
example) the addons on addons.mozilla.org, because there is code in
Firefox to download and run this specific module (Widevine specifically,
not just the generic concept of an EME module), and the UI for that
feature does not make it immediately obvious that an additional module
will be downloaded and run when it is enabled. I think you might be
harming your chances of achieving your goal here by trying to make this
into a debate about DFSG-compliance (which I suspect is not one you are
likely to win), and by expanding its scope from Widevine to software
downloaders more generally.

If you approach this from the angle of "I had a reasonable expectation
of what this checkbox would do, but what it actually does is something
different, and I think this situation could be improved", then that
seems more likely to lead to changes, assuming you haven't already
antagonised the people you would have needed to persuade. It might not
lead to precisely the changes you hoped for, but sometimes compromise
is necessary.

More on the DFSG angle, because this *is* -legal:

Packages in main are not allowed to *depend on* proprietary software,
which we have generally interpreted as: imagine the proprietary software
was distributed via apt/dpkg (if it isn't already). If the strength of the
depending package's dependency on it is such that a Depends or Recommends
with no alternative would be appropriate, that isn't OK for main; but if
a Suggests or no explicit dependency at all would be more appropriate,
or if an appropriate dependency could have been an alternative-group like
"Depends: free-thing | non-free-thing"[2], then that's allowed.

So, imagine the proprietary Widevine module was included in the non-free
archive area or some third-party apt repository, so that firefox.deb
could have a Depends, Recommends or Suggests on it, rather than being
available via a non-apt mechanism. How strong would the correct dependency
be? I think the answer is probably Suggests: Policy says that means that
"the listed packages are related to this one and can perhaps enhance
its usefulness, but that installing this one without them is perfectly
reasonable", which seems about right. Installing Widevine enables an
additional feature (playing DRM-encumbered videos), but Firefox continues
to be useful for many other purposes without it.

Firefox frequently also downloads proprietary web pages, and proprietary
Javascript programs, but if anything the dependency relationship there is
the other way around: the web page and its associated Javascript programs
depend on a web browser. If (for example) Youtube was somehow packaged in
Debian[3], we'd be more likely to say
youtube Depends: firefox | chromium | www-browser than we would be
to say firefox Depends: youtube.

smcv

[1] If you believe "software" means executable code and excludes
non-executable data like the text of this email, please imagine that
I had included a shell script under a "non-commercial use only" license
in order to make my point
[2] Debian Policy §2.2.1, as resolved in #681419 and 

Re: Hacking License

[Simon McVittie]

Please take a step back from the specifics of this license and think
about its wider goals, and whether writing a new license helps to achieve
them. I suspect it actually doesn't.

Presumably you're aiming for something similar to the copyleft effect
of the GPL and AGPL: you want people to improve your software, and you
want them to share their modifications with everyone else. However,
every time someone considers whether to redistribute your software or
whether to invest their time in understanding and modifying it, they
need to decide whether the license terms are acceptable to them. When
faced with a non-standard license with unclear terms and no community
consensus on its consequences, it's quite a rational response to think "I
don't have time to think about this" and decide to contribute to something
else instead. The same contributor, considering whether to redistribute
or improve GPL or LGPL software, will likely think "this is the GPL,
I already know about this from Linux" or "this is the LGPL, I already
know about this from glibc" and not need to think about it. That's true
whether your license terms actually do what you want them to or not - the
cognitive load of deciding whether a license is acceptable is a cost in
its own right.

One risk of contributing to or relying on a project with an unclear
license is that the license is too restrictive (e.g. a very strong
copyleft) and prevents you from doing something you wanted to. The
opposite risk is also present: if some or all of the license turns out
to be too unclear to be enforceable in court, then contributors have
no recourse if someone takes the project and modifies it in ways that
(the unenforceable part of) the license was intended to prevent. We
know (because it's happened) that the GPL can be enforced in court;
we can be reasonably sure that other standard licenses written with the
help of lawyers can also be enforced; but we don't know that about your
new license.

The more influential and useful a piece of software is, the more willing
people are (either as individuals or as representatives of a company)
to put up with a pre-existing weird license, but it isn't 1995 any more:
there are a lot of open source software projects out there, and the more
potential contributors a new software project puts off with a non-standard
license, the less likely it is to get that influential.

It's also worth considering what would happen if someone violates your
license. Assume a large evil company relies on your software in a SaaS
situation without sharing their modifications with their users. The
AGPL-style restriction in the license can only help you if: their users
somehow find out that this has happened, and what the applicable license
is; their users tell a copyright holder; and the copyright holder has the
resources to successfully sue a large evil company. This seems like a
relatively tenuous benefit, compared with the cost of license proliferation.

On Wed, 12 Dec 2018 at 00:55:47 +0100, Giacomo Tesio wrote:
> If a company violates the Hacking License, the upstream copyright
> holders could, since they have received "all permissions and patent
> licenses granted to the Users of the Hack, and all rights, title and
> interests in any Copyright the Hackers have in the Hack to the extent
> permitted by Law."

I don't think this works. Who holds copyright is a matter of law,
not licensing, and my understanding is that in many (most? all?)
jurisdictions, you can't reassign copyrights from one legal entity to
another (whether those legal entities are people or companies) without a
signed contract. If your license claims to make this happen implicitly,
and an upstream relies on it having done so, in a jurisdiction where
this is not actually possible, then the upstream and the company are now
violating each other's copyright, and each could plausibly win damages
from the other (possibly after an expensive legal fight, which in many
jurisdictions means the larger entity will probably win, because it can
stall until the smaller entity runs out of money).

Any time you think "my license forces someone to do what I want",
you should be aware that that's only shorthand for "my license forces
someone to choose between doing what I want, or violating my copyright
and facing the consequences of that, or not interacting with my software
in ways that are restricted by copyright". If they have no legal authority
to do what you want - perhaps because they signed a contract reassigning
copyright in what they write to their employer - then their only options
are to violate your copyright (which has no practical consequences unless
you find out and can successfully sue), or avoid your software (oops,
now you've lost another contributor).

I am not a lawyer in any jurisdiction, but as far as I know, neither
are you. I would recommend that you save your innovation for software,
and leave the innovation in licensing to lawyers (or at least involve
qualified lawyers in 

Re: Font-Awesome 5 no build system DFSG compatibility

[Simon McVittie]

On Thu, 19 Jul 2018 at 00:38:15 +0200, Alexis Murzeau wrote:
> Since version 5, font-awesome upstream repository contains both source
> files and generated files but not the build system [1].

I think this is a technical issue, but not a DFSG violation; and I think
it would be appropriate to track it as a bug, but not a release-critical
bug.

The same situation exists in any package where some hard-to-modify,
non-executable data file (perhaps an icon) is accompanied by its
easier-to-modify source form (perhaps in GIMP format or as a SVG) but
a manual export step is required to transform the source form into the
modifiable form.

We generally hold executable code (must be compiled at build time,
with some rare exceptions) to a higher standard than "pure data" (not
necessarily recompiled at build time), because in practice it is far
more likely that we will find ourselves in a position where we need to
exercise our right to modify for executable code, to be able to fix bugs
in that code; and because in most cases fixing bugs in executable code
by direct modifications to a generated format is much les practical than
doing the same with many non-executable data formats (for instance if
you need to, you can perform many edits to an icon in its bitmap form
without going back to its source form).

> So it is not possible to regenerate generated files from source files
> without guessing which file are generated and which are sources.

We do not require that packages are modifiable by people who do not
know how to modify that particular language or format. People with the
necessary knowledge presumably know which file is in a preferred form
for modification and which file is generated from it; if they didn't,
then that would preusmably have to be because the generated file was a
reasonable form for modification in its own right.

> Considering DFSG #2:
> > The program must include source code, and must allow distribution in
> > source code as well as compiled form.

The "program" (package, module) includes source code: [x]

The license allows distribution of that source code: [x]

So yes I think this is fine for the DFSG.

smcv

Re: Unclear license information regarding copyleft

[Simon McVittie]

On Tue, 15 May 2018 at 19:22:54 +0200, Sven Bartscher wrote:
> I'm the maintainer of the package dwarf-fortress in non-free. The
> package as a whole is clearly non-free as the license states that „you
> may redistribute the *unmodified* binary and accompanying files“ and the
> source code to the contained executable is not provided.
> 
> The package also contains a shared library called libgraphics.so and the
> corresponding source code. The library links to (among others) SDL and
> GTK which are licensed under the LGPL-2.1, AIUI this means that
> libgraphics.so and its source code have to licensed under the LGPL. (due
> to condition 2, correct?)

No. glibc is LGPL-licensed, the same as GTK[1], so if your interpretation
was correct, the dwarf-fortress developer would not be allowed to
distribute their proprietary executable that is linked to glibc.

The main difference between each version of the GPL and the corresponding
version of the LGPL is that you can link (possibly proprietary) objects
to a LGPL library without being obliged to release source for those
objects under the (L)GPL.

If the dwarf-fortress developer is the copyright holder of everything in
libgraphics, then the choice of license is up to them, as long as they
meet the conditions in LGPL-2.1 §6. They are under no obligation to
provide source code for it (under LGPL or otherwise), because LGPL-2.1
§5 and §6 apply to it.

> As there are some problems[1] with the compiled shared library as
> distributed by upstream (and because compiling things ourselves is
> always nicer) I would like to rebuild the library when building the
> Debian package, though I'm not sure if it is clear in the given
> situation that it is legal to recompile the library and distribute the
> resulting shared library.

The dwarf-fortress developer doesn't seem to have given you permission
to compile g_src into a replacement libgraphics.so and distribute the
result, so you can't; but it seems to be their intention that you can
(otherwise they wouldn't have released source code), so if you ask nicely,
it seems likely that they will give you that permission.

smcv

[1] I don't know whether it's the same version of the LGPL, but the
differences between versions are not particularly relevant here

Re: License of the GPL license

[Simon McVittie]

On Mon, 16 Apr 2018 at 10:50:04 +0200, Giovanni Mascellani wrote:
> this question might be trivial, but I just realized that the GPL license
> is itself licensed under a license that technically does not appear to
> be DFSG compliant:

We make an exception for the licenses of licenses, because otherwise we
basically wouldn't be able to distribute any software at all (and it
isn't completely clear whether legal texts are copyrightable anyway).

smcv

Re: How to determine the license of D-Bus interface spec files (XML)?

[Simon McVittie]

The usual term of art for the D-Bus interface descriptions you're talking
about here is "introspection XML".

On Mon, 19 Mar 2018 at 16:09:02 +0800, Boyuan Yang wrote:
> * Vala source code files are generated from D-Bus interface spec files
> (XML format) using "vala-dbus-binding-tool" (exist in Debian Archive)
> * Some of XML spec files are generated using "dbus-send" tool (exist
> in Debian Archive)

dbus-send doesn't "generate" anything. It sends a message and prints
the reponse. Saying that dbus-send generates introspection XML is like
saying that wget generates the content of a web page.

Depending on the service you're using as the destination in your
dbus-send request, the introspection XML might either have been copied
from the source code into the service binary as a large string literal, or
constructed on-demand from data structures like GLib's GDBusInterfaceInfo.
I've seen both approaches used.

> * Other XML files are copied from Freedesktop.org website [4] and gnome-shell
> source code

> Now, here is the problem: contents in fd.o website has no licensing
> information. I asked (daniels) at irc #freedesktop and the person said
> that the status quo is "undefined" and it is not likely to change in
> near future.

If a particular freedesktop.org specification (in your case the File
Manager interface) doesn't have copyright/licensing information at its
upstream source, the only people who can give you that information are
the authors of that specification. The fact that a specification is
hosted on freedesktop.org isn't really any more significant here than
the fact that something else is hosted on Github.

> However, I'm not sure about the license of D-Bus interface itself as
> well as the XML file that describes such interface.

There is no single required license for D-Bus introspection XML, in the
same way that there is no single required license for C source code.

The org.freedesktop.DBus interface is defined by the D-Bus Specification
and its reference implementation "dbus", which are both available
under a dual-license: GPL-2.0 or any later version, or AFL-2.1 (see
/usr/share/doc/dbus/copyright); so the most restrictive terms that could
possibly be applied are that dual license.

The freedesktop.org File Manager interface is presumably defined by some
freedesktop.org specification: you know as much about this one as I do.

The org.gnome.Shell Screencast interface is presumably defined by GNOME
Shell and released under the same licensing terms as the rest of Shell.

> Anyway, it is an interface, not any concrete implementation.

I am not a lawyer, but I suspect that a bare interface description without
documentation, like
 and
,
might be considered to be sufficiently un-creative that it is not
protected by copyright: it's a purely functional description of what
is necessary to interoperate with a fd.o file manager.

An interface description that contains comments/documentation should
probably be treated like source code, though. Ideally the upstream
developers of GNOME Shell would put copyright/licensing information in
their introspection XML just like they should for any other source code.

> P.S. I'm asking this question looking for an answer to make sure that
> this package won't get rejected during the NEW process by ftp-masters
> due to licensing problems.

Only the ftp team can tell you whether they would accept or reject a
package and why. The debian-legal mailing list has no authority over
the ftp team.

smcv

Re: Is there a list contains all debian packages and it's license ?

[Simon McVittie]

On Sat, 23 Sep 2017 at 10:25:33 +0200, to...@tuxteam.de wrote:
> Not a readymade solution, but perhaps a lead to follow: package copyright
> info is supposed to be in a file debian/copyright within the package source
> archive[1]. I don't know at the moment whether this info percolates to
> the package binary when building.

It does, and Debian Policy says it must. That information ends up in
/usr/share/doc/${binary_package}/copyright where ${binary_package} is the
binary package. For instance, the dbus source package produces binary
packages that include dbus, dbus-x11 and libdbus-1-3, so its
debian/copyright gets copied to /usr/share/doc/dbus/copyright,
/usr/share/doc/dbus-x11/copyright and /usr/share/doc/libdbus-1-3/copyright,
among others.

In rare cases the binary package copyright file is not identical to the
source copyright: if a package foo has a GPL part packaged as foo-utils
and a LGPL part packaged as libfoo0, it would be valid to list both GPL
and LGPL in debian/copyright, only GPL in /u/s/d/foo-utils/copyright
and only LGPL in /u/s/d/libfoo0/copyright. However, in practice
maintainers don't make use of this, because it creates extra work for
little or no benefit, and carries a risk of accidentally providing
incomplete or untrue copyright/licensing information.

S

Re: Unsure about a License with mandatory attribution clause

[Simon McVittie]

On Sat, 17 Jun 2017 at 12:52:06 +0200, Andreas Moog wrote:
>  The end-user documentation included with the redistribution, if 
>  any, must include the following acknowledgment: "This product 
>  includes software developed for the Unity Project, by Mike Karlesky,
>  Mark VanderVoord, and Greg Williams and other contributors", in 
>  the same place and form as other third-party acknowledgments. 

In Debian, third-party acknowledgements of this form appear in
/usr/share/doc/*/copyright, which is part of the end-user documentation
in /usr/share/doc. So I think this is fine: documenting the license
in /usr/share/doc/*/copyright, which you are already required to do, is
enough to comply with this clause.

(I'm sure we have a lot of software with similar license clauses.)

S

Re: Licensing Issues for Proprietary Game Assets

[Simon McVittie]

On Thu, 02 Mar 2017 at 09:41:30 +0200, Kyle Robbertze wrote:
> Is it possible to package this for Debian with the asset license as is?

Probably not. This sounds like a job for game-data-packager to me:
it downloads and repackages proprietary game assets, or reads them
from a non-distributable GOG or Steam package or a CD-ROM or whatever,
and produces and installs a .deb that is not redistributable. Have a
look at iortcw to see how that typically works (data/rtcw.yaml in
game-data-packager is the corresponding description of the proprietary
assets).

game-data-packager was originally for game assets that are sold commercially
and are not legally distributable at all, but freely downloadable assets with
an unclear or otherwise unacceptable license are also in-scope.
If the proprietary assets are downloadable in an automated way using standard
tools (game-data-packager uses Python's built-in HTTP support), then
game-data-packager will be able to create empty-epsilon-data entirely
automatically, like it does for several games in the Zork series.

If the engine that will interpret those assets is Free Software, it can
go in contrib[1]; if not, but it is distributable separately from the assets,
it can go in non-free.

If you go this route, please do your packaging with the assumption that
data files will go in /usr/share/games/empty-epsilon or similar, install
them there manually for now, and open a 'wishlist' game-data-packager bug
with details of the files that need to be packaged. Patches welcome (the
YAML format should be reasonably self-explanatory), or we can use the
output of "game-data-packager make-template /usr/share/games/empty-epsilon"
as a starting point for the necessary information.

You can also use the game-data-packager launcher (game-data-packager-runtime)
if you want to avoid having to have your own handling for missing data files
like iortcw does. It's a simple Python + GTK wrapper around the real
executable, which checks that the required files and engine are present,
and execs the real executable if everything looks OK. Examples of its use
so far include Quake I, II and III (Free engines, proprietary data), and
Quake IV and Unreal (proprietary but freely downloadable Linux binaries,
proprietary data).

S

[1] I'm assuming there isn't an alternative set of Free assets that would
allow it to be in main, like OpenArena for the Quake III Arena engine?

Re: unknown license for package/debian/* in d/copyright in adopted package

[Simon McVittie]

On Wed, 04 Jan 2017 at 02:16:10 +, Ian Jackson wrote:
> This benefit IMO far outweighs the risk that at some point someone
> will abuse our goodwill to make Debian-format source packages out of
> proprietary software.  No-one, not even evil people, would want to do
> that.

As a consultant mostly working on Debian derivatives, I wouldn't agree
with that. Various non-evil[1] people make Debian-format source packages
whose upstream part is partially or entirely proprietary software, with
either Free packaging (common in Debian non-free), proprietary packaging
(which I seem to remember seeing in at least Maemo), or packaging with
no explicit license at all (which I've seen in at least Raspbian).

Putting a copyleft license on your favourite package's packaging is
not going to prevent that: Debian packaging is not difficult to
write from scratch, and even if it wasn't, there are plenty of
permissively-licensed packages available to base a proprietary
package on.

This also assumes that the parts of the packaging that might be copied
are even sufficiently creative to be eligible for copyright, which might
be doubtful in simple cases (in particular, maximally-declarative
packaging with dh).

I think a much more serious risk is that an insufficiently permissive
license results in inadvertent copyright infringement, avoidable duplicated
work, or avoidable bugs, in Free Software whose author is trying to do
the right thing.

When a licensed work represents an investment of time/effort/money that
is difficult or expensive to redo - most visibly, the Linux kernel -
copyleft is a valuable tool to encourage the production of more Free
Software. However, when an independent reimplementation of the work
only has a cost comparable to the time spent worrying about licensing
questions, copyleft is at best neutral, often an annoyance, and at worst
an active barrier to re-use.

I wonder how many debian/ directories the participants in this thread
could have written between us, under licenses of our choice, in the time
it took to discuss this?

S

[1] assuming for the sake of avoiding tautology that you do not consider
proprietary software to be inherently evil

Re: Ask about the license "permissive"

[Simon McVittie]

On Sat, 31 Dec 2016 at 01:33:04 +0300, Dmitry Alexandrov wrote:
[I wrote]
> > Permissive licenses typically need to be quoted in full in the Debian
> > copyright file.
> 
> Any licence regardless of its conditions (permissive, copyleft or even 
> nonfree), except the following ones, should be quoted in full, is not it?
> 
> ,[ $ ls /usr/share/common-licenses/ ]
> | Apache-2.0  BSD   GFDL-1.2  GPLGPL-2  LGPLLGPL-2.1
> | ArtisticGFDL  GFDL-1.3  GPL-1  GPL-3  LGPL-2  LGPL-3
> `

Correct. The original BSD license is one example of a permissive license.

S

Re: Ask about the license "permissive"

[Simon McVittie]

On Fri, 30 Dec 2016 at 20:50:10 +0300, Dmitry Alexandrov wrote:
> > There is "permissive" used as name. Is this the correct name of the
> > license?
> 
> It look like a simplified variation on so called ‘Historical
> Permission Notice and Disclamer’ [0][1].  It is indeed a lax permissive
> licence, so I see no problem.

To be clear, there is probably no canonical name for this license. It
is one of many permissive licenses, rather than being "the Permissive
License".

Permissive licenses typically need to be quoted in full in the Debian
copyright file.

If you are using machine-readable copyright file syntax, the names used
for permissive licenses are essentially arbitrary, as long as they do not
collide with a predefined license name. If only one permissive license
is used, it's often listed as "License: permissive". If multiple
permissive licenses are used or there is some other reason to disambiguate,
I usually use something like "License: alexandrov-permissive" or
"License: foobar-permissive", with the name of the author, copyright
holder or module added.

S

Re: Is an AGPL2 possible?

[Simon McVittie]

On 18/01/16 23:40, Jonathon Love wrote:
> the AGPL3 is the GPL3 with an additional clause. is there some reason
> why an AGPL2 wouldn't be possible?

It exists, and is called the Affero GPL version 1
; but it probably doesn't do what you
want, because it isn't GPLv2-compatible. I would recommend not licensing
anything under it.

The "Affero clause" (AGPLv1 clause 2d, AGPLv3 clause 13) adds an
additional restriction beyond those of the GPLv2, and the GPLv2 says you
can't combine GPLv2 software with other software in a way that would add
additional restrictions (beyond those of the GPLv2) to the combined work.

The AGPLv3 is only GPLv3-compatible because the GPLv3 clause 13
specifically says so, as a special exception to GPLv3 clause 7.

(I don't particularly like the AGPLv3 either, because it makes it much
less obvious whether you're in compliance than the GPLv2/v3 do, and
either restricts use or comes very close; but it is at least
GPLv3-compatible.)

S

Re: Consensus about the Academic Free License (AFL) v3.0

[Simon McVittie]

On 13/06/15 15:45, Francesco Poli wrote:
 As also noted by Walter Landry, there's a crucial difference w.r.t.
 Apache v2: the latter license requires to preserve attribution notices
 within NOTICE files; the AFL v3.0 requires instead to preserve *any*
 descriptive text identified as an Attribution Notice (even when this
 text includes something other than attribution notices!).
 
 I think this is non-free, unless all descriptive texts identified as
 Attribution Notices only contain attribution notices.

The ftpmasters do not decide whether Debian will accept particular
licenses; they decide whether Debian will accept particular software.
One possible outcome for this part would be the ftpmasters deciding that
AFL-3.0 software is only Free if it does not have any Attribution
Notices that are not, in fact, attribution notices.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/557ca492.5060...@debian.org

Re: GPL + question

[Simon McVittie]

On 29/05/15 16:30, Ole Streicher wrote:
 Miriam Ruiz mir...@debian.org writes:
 So in my opinion, if you modify a code which was released under GPL2+
 and you license your modifications as GPL3+, the resulting work has to
 also be GPL, and the terms or conditions that apply are those of the
 version 3 of the lincense, or later, but you're not effectively
 relicensing the code that is not yours, so that part would be still
 licensed as GPL2+ by the author and copyright holder.
 
 I may give to others the permission to use the modified/redistributed
 file under GPL-3+. This permission is what is usually called License.
 
 In that sense, the license is changed.

I think you're mixing up the license of a work, and the effective
license of a combined work.

A work is an abstract legal thing, dating back to when the most advanced
computer available was a monk with an abacus.

A file is a computing concept. The law says nothing about files. If
various people have contributed bits of a file, my understanding is that
the file is a combined work consisting of individual works by those people.

To distribute a file that contains one or more works in a way that
copyright would not normally allow without the result being illegal, you
must get permission from all the copyright holders. A copyright license
is just pre-emptive permission from a copyright holder - if you follow
these conditions, the answer is yes - so the most common way to get
permission from all the copyright holders is to comply with all the
conditions imposed by all the copyright holders, simultaneously. For
instance, if the file combines a GPL-2+ work with a GPL-3+ work, you
must simultaneously comply with both

 GPL-2 or GPL-3 or some future version

and

 GPL-3 or some future version

In this simple case, the second condition implies the first, so you
might use a shorthand: this is effectively the same as the whole thing
being GPL-3+. However, this is just a shorthand, and the real status is
somewhat more complicated.

However, the general case is not this simple:

 http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/msg.h
 
 This is a file that is initially copyrighted by Daniel Boulet (and
 licensed under BSD-2-Clause). However, without any other change, it also
 has the header
 
 | Copyright (c) 2000-2007 Apple Inc. All rights reserved.
 | [...]
 | This file contains Original Code and/or Modifications of Original Code
 | as defined in and that are subject to the Apple Public Source License
 | Version 2.0 (the 'License'). You may not use this file except [...]

So what you have here is (claimed to be) a file containing a combination
of a work by Daniel Boulet, licensed under BSD-2-Clause, and a work by
Apple, licensed under APSL-2.0.

To distribute that file, assuming that the claim is true, you must
simultaneously comply with the conditions of the BSD-2-Clause license
(because if you don't, you are infringing Daniel Boulet's copyright),
and with the conditions of the APSL-2.0 (because if you don't, you are
infringing Apple's copyright).

If Apple have not, in fact, modified the file (except to add their
license boilerplate, which might not be sufficiently creative to be
considered to be a copyrightable work), then their assertion that they
hold copyright on the file might not actually be true. If that is the
case, then it might be possible (at your own legal risk) to disregard
that part, then defend yourself on that basis if they sue you. I
wouldn't want to try it myself, because Apple's lawyers are more
expensive than I can afford; and there's no real point anyway, because
you can presumably just get Daniel Boulet's original version of the file
from FreeBSD (?) and avoid the whole issue.

If the two licenses are contradictory (one says you must do something
and the other says you must not, e.g. GPL-2 and GPL-3, or GPL and
OpenSSL) then the combined work is non-distributable. I suspect these
two licenses are not contradictory, though - the BSD-2-clause license
doesn't require much.

 Would you accept such a file in Debian? It is clearly not BSD-licensed,
 even if an unchanged BSD-licensed version exists.

If we can exercise the rights demanded by the DFSG while simultaneously
complying with both the applicable licenses, then the work is Free.

I don't know the precise status of the APSL-2.0 (neither do I
particularly want to), but if the two licenses were a pair that I know
to be Free and non-contradictory (e.g. BSD-2-clause and GPL), then the
ftpmasters would (and frequently do) accept files like that in Debian.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55689e39.5020...@debian.org

Re: MCD-ST Liberty SW License Agreement

[Simon McVittie]

On 14/04/15 19:25, Anton Gladky wrote:
 STMicroelectronics (“ST”) grants You a [...]
 revocable, [...] license

As far as I can see, ST can revoke this license at any time, i.e. they
can say no, we don't want to allow that any more, any further
distribution of our software is copyright infringement.

That might well be a showstopper even for non-free.

 (i) make copies, prepare derivative works [...]
 for the sole and exclusive purpose of
 developing versions of such Licensed Software only for use within the
 Product;

What is the Product? Most legal documents have some section where they
define abbreviated terms like the Product so that they don't have to
repeat the definition everywhere. If so, the document can't be
understood without that section.

This looks like discrimination against fields of endeavor (DFSG §6),
unless the Product is so broadly defined that it covers anything and
everything.

(ii), (iii) are similar.

 Unless otherwise explicitly stated in this Agreement, You may not
sell, assign,
 sublicense, lease, rent or otherwise distribute the Licensed Software
 for commercial purposes, in whole or in part.

They have said that you may make copies and prepare derivative works for
use within the Product, and that you can sell them. I think that's
enough to be explicitly stating, so those parts of this clause might not
apply to the Product, whatever that is.

They have not said you can lease or rent the Product, unless that's
considered to be included in otherwise distribute.

 There are some other stuff in
 Restriction which is probably also makes the license non-free.

 If it is so, is it OK to put the package into a non-free section
 or the license is too bad even for that?

Only the ftp-masters can give you a canonical yes or no on what
legal risk they are prepared to accept for non-free (or for that matter,
for contrib or main), but they'd almost certainly want to see the other
stuff in Restriction before saying anything.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/552d6562.4050...@debian.org

Re: Does logo under CC BY SA makes entire project SA

[Simon McVittie]

On 25/02/15 15:55, Yaroslav Halchenko wrote:
 Now at least we agreed that logo could be released under CC BY SA
 (share-alike) license but I wondered:  if I have a software project
 which is under more permissive license (MIT or BSD-3) and then includes
 that logo a) in the code   b) in the documentation.  Does it obligates
 share alike (thus copyleft) licensing of the entire project, i.e. it
 would not be available for close-source derivatives?

The important question is, is the code or documentation legally a
derivative work of the logo, or have they just been put alongside each
other? (This is really a question for a lawyer - it's a question about
copyright law, not about CC licenses.)

If the logo is compiled into the executable, I would argue that the
executable is a derivative work of both its source code and the logo. If
the logo is loaded by name at runtime, such that you could trivially
substitute any graphic of the same size, I would argue that it isn't:
there is nothing about the logo that was an input to making the
executable, other than perhaps its size and format, which are unlikely
to be considered a creative choice (and hence not protected by copyright).

Similarly, if the documentation loads a separate logo (e.g. in HTML) and
would make just as much sense with a different logo design referring to
essentially the same thing, it probably isn't a derivative work, but if
it integrates the logo into some sort of clever graphic design that it
would have been done differently if the logo was different, then it
probably is.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54edffc5.20...@debian.org

Re: Python GPL-3+ program w/o OpenSSL exception using python-requests

[Simon McVittie]

On 18/01/15 08:18, Vincent Bernat wrote:
  ❦ 17 janvier 2015 19:14 +0100, W. Martin Borgert deba...@debian.org :
 Python program or library X is licensed under GPL3+ without
 OpenSSL exception. X does use the python-requests library,
 which on load dynamically links the Python interpreter with the
 OpenSSL library.
 
 A close issue has already been discussed [1] but it was mostly
 ignored. Doing import readline and import ssl triggers the problem
 without introducing a third-party program.

Copyright law says nothing about loading shared libraries, and quite a
lot to say about creating derivative works.

The important thing from a legal point of view is not does python's
address space contain both readline and OpenSSL? - that's interesting
evidence, but not actually the question that a court case would seek to
determine. The important thing is has a derivative work of readline and
OpenSSL been created? and that's rather less clear-cut.

See also http://lwn.net/Articles/548216/ for related discussion.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54bb7cad.9090...@debian.org

Re: Standard implementation of constant, copyright or not ?

[Simon McVittie]

On 16/01/15 16:23, Geoffrey Coram wrote:
 In particular, Stan Krolikoski wrote:
 Licensing part of standard (as opposed to licensing examples) under
 open source
 seems counterproductive-- a standard is fixed until the relevant
 standards WG
 decides to update it.  Indeed, I would strongly argue that if anyone
 is able to
 make changes to part of a given standard as they wish, then it ceases
 to be a
 true standard.

I understand this position, but it is entirely possible to have a
standard that does not change or is under strict change-control, without
having copyright infringement as a stick to hit people with. A work
derived from a standard is not, itself, the standard (unless/until the
relevant standards body says it is), but it is potentially still a
useful thing for a third party to be able to construct without breaking
the law.

For instance, here are a couple of useful derivative works:

* a version of a standard with additional explanatory text
  (rationale, examples, ...) after each paragraph
* a proposal for changes that someone would like to see in the next
  version of the standard, adapting some paragraphs from the current
  version to illustrate what they want

Surely the harmful thing is not deriving new works from the standard,
the harmful thing is misrepresenting those derived works by claiming
that they are the standard when they are actually not?

XMPP's XEPs (approximately equivalent to RFCs) are all
permissively-licensed
http://xmpp.org/extensions/xep-0001.html#appendix-legal and might be
an interesting model.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54b9c1b1.9020...@debian.org

Re: confirm apache 1 and gpl-1+ situation

[Simon McVittie]

On 11/11/14 06:44, Florian Weimer wrote:
 http://anonscm.debian.org/cgit/collab-maint/xmlrpc-c.git/tree/tools/turbocharger/mod_gzip.c?h=debian-sid
 
 I don't think this file is even compiled, so its license does not
 matter.

I believe the ftp-masters' current interpretation of the DFSG is that
unused files in source packages are still required to be under a DFSG
license, or be removed. However, if this file is not compiled, its
license does not matter other than it's some DFSG license, and it's
mentioned in the copyright file.

(Insert a #error to confirm that it isn't compiled? :-)

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5461e932.6090...@debian.org

Re: confirm apache 1 and gpl-1+ situation

[Simon McVittie]

[Re-sending with the necessary Ccs, sorry for the duplicate on
debian-legal.]

On 11/11/14 06:44, Florian Weimer wrote:
 http://anonscm.debian.org/cgit/collab-maint/xmlrpc-c.git/tree/tools/turbocharger/mod_gzip.c?h=debian-sid
 
 I don't think this file is even compiled, so its license does not
 matter.

I believe the ftp-masters' current interpretation of the DFSG is that
unused files in source packages are still required to be under a DFSG
license, or be removed. However, if this file is not compiled, its
license does not matter other than it's some DFSG license, and it's
mentioned in the copyright file.

(Insert a #error to confirm that it isn't compiled? :-)

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5461e97d@debian.org

Re: Question about Facebook's Osquery: Additional Grant of Patent Rights

[Simon McVittie]

On 30/10/14 03:18, Riley Baird wrote:
 This is the part which worries me:
 
 no license is granted under Facebook’s rights in any patent claims that
 are infringed by (i) modifications to the Software made by you or a
 third party, or (ii) the Software in combination with any software or
 other technology provided by you or a third party.

Suppose Facebook has two patents - one for a method for frobnicating
widgets, and one for a method for reticulating splines, say - and
osquery frobnicates widgets in a way that would be covered by that
patent, but does not currently reticulate splines. Then this patent
grant lets osquery users frobnicate widgets, and the goal of this clause
seems to be that if I modify osquery to add unrelated
spline-reticulation functionality, Facebook can still demand that I
license their spline-reticulation patent separately. I am deliberately
using hypothetical patent examples because I don't know, or want to
know[1], what patents Facebook holds.

The closest copyright equivalent would be that they release one work
under a DFSG license, but keep another work proprietary. Obviously, we'd
prefer that they license all their patents permissively, and all their
copyright works under DFSG licenses; but if they're not going to do
that, which in practice they probably won't, a limited license is better
than no license.

As long as software patents exist, certain specific modifications to
software are never going to be possible to do without infringing a
patent, regardless of the licensing status of the software you started
from. We don't stop considering Linux to be DFSG-licensed just because,
for instance, one example of a modification that could be made to Linux
would be to add exFAT support using the methods described in certain
Microsoft patents, and that would (probably[2]) infringe those patents.
If we *did* let that prevent us from distributing or modifying software,
then there would be no software that we would consider to be DFSG, and
we wouldn't be able to produce a software distribution at all. The fact
that we continue to develop Debian rather than just giving up suggests
that that is not how we interpret the DFSG.

More generally, because independent reinvention without knowledge of the
patent can infringe patents, and patent searches for arbitrary free
software are neither feasible nor advisable[1], it is always the case
that any modification you make to any piece of software might be
infringing some previously unknown patent. There's nothing we can do
about that, other than trying to get the relevant laws changed.

S

[1] https://www.debian.org/reports/patent-faq, under the heading Are
you suggesting that it is better for developers and contributors not to
read patents?
[2] if we assume those patents are valid, which I am neither qualified
to assess, nor interested in assessing[1]


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54520947.1070...@debian.org

Re: License of Doom3-BFG

[Simon McVittie]

On 06/10/14 17:43, Tobias Frost wrote:
  1. Replacement of Section 15. Section 15 of the GPL

This is presumably GPL-3, since there is no §15 in the GPL-2.

 shall be deleted
 in its  entirety and replaced with the following

Strictly speaking, I think this means they've placed Doom3-BFG under a
GPL-3-compatible non-GPL license with no name. Is this the lawyer
equivalent of defining an anonymous function? :-)

The relationship of this license to the GPL would be more obvious if
they'd phrased it in terms of:

The following supplementary terms apply and must be reproduced
in copies of the covered work, as described by section 7 of the
GPL: ...

but it's probably fine.

 15. Disclaimer of
 Warranty.  THE PROGRAM IS PROVIDED WITHOUT ANY WARRANTIES, WHETHER
 EXPRESSED OR IMPLIED,  INCLUDING, WITHOUT LIMITATION, IMPLIED
 WARRANTIES OF FITNESS FOR A PARTICULAR  PURPOSE, NON-INFRINGEMENT,
 TITLE AND MERCHANTABILITY. THE PROGRAM IS BEING  DELIVERED OR MADE
 AVAILABLE AS IS, WITH ALL FAULTS AND WITHOUT WARRANTY OR
 REPRESENTATION. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF
 THE  PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU
 ASSUME THE COST  OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

Seems OK, and GPL-compatible under paragraph 7(a).

  2. Replacement of Section 16. Section 16 of the GPL shall be deleted
 in its  entirety and replaced with the following:  16. LIMITATION OF
 LIABILITY.  UNDER NO CIRCUMSTANCES SHALL ANY COPYRIGHT HOLDER OR ITS
 AFFILIATES, OR ANY  OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM
 AS PERMITTED ABOVE, BE  LIABLE TO YOU, WHETHER IN AN ACTION OF
 CONTRACT, TORT OR OTHERWISE, FOR ANY  DAMAGES OR OTHER LIABILITY,
 INCLUDING ANY GENERAL, DIRECT, INDIRECT, SPECIAL,  INCIDENTAL,
 CONSEQUENTIAL OR PUNITIVE DAMAGES ARISING FROM, OUT OF OR IN
 CONNECTION WITH THE USE OR INABILITY TO USE THE PROGRAM OR OTHER
 DEALINGS WITH  THE PROGRAM(INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR
 DATA BEING RENDERED  INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
 PARTIES OR A FAILURE OF THE  PROGRAM TO OPERATE WITH ANY OTHER
 PROGRAMS), WHETHER OR NOT ANY COPYRIGHT  HOLDER OR SUCH OTHER PARTY
 RECEIVES NOTICE OF ANY SUCH DAMAGES AND WHETHER  OR NOT SUCH DAMAGES
 COULD HAVE BEEN FORESEEN.

Seems OK, and GPL-compatible under paragraph 7(a).

  3. LEGAL NOTICES; NO TRADEMARK LICENSE; ORIGIN. You must reproduce
 faithfully  all trademark, copyright and other proprietary and legal
 notices on any copies  of the Program or any other required author
 attributions. This license does  not grant you rights to use any
 copyright holder or any other party’s name,  logo, or trademarks.
 Neither the name of the copyright holder or its  affiliates, or any
 other party who modifies and/or conveys the Program may be  used to
 endorse or promote products derived from this software without
 specific prior written permission. The origin of the Program must not
 be  misrepresented; you must not claim that you wrote the original
 Program.  Altered source versions must be plainly marked as such, and
 must not be  misrepresented as being the original Program.  

Seems OK, and GPL-compatible under 7(b) to 7(e)

  4. INDEMNIFICATION. IF YOU CONVEY A COVERED WORK AND AGREE WITH ANY
 RECIPIENT  OF THAT COVERED WORK THAT YOU WILL ASSUME ANY LIABILITY FOR
 THAT COVERED WORK,  YOU HEREBY AGREE TO INDEMNIFY, DEFEND AND HOLD
 HARMLESS THE OTHER LICENSORS  AND AUTHORS OF THAT COVERED WORK FOR ANY
 DAMAEGS, DEMANDS, CLAIMS, LOSSES,  CAUSES OF ACTION, LAWSUITS,
 JUDGMENTS EXPENSES (INCLUDING WITHOUT LIMITATION  REASONABLE ATTORNEYS'
 FEES AND EXPENSES) OR ANY OTHER LIABLITY ARISING FROM,  RELATED TO OR
 IN CONNECTION WITH YOUR ASSUMPTIONS OF LIABILITY.

Seems OK, and GPL-compatible under 7(f). I'm not sure what practical
effect it has to write if you agree to assume liability for the work,
then you assume liability for the work, or what jurisdiction makes it
necessary to say so... :-)

Not a lawyer,
S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5432d23b.9000...@debian.org

Re: Providing an openssl-linked pycurl (reviving 2010 thread)

[Simon McVittie]

On 25/09/14 04:18, Andrew Erickson wrote:
 Could an 'official' person make a ruling on Guido's email from 2010
 (link below)?

debian-legal does not control or enforce Debian's official position on
licensing or what can go into the archive. We can offer opinions and
advice, but that's about it. The relevant factors are:

* (for main and contrib) is it Free Software according to the DFSG?
* (for main, contrib and non-free) is the proposed situation something
  we can legally distribute?

and the people with the final word on both these topics are the
ftpmasters, Cc'd here.

ftpmasters, the thread on which Andrew would like a ruling is this:

 https://lists.debian.org/debian-legal/2010/06/msg00016.html
 
 The bug mentioned
 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515200) has
 lingered due to no official response. It's still very much an issue
 and it would be great to have a solution.

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5423ea3d@debian.org

Re: apache2 and gpl2+

[Simon McVittie]

On 01/09/14 20:03, Johannes Schauer wrote:
 What would I put into debian/copyright? GPL2+ (which is what upstream uses but
 is unredistributable) or GPL3+?

If it was me, I'd state the facts:

Format:
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Files: *
Copyright:
 © 2000 Alice Smith
 © 2010 Bob Jones
License: GPL-2+

Files: lib/fuzzylite/*
Copyright:
 © 1995 Fred Bloggs
 © 2005 Jane Doe
License: Apache-2.0

License: GPL-2+
 blah blah blah or any later version blah blah blah common-licenses

License: Apache-2.0
 blah blah blah except in compliance with the License blah blah blah
 common-licenses

(but with the actual copyright holders and license grants instead :-)

and let the reader draw their own conclusions. If you were feeling
explanatory, you could put something like this in the first paragraph,
the one with the Format:

Comment: The effective license for the binaries is (GPL-3+ and
 Apache-2.0) since GPL-2 and Apache-2.0 are not compatible

Or if you don't like the structured copyright file format, do the same
thing with less syntax and more text.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5404d37b.8090...@debian.org

Re: apache2 and gpl2+

[Simon McVittie]

On 31/08/14 17:54, Johannes Schauer wrote:
 As it is pointed out here [5] and here [6], GPL2 is incompatible with Apache2
 but GPL3 projects can contain Apache2 licensed code. Since vcmi is licensed
 GPL2+, could the Debian package upgrade the license to GPL3+ and thus turn it
 into a GPL3 project with Apache2 code which should be compatible? Sorry if 
 this
 is stupid, it's just a naive idea.

(All answers are on the basis of your statements about the license being
accurate: I know nothing about vcmi.)

That general reasoning works, but you don't have to upgrade the
license or anything. The way to think about it is: who has the right to
say what you may do, and what did they say?

The copyright holder of fuzzylite (more precisely, the fuzzylite source
code) says you may copy it, as long as you don't do anything not allowed
by the Apache license v2.

The copyright holder of vcmi (more precisely, the parts of the vcmi
source code other than fuzzylite) says you may copy it, as long as you
don't do anything not allowed by any of the GPL2, or the GPL3, or a
hypothetical future GPL version.

OK, that's the source. What about the binaries? They are a derivative
work of both vcmi and fuzzylite source code, so you may only do things
that are allowed by both the vcmi copyright holders, and the fuzzylite
copyright holders. In other words, the license is you must obey the
GPL2 or later, and simultaneously obey the Apache license v2.

The GPL2 says you can only copy under GPL2 if the source code for the
whole thing is under terms no more restrictive than GPL2, and the Apache
license v2 has terms more restrictive than that, so, no go: this
combination of licenses would place impossible requirements on you.

However, the GPL3 says you can only copy under GPL3 if the source code
for the whole thing is under terms no more restrictive than (GPL3 + a
few restrictions), and the Apache license v2 fits in those few
restrictions, so it is possible to comply with the terms of both the
GPL3 and the Apache license v2 simultaneously. Both of these licenses
let you do everything the DFSG requires, so that's good enough for Debian.

The license applicable to the binaries is still not GPL-3, though - it
is ((GPL-2 or GPL-3 or ...) and Apache-2.0). The practical result is the
same as ((GPL-3 or ...) and Apache-2.0), but it matters if you're going
to extract GPL-2+ bits and combine them with something GPL-2.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54039338.7090...@debian.org

Re: license on upstream web site, not in tarball

[Simon McVittie]

On 28/08/14 19:28, Daniel Pocock wrote:
 If an upstream publishes a license (or link to GPL) and copyright on
 their web site but not in their tarball, how do people feel about that?
 
 Should it just be noted in a comment in debian/copyright?

Copying emails/etc. into debian/copyright is considered to be sufficient
to document clarification/relicensing, so copying a license declaration
from the upstream website into debian/copyright seems like it ought to
be sufficient here - it's effectively the upstream relicensing from the
implied null license (copyright owned by someone, all rights reserved)
to an actual license.

 Or should the packager create a repackaged upstream tarball with a copy
 of the web site text combined with the contents of the original source
 tarball?

I very much hope that's considered to be a waste of time. If you're
going to spend time on this, spend it on asking upstream to make the
license explicit in their future releases.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ff7e79.7030...@debian.org

Re: Upstream GPL-3+ vs debian/* GPL-2+

[Simon McVittie]

On 22/08/14 14:25, Eriberto Mota wrote:
 So, I am thinking that is because Debian
 distributes, separately, the upstream code (orig.tar.gz) and
 debian.tar.xz. Is this? But, the .deb is a product of the junction of
 these files. So, I am confused. Can you clarify me this issue?

The key thing here is that each copyright holder can give you permission
to do things that would normally infringe their copyright, but they
cannot give you permission to do things that would normally infringe
someone else's copyright.

The upstream source code is a copyright-covered work owned by the
upstream developers[1]. They have given permission to copy it under some
license, in this case GPL-3+.

The packaging is another copyright-covered work. It might be legally a
derivative of the upstream source code, or it might not, depending
what's in it and how you made it.

If the packaging is *not* a derived work of the upstream source code,
then its copyright holder is whoever did the packaging[1] and they have
given permission to copy the packaging under GPL-2+.

If it *is* a derived work of the upstream source code, then its
copyright holders are the upstream developers *and* the packager. The
upstream developers have given permission to copy their bit under
GPL-3+, and the packager has given permission to copy their bit under
GPL-2+. To copy it without copyright infringement[2], you must comply
with both licenses simultaneously. In this case that effectively means
GPL-3+, because you do not have the upstream developers' permission to
do anything with their bit that the GPL-2 would allow but the GPL-3+
would not. However, if you are able to extract a smaller part of the
packaging that is not derived from the upstream source - the
README.Debian written by the packager might not be a derived work, for
instance - then you can still copy that smaller part under GPL-2+.

The resulting binary (the .deb) is a third copyright-covered work,
distinct from both the upstream source code and the packaging. It is
likely to be[3] a derivative work of both the upstream source code and
the packaging, so again, both the upstream developer and the packager
have a copyright interest in it, and when you copy the .deb you must
comply with both their licenses simultaneously. In this case that
effectively means GPL-3+ again.

The fact that Debian puts the orig.tar.gz and the debian.tar.gz into
separate files is not relevant here. Whether the packaging is a
derivative work of the upstream source is a property of the content, not
the distribution mechanism: you can put them in the same file and split
that file apart again, and their legal status (whatever it was in the
first place) is not changed by that process.

S

[1] or their employer/school/university/whatever
[2] assuming that fair use / fair dealing does not already allow what
you're doing
[3] there are probably obscure situations in which the .deb somehow
manages to not be a derived work, but the safe assumption is that it is


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f7849e.8030...@debian.org

Re: copyright years in the copyright file

[Simon McVittie]

On 01/05/14 11:16, Riley Baird wrote:
 I still didn't get the problem. What is the copyright year for? What is
 the difference if a software is (c) 1999 or (c) 2014?
 
 All copyrighted materials enter the public domain after a certain number
 of years. To be able to work out whether something is in the public
 domain, the year has to be known.

I am unconvinced by this argument, because I don't think
debian/copyright on its own is ever a going to be a sufficient source
for determining whether a work has passed into the public domain.

What matters for Debian is that the work is under DFSG-acceptable terms,
that we're complying with those terms (e.g. reproducing copyright
notices in accompanying documentation where required), that every
copyright holder has allowed the work to be released under those terms
(although in practice the closest that's ever going to be feasible for
that is we couldn't find any evidence that any copyright holder
*didn't* allow the work to be released under those terms, because we're
not omniscient), and that the work's terms are compatible with those of
other works that we want to combine with it (e.g. avoiding GPL vs.
obnoxious advertising clause). The rest is secondary

It is common for authors to contribute patches to
collaboratively-developed software without also adding themselves to
that file's copyright notice, and it isn't necessarily even clear to
non-lawyers (or even to lawyers) whether any given contribution is
eligible for copyright protection, or whether it is too small/trivial.
As long as that contribution is offered under the same license as the
work itself, the set of copyright holders doesn't usually matter a great
deal for Debian, and the set of copyright years certainly doesn't
(particularly not until the first Unix-related copyright terms start
expiring in a couple of decades, assuming copyright terms haven't been
retroactively extended by media-cartel-sponsored laws by then).

The situations where the copyright year really matters are those where
you want to claim that the work is now in the public domain:

* you want to use the work in a way not consistent with its license,
  e.g. taking a GPL work proprietary, or combining proprietary works
  with GPL'd works

* you want to relicense the work (which could be considered to be a
  special case of using it in a way not consistent with its current
  license)

and in either of those cases you need more information: for instance,
many jurisdictions have copyright terms of the form author's lifetime +
N years for at least some works, so now you need to know which authors
have or haven't died.

When relicensing, it is wise to err on the side of caution. For
instance, when we tried to relicense D-Bus from its GPL-2+/AFL-2.1
dual-license to the Expat license, Ryan Lortie used the copyright
headers, revision control history and ChangeLog to contact everyone who
*might* have been a copyright holder, because that was easier than
seeking legal advice on whether specific maybe-copyright-holders
actually held copyright. (We still couldn't relicense in the end,
because one early copyright holder had gone bankrupt, so tracing the
recipient of their copyright was difficult.)

The conservative assumption for copyright years is that a particular
version of a work (for instance, libfoo 1.2.3, not just libfoo) is
copyright [earliest copyright notice or release date]-[release date of
that version] by each copyright holder, unless you can find very good
evidence to the contrary.

Similarly, debian/copyright is a best-effort summary of copyright
holders, but if you actually want to track down the complete set of
copyright holders for relicensing or whatever, the conservative
assumption should be that you should use all available public
information (revision control, ChangeLog, *and* copyright headers) to
find everyone who *might* be a copyright holder.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53677228.3020...@debian.org

Re: Derivatives forced to have the same license

[Simon McVittie]

On 06/02/14 01:36, Matthew Kloth wrote:
 For example:  I make an image and put it under my superviral license. 
 Somebody else creates a derivative and posts it to deviantart or flickr
 or some such place.  Their derivative work is automatically under the
 superviral license simply because they created and distributed a
 derivative.  Even if they don't put a superviral license notice, it
 would still be under that license whether or not they wanted it to be.

As far as I'm aware, the GPL gets as close to this as is legally
possible. GPL3 §9:


You are not required to accept this License in order to receive or run a
copy of the Program. Ancillary propagation of a covered work occurring
solely as a consequence of using peer-to-peer transmission to receive a
copy likewise does not require acceptance. However, nothing other than
this License grants you permission to propagate or modify any covered
work. These actions infringe copyright if you do not accept this
License. Therefore, by modifying or propagating a covered work, you
indicate your acceptance of this License to do so.


(GPL2 §5 is similar.)

If the author of a derivative work[1] asserts that they have not agreed
to the license, then they're illegally infringing your copyright
instead, and what happens is between you, them and the legal system. If
threatened with legal action, I would hope that the rational response
would be to apologise and release their derivative under an appropriate
license; but you never know.

If the derivative work is derived from more than one source then it
certainly isn't safe to say this is GPL'd, because the GPL says so,
because its publisher might not have the authority to release it under
GPL at all. A concrete example to make this less vague:

* Alice publishes a work A under CC-BY-NC
* Bob publishes a work B under the GPL
* Chris publishes a work C derived from both A and B

Chris does not have the authority to release C under the GPL (because
the GPL allows commercial use and CC-BY-NC does not), CC-BY-NC (because
the GPL does not allow that additional restriction), or any other
license (because they can't satisfy both conditions simultaneously), so
depending on the license they chose for C, they are infringing Alice's
copyright, Bob's copyright, or both.

S

[1] assuming that what they're doing with their derivative is something
that is forbidden by copyright law in the relevant jurisdiction (which
it might not be, for instance if their work is a parody of yours)


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f37374.3050...@debian.org

Re: word lists

[Simon McVittie]

On 01/02/14 06:07, Werner LEMBERG wrote:
   (1) What happens with the copyright of works if I extract
   information as explained in my previous mail?
   (2) What copyright can a word list have at all, given that it gets
   mechanically extracted? [...]

I think you'd have to ask a qualified lawyer to get a good answer for these.

   (3) The frequency of words is a statistical information, a byproduct
   of collecting the data mechanically, without any manual
   intervention.  Can such information be copyrighted, too?

I'm not sure that it can, but in the EU there's something rather similar
for non-creative collections of data:

https://en.wikipedia.org/wiki/Sui_generis_database_right

   (3) What license do you recommend for a list of German words (as in
   our project) enriched with information on weighted hyphenation
   points?  Contrary to (2) and (3), we enter our information
   manually, however, it's just describing inherent properties of
   German words.

How do you want to license it? Copyleft or permissive?

If you're happy with a permissive license, I would personally suggest
the CC0 public-domain dedication, which specifically relinquishes
database rights as well as copyright:

https://creativecommons.org/publicdomain/zero/1.0/legalcode

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ed1867.40...@debian.org

Re: dxsamples: New upstream version 4.4.0 available

[Simon McVittie]

On 12/11/13 10:43, Graham Inggs wrote:
 The previous maintainer of dxsamples felt that the license of some of
 the examples added in more recent versions made it unsuitable for
 distribution in Debian.

I don't see a license problem with what you quoted. It would be nice if
the copyright holder had used a more common form of the MIT-style
license (the Expat license is the closest thing there is to a canonical
MIT/X11 license, and is the one in the OSI license list), but it appears
to be DFSG-compliant and GPL-compatible.

The maintainer will have to copy this license into debian/copyright in
order to satisfy both Debian policy and the ... in supporting
documentation ... clause.

  * (C) Visualization and Imagery Solutions, Inc. 2002
  *
  * Permission to use, copy, modify, and distribute this software and its
  * documentation for any purpose and without fee is hereby granted,
  * provided that the above copyright notice appear in all copies and that
  * both that copyright notice and this permission notice appear in
  * supporting documentation, and that the name of VIS not be
  * used in advertising or publicity pertaining to distribution of the
  * software without specific prior written permission.

This is the first paragraph of what
https://fedoraproject.org/wiki/Licensing:MIT calls Old Style with legal
disclaimer, with s/M.I.T./VIS/ and the last sentence
(mini-warranty-disclaimer) removed. Seems fine to me.

  * THE SOFTWARE IS PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY
  * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

This disclaimer of warranty looks fine to me, and is similar to the one
recommended for use with the GPL.

  * VIS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
  * ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  * PURPOSE. IN NO EVENT SHALL VIS BE LIABLE FOR ANY SPECIAL, INDIRECT
  * OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
  * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
  * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE
  * OR PERFORMANCE OF THIS SOFTWARE.

This is back to what https://fedoraproject.org/wiki/Licensing:MIT calls
Old Style with legal disclaimer. Also looks fine to me.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5282109c.2090...@debian.org

Re: CC0 and authors' names in Copyright field

[Simon McVittie]

On 02/10/13 08:49, Gioele Barabucci wrote:
 (BTW, is the fact that CC0 is a licence
 rather than a dedication an accepted POW? I thought it was still an
 open question.)

My understanding is that it's both, stuck together, in one convenient
document - to work around the jurisdictions where you can't relinquish
copyright, and the jurisdictions where it's unclear whether you can or not.

The tl;dr version of CC0 is if my jurisdiction lets me put this work in
the public domain, I'm doing that, and if not, you may copy/modify it
under this very broad permissive license. The quantum superposition
won't collapse unless it becomes relevant to a court case :-)

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/524c00e4.4080...@debian.org

Re: SEIKO EPSON license, suitable for non-free ?

[Simon McVittie]

On 07/12/12 11:50, Didier 'OdyX' Raboud wrote:
 To ease the installation of the various Epson drivers [0], I'd like to get 
 them uploaded to Debian (even non-free would be an improvement over their 
 download page).

That would be nice, but no permission has been given to redistribute
them, and...

 But these packages all come with the SEIKO EPSON CORPORATION SOFTWARE 
 LICENSE 
 AGREEMENT (attached), which I wonder if it allows redistribution through 
 Debian's non-free.

tl;dr: no.

| 2. [...] You may not share, rent, lease, encumber,
| sublicense or lend the Software.

... this specifically forbids sharing. You'd need specific permission
from the copyright holders: at a minimum, Debian and its mirrors need to
be allowed to redistribute whatever you package in non-free.

It even goes further:

| 5. [...] You agree to use your best efforts and take
| all reasonable steps to safeguard the Software to ensure that no
| unauthorized person has access to them and that no unauthorized copy,
| publication, disclosure or distribution of any of the Software is
| made. You acknowledge that [...] unauthorized use and copying are
| harmful to EPSON and its suppliers

which is obviously not possible for Debian to agree to, given that if it
was in non-free, we'd be using our best efforts to ensure that everyone
on the Internet can get a copy! :-)

Another possible route would be to take the same approach as
game-data-packager, java-package, googleearth-package and friends:
require the user to download their own copy, and provide a script to
mangle it into an installable .deb on their own system, at their own
legal risk.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50c1e043.9010...@debian.org

Re: `free' in GNU and DSFG?

[Simon McVittie]

Please see the threads that led to
http://www.debian.org/vote/2006/vote_001 for exhaustive discussion
about the GFDL vs. the DFSG.

On 08/06/12 16:34, Christofer C. Bell wrote:
 I cannot think of a case where someone
 modifying the document would, when acting in a good faith manner, want
 to alter this text.

That would be fine if we (either Debian when redistributing the
document, or someone wanting to alter the document later) could delete
them - but clause 4L, and the first paragraph of section 5, forbid that.

 would a
 GFDL document that has no invariant sections be considered Free under
 the current Debian guidelines?

According to the General Resolution at
http://www.debian.org/vote/2006/vote_001, yes. The GNU Libtool manual
in libtool-doc is one example of a GFDL-with-no-invariant-sections
document in main.

(The GR was not unanimous - a significant number of Debian members would
have preferred for libtool-doc to be excluded from main too.)

 They have 4 licenses, all of which seem to serve a unique and
 necessary role:  GPL, LGPL, AGPL, and GFDL.

The major reason I never want to put anything I write under the GFDL is
that it has annoying practical consequences.

The AGPL, GPL and LGPL (of the same version) are copyleft licenses with
varying terms, but form a chain of compatible licenses in which you can
combine works under any pair of those licenses, and put the result under
the more restrictive license.

The GFDL and GPL are mutually-incompatible copyleft licenses (each
includes restrictions that the other does not), so you can't combine
parts of a GPL'd work with parts of a GFDL'd work, under any license,
unless you are the sole copyright holder on both. That's fine for GNU
(the sole copyright holder on GNU projects, via copyright assignment),
but an obstacle for the rest of the world.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd2210f.30...@debian.org

Re: MIT/Expat with The Software shall be used for Good, not Evil statement

[Simon McVittie]

On 26/04/12 11:41, Dmitry Nezhevenko wrote:
 I've already got response for upstream. File jsmin.py itself in
 package will have no special license as it's just wrapper
 around non-free jsmin. So special licensing will be removed from
 LICENSE.
 
 Is it ok to patch such jsmin.py wrapper now to do nothing?

The requirement for main is that you don't cause any non-free code to
be present in the archive: either in the orig.tar.*, the Debian
diff/tarball, or the binary packages. (That's why patching out
non-free code is not OK, because that still results in Debian
distributing one copy of it in the orig.tar.*, and a second copy in
the - lines of the Debian diff.)

This situation is a bit confusing because it sounds as though there
are two files involved, both called jsmin: the library is a
translation of the original jsmin non-Python library into Python
(Good, not Evil license inherited from the original jsmin non-Python
library), and the wrapper wraps it in a common API (Expat license).
Is this the case? If so, you must not distribute the library but I
think it's OK to distribute the wrapper.

If that's the case, and the orig tarball doesn't contain an embedded
code copy of the library, then yes I think you can just patch the
wrapper.

If your orig tarball does contain an embedded code copy of the
library, you must still repack the tarball to remove it.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f992b89.5040...@debian.org

Re: Patents and Multimedia codecs in Debian

[Simon McVittie]

On 28/03/12 07:40, Alexey Eromenko wrote:
 The Debian project includes a number of patent-encumbered Multimedia
 codecs

As mentioned in Debian's patent policy
http://www.debian.org/legal/patent point 3, please refrain from
posting patent concerns publicly or discussing patents outside of
communication with legal counsel, where they are subject to
attorney-client privilege.

Transparency and public discussion are usually good things, but patents
are an area where they can be harmful.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f72c5dc.3070...@debian.org

Re: 3 questions around source of GPL images

[Simon McVittie]

I have no opinion on whether the SVG files are required by the
GPL/DFSG, or just count as an older version of the preferred form
for modification in this case. Defining the preferred form for
modification for non-programs gets a bit vague...

If it's easy to find the corresponding SVGs, the safe option is to add
them to the source package, and stop caring about whether the license
required you to do so or you're just being helpful.

If they *are* required by the GPL/DFSG, then you can't rely on another
package to provide them without a dependency relationship:

On 18/03/12 23:48, Thomas Preud'homme wrote:
 = Since Debian distribute the source for both package X (the KDE
 icon theme) and my package, I'd say the image are correctly
 acompanied with the source (both are in Debian archive) as per
 GPL-2 3.a) or GPL-3 6.d (If the place to copy the object code is a
 network server, the Corresponding Source may be on a different
 server).

From a purely practical point of view, this is not guaranteed to
remain true: packages, and specific package versions, get removed from
the archive regularly. The KDE icon theme will hopefully never get
removed, but the specific version from which your package is derived
will disappear eventually.

If your package needs to keep another source package in the archive in
order to comply with the GPL (e.g. binutils-mingw-64 needs to keep its
corresponding binutils in the archive), that's what the Built-Using
field is for - but in this case that isn't really appropriate (it'd
keep a particular version of the KDE icon theme in the archive
indefinitely).

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f667cc7.1020...@debian.org

Re: libidn re-license

[Simon McVittie]

On 07/03/12 09:01, Simon Josefsson wrote:
 I co-maintain the libidn package.  As upstream, I recently relicensed it
 from LGPLv2+ to GPLv2+|LGPLv3+.

This effectively means: recipients of the new libidn may choose any
license which they could choose for the old libidn, except for the
LGPLv2 and LGPLv2.1.

Is there a particular reason why you want to deny permission to use your
library under those specific licenses? Is there something they allow
that you want to forbid? If not, I'm not sure that I see why you'd want
to change it... particularly if you have to get into dual-licensing. I
can see advantages of the LGPLv3 over the LGPLv2 from a clarity point of
view (it's just the GPLv3 with exceptions, whereas the LGPLv2 and v2.1
are separate licenses with explicit provision to relicense to the
GPLv2), but an explicit dual-license seems as though it defeats that
clarity.

Obviously, it's your choice as copyright holder, but I can't say I'm
entirely happy about libraries getting a more restrictive license in
newer versions; I feel as though the general principle of
backwards-compatible API (everything that used to work should still
work) applies just as much to licensing. Hopefully nobody's going to end
up forking an older version as libidn-lgpl2 or something...

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f588396.3060...@debian.org

Re: Thoughts on GPL's Appropriate Legal Notices? or the CPAL?

[Simon McVittie]

On Wed, 14 Dec 2011 at 16:47:33 -0500, Clark C. Evans wrote:
 the question for me is 
 if Powered By SugarCRM is a reasonable author attribution.

No, I don't think it is.

Copyright © 2011 John Doe and Copyright © 2011 SugarCRM Inc. are
both Appropriate Legal Notices; Incorporates code by John Doe,
Based on a work by SugarCRM Inc. and Authors: John Doe, Jane Smith et al
all seem like reasonable author attributions.

This is not the clearest possible example; be careful to distinguish here
between SugarCRM, a product, and SugarCRM Inc., a legal entity. A product
can't be an author, but perhaps a legal entity can, depending how you and
your jurisdiction interpret the relationship between work-for-hire and
authorship.

Here's a clearer example with less confusing names: Powered by
GNU Emacs is neither an author attribution nor an Appropriate Legal Notice;
© Free Software Foundation, Inc. is an Appropriate Legal Notice;
Author: Richard Stallman is an author attribution.

 | (By contrast, incorporates code from SugarCRM would remain a true
 fact,
 | and is nicely neutral: a non-binding request to acknowledge use of
   

To be clear, I didn't intend this as an example of something that should be
mandated by the license either. (I'm sure there are situations where it can
become equally false in something that is still legally a derived work,
in fact.)

Here's an example of what I mean by a non-binding request:
http://www.portaudio.com/license.html
(That particular example is unusually clear and specific; most are rather
more vague.)

Or you could just include a reasonable credit of your choice in the work,
and rely on it being reasonable enough that there's no reason
to patch it out. (Of course, this only works if it actually *is* reasonable.)

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111215144333.ga3...@reptile.pseudorandom.co.uk

Re: Thoughts on GPL's Appropriate Legal Notices? or the CPAL?

[Simon McVittie]

My recommendation (for basically any software, not just yours!)
is still licensing under either the GPL, LGPL or Expat MIT/X11 license;
of which the GPL sounds like the best fit for what you want.

On Wed, 14 Dec 2011 at 14:18:41 -0500, Clark C. Evans wrote:
 Is there a debian-legal position on Appropriate Legal Notices 
 aspect of the GPLv3.  Including 5(d) and 7(b)

(This is my personal opinion; I'm not speaking for Debian, debian-legal,
the ftpmasters (who get the final say on whether things get into Debian
or not), my employer, or anyone else.)

As far as I understand it, the purpose of §7(b) is to make it
absolutely clear that the FSF considers BSD-style licenses - with their
this notice must accompany the binaries and/or source clauses - to be
GPL-compatible.

Regarding §5(d), here are some Appropriate Legal Notices (which has
a defined meaning in the license) displayed by gdb whenever it starts up:

  GNU gdb (GDB) 7.3-debian
  Copyright (C) 2011 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type show copying
  and show warranty for details.

 OR, alternatively, 
 the OSI approved Common Public Attribution License (CPAL).

I'm a DD who sometimes gives people licensing advice, and I've never heard
of that license. As far as I'm concerned, that's a great big warning sign -
please avoid obscure licenses.

 I'm asking because having appropriate credit really resonates 
 with with those in my organization who are getting behind 
 releasing our entire medical informatics system (and modules).

There's sometimes a fine line between appropriate credit and obnoxious
advertising; the more reasonable you are about it, the happier everyone
is likely to be to go along with it (and, I suspect, the more sympathetic
a court will be if you sue someone over removing whatever amount of credit
is mandated by your license).

Is the sort of thing that gdb displays enough for you/them? If so,
problem solved.

Failing that, if you make the system display what you consider to be
appropriate credit, is anyone, realistically, ever going to patch it out?
If they did, even after you asked them not to, would you sue them? (If not,
then there's no point in mandating it in a license.) From a PR point of view,
a non-binding request to do something that reasonable people would probably
do anyway seems a more friendly way to deal with your customers in any case.

  * In accordance with Section 7(b) of the GNU Affero General Public
  License version 3,
  * these Appropriate Legal Notices must retain the display of the
  Powered by
  * SugarCRM logo. If the display of the logo is not reasonably feasible
  for
  * technical reasons, the Appropriate Legal Notices must display the
  words
  * Powered by SugarCRM.

I think this goes beyond (A)GPLv3 §7(b): Powered by SugarCRM is neither an
Appropriate Legal Notice (defined in the AGPLv3 as a copyright notice,
statement of no warranty, or statement that it's under the AGPLv3) nor
an author attribution (author attributions look like this: based on software
written by John Doe, Jane Smith and FooCorp, Inc.).

It's also not necessarily true, or advantageous to the authors of SugarCRM.
If I extracted a module from SugarCRM to use in my new webapp, it looks as
though the authors of SugarCRM are trying to require me to say
Powered by SugarCRM - even if the rest of my webapp is so bad that doing
so could damage SugarCRM's reputation!

(By contrast, incorporates code from SugarCRM would remain a true fact,
and is nicely neutral: a non-binding request to acknowledge use of SugarCRM
is much less adversarial and probably has about the same practical effect.)

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111214203231.ga...@reptile.pseudorandom.co.uk

Re: a Free Platform License?

[Simon McVittie]

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


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2028161129.gb28...@reptile.pseudorandom.co.uk

Re: Bug#639916: spread: license wackiness

[Simon McVittie]

On Mon, 05 Sep 2011 at 07:32:33 +0200, Florian Weimer wrote:
 * Ken Arromdee:
  Unlike the original BSD 4 clause license this adds or software that uses
  this software.
 
 Is it really that much different in effect from the Affero GPL?  It
 may be a bit more far-reaching, but compliance is so much easier.

The AGPL requires you to provide (an opportunity to download) Corresponding
Source in the webapp itself, but this license contaminates web pages that
merely *refer to* the webapp; I think that's considerably more onerous.

(If Spread-based webapps had to display the specified text This product...
For more info... in the webapp itself, you're right that that would be less
onerous than the AGPL, but that's not what the license says.)

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110905183950.ga32...@reptile.pseudorandom.co.uk

Re: recommendation for packaging license

[Simon McVittie]

On Fri, 02 Sep 2011 at 14:10:38 +0200, Thomas Koch wrote:
 Could you enhance the documentation of the copyright format or the policy 
 with 
 a recommendation for the copyright in the debian/* files section? I couldn't 
 care less about the copyright and tend to use the Do What The Fuck You Want 
 To Public License. However I really want to make life as easy as possible 
 for 
 all humans. It'd also be nice if it could be a license where I don't need to 
 copy the license text in the copyright file to keep it as short as possible.

By Policy, the only licenses you don't need to quote in the copyright file
are the ones in /usr/share/common-licenses, and the license grant to put
something under one of those licenses properly is of comparable length to
a short license like Expat.

For minimal length for a comprehensive Free license, I still like the
GNU all-permissive license:

https://www.gnu.org/prep/maintain/html_node/License-Notices-for-Other-Files.html
 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
 notice and this notice are preserved.  This file is offered as-is,
 without any warranty.

and the ad-hoc license of IkiWiki's basewiki:

http://ikiwiki.info/freesoftware/
 Redistribution and use in source and compiled forms, with or without
 modification, are permitted under any circumstances. No warranty.

although Joey warns that the warranty disclaimer in the latter may not be
safe to apply to general software:

http://lists.debian.org/debian-legal/2010/04/msg00097.html
 Its warantee disclaimer is indeed weak. I don't know that I would
 want to use this on any software that could cause trouble if it broke.
 The files it was attached to are mostly templates that users go in and
 edit, and some documentation.

The no-warranty disclaimer is somewhat orthogonal to having a Free Software
license, but may be important to protect you from being sued by your users
over bugs in your software; the wording in the GPL is carefully chosen to
mention specific phrases (as is, fitness for a particular purpose) that
are significant in USA law.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110902143921.gb6...@reptile.pseudorandom.co.uk

Re: Question about GPL and DFSG Compatibility of a Proposed Amendment to the W3C Document Licence

[Simon McVittie]

On Thu, 28 Apr 2011 at 13:27:48 +0200, Lachlan Hunt wrote:
 This would seem to imply a field of use restriction
 against anything that is not covered by those 3 exceptions.  In
 particular, this does not explicitly permit others to fork the
 specification.

It seems from the linked pages that one goal of the W3C's current non-Free
document licensing is to prevent third parties from forking (say) the CSS3
spec, making random changes (potentially incompatible ones), and publishing
the result (as FooCorp CSS 4, perhaps). RFCs have a similar policy and it
presents similar problems http://josefsson.org/bcp78broken/ (although
recent RFCs use a BSD-style license for code fragemnts, avoiding some of the
bad effects of BCP78).

I can see why the W3C needs to discourage forks of its standards, and in
particular, avoid misrepresentation of modified versions as the original or
W3C-approved version, but I don't think copyright is necessarily the right
way to achieve this: making it illegal to distribute modified versions seems
a much bigger hammer than is necessary. Holding and enforcing a trademark
on the W3C name (as W3C indeed does) seems a more appropriate mechanism?

There's nothing to stop a vendor embracing-and-extending a W3C standard
without making verbatim copies of any of the W3C's spec wording (e.g. each
major browser supports a HTML-like markup language consisting of a W3C-HTML
subset plus browser extensions), so it's not clear to me that using copyright
like this is particularly effective either.

It seems particularly perverse to take legal measures to prevent forking when
a reimplemented description of HTML5 is available under a much more
permissive license from WHATWG...

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110428154810.ga10...@reptile.pseudorandom.co.uk

Re: Re: Question about GPL and DFSG Compatibility of a Proposed Amendment to the W3C Document Licence

[Simon McVittie]

On Thu, 28 Apr 2011 at 17:41:40 +0200, Lachlan Hunt wrote:
 Paul Wise wrote:
 Is there any chance they would use an existing license instead of
 reinventing the legal wheel?
 
 Many of us are arguing that the W3C should do just that with
 suggestions to use MIT, BSD or CC0.

I'm glad to hear it!

It may be worth mentioning that since 2008, the XMPP Software Foundation has
used a MIT-based license for its specifications:
http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110428160657.ga12...@reptile.pseudorandom.co.uk

Re: The Evil Cookie Producer case

[Simon McVittie]

On Mon, 07 Mar 2011 at 11:04:11 +0100, Bruno Lowagie wrote:
 This is what the end consumer wants,
 and this is what 1T3XT wants, regardless of the opinion of any other
 party in-between.

I think there's an important distinction between I believe that it's
beneficial for everyone that this is done, this is sufficiently important
that someone should cause it to be legally binding, and this is sufficiently
important that I, personally, need to enforce it via my copyright license.

I'd like it if nobody forked my Free Software and everyone sent me patches for
their changes, but there seems to be a general consensus (which I agree with)
that enforcing this via a license is too high a price to pay for this good
behaviour - the right to fork is also valuable. So, I can request it, but if
I try to enforce it we consider that to be a non-Free restriction.

A couple of relevant things to think about: suppose I fork iText (and call it
smcvText).

* Do you intend your extra term to force me to put iText in the producer line,
  which is arguably not true any more since I'm using a modified version
  with exciting new bugs?

* Or, do you intend your extra term to force me to put smcvText, or
  smcvText (based on iText), in the producer line?

* If I don't do either (or if I choose the wrong one!), presumably when you
  found out you'd ask me to fix that. If I refused, would you sue me? If the
  answer is no then it doesn't seem as though you'd have gained anything by
  adding the term to the license; there's no point jumping through hoops to
  make something enforcable if you're not going to enforce it.

I don't think your extra term complies with AGPL 7(b) as it claims, because
7(b) requires preservation of legal notices/attributions in material you add
to a covered work or in the Appropriate Legal Notices displayed by works
containing it - you can force people to keep your attribution in iText's
Help - About or --version output or equivalent, but I don't think this
applies to iText's *output* (unless its output contains enough of a copy of
iText that all PDFs produced by it are *also* covered by the AGPL, but I think
that'd imply a lot of practical problems anyway). So, you've effectively
created an AGPL-like, but incompatible, license.

Because of your modified license, I can't combine iText with code from
another GPL'd or AGPL'd work. Is that an acceptable price to pay? We strongly
discourage the use of non-standard licenses because of practical problems like
these. A non-standard license can be DFSG-compliant but still a bad idea
(look at OpenSSL and all the practical problems that's caused).

In this particular situation I'd suggest making the extra term a non-binding
request, something like:

The author of this software requests that you retain the iText producer
line in every PDF that is created or manipulated using iText.

or even:

The author of this software requests [...etc...] to facilitate debugging
of any post-processing issues and [... other reasons? ...]

or even just insert similar wording as a comment in the source code, next to
the code that adds the producer line. Anyone who's not being deliberately
awkward will probably comply with your request, particularly if the reasons
are as compelling as you imply, and if they *are* being deliberately awkward,
perhaps they don't deserve your help :-)

-

Rather off-topic, but back to your cookie analogy: I don't think using
copyright law or private contracts as a way to enforce may contains nuts
labelling would be appropriate either. The reason that those labels are
legally mandated (in many countries) is that society has decided that the
burden of labelling products is an acceptable price to pay for not having
people who're allergic to nuts accidentally eating them and dying. If it's
important enough to be enforced (and IMO it is), then it's important enough to
be enforced for everyone, not just users of your particular brand of
cookie-making machines. Enforcing society's consensus on everyone, so
individuals don't have to, is what governments are for...

In the desert island situation, attempting to create unrelated laws via
copyright seems rather futile; if there's nobody who can enforce safety
labelling, probably nobody's enforcing copyright either.

(I hope your analogy is exaggerated and nobody actually has an
anaphylactic-shock reaction to iText output :-)

Regards,
S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110307122654.ga6...@reptile.pseudorandom.co.uk

Re: data copyright or not -- what is Debian's take?

[Simon McVittie]

On Tue, 25 Jan 2011 at 14:06:49 +1100, Ben Finney wrote:
 I don't see a need to specify “data”. What's wrong with “work”, the term
 normally seen in English-language copyright discussions for any
 information covered by copyright?

Since the issue under discussion is things that might or might not be covered
by copyright, I wasn't sure whether work as legal jargon implies
copyrightable thing (and hence isn't applicable to non-copyrightable things);
avoiding the term presumably sidesteps that :-)

   Permission is hereby granted, free of charge, to any person
   [... and the rest of the usual MIT license text]
 
 Where “the usual MIT license text” presumably means the more precise
 “terms of the Expat license”.

Yes, I meant the Expat license (or in fact, what I really meant was insert
the terms of your favourite permissive license here, but the Expat license
is a good choice).

 So long as the terms are as I specified above, I think that's a good
 strategy also, but it is only effective if done by the copyright holders
 (not unilaterally by a third party).

I don't see how anyone who isn't the copyright holder[1] could offer a license
for material that might be copyrightable, but yes, it's worth emphasizing that.

S

[1] by which I really mean: entity who would be the copyright holder if the
work was copyrightable, which it might be, or not. Superpositions
of states are hard to talk about precisely :-)


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110125172712.ga31...@reptile.pseudorandom.co.uk

Re: data copyright or not -- what is Debian's take?

[Simon McVittie]

On Mon, 24 Jan 2011 at 10:44:34 -0500, Yaroslav Halchenko wrote:
 Should I advise to blindly attach a copyright  statement and
 license, possibly copyrighting non-copyrightable, thus committing
 Copyfraud in some jurisdictions?

I'm not a lawyer or anything, but would this work?

To the extent that it is covered by copyright under any applicable laws,
this data is copyright © 1984 Winston Smith.

Permission is hereby granted, free of charge, to any person
[... and the rest of the usual MIT license text]

If it turns out not to be covered by copyright, this is a no-op; if it is,
it gives permission for more or less everything.

S


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110124160711.ga3...@reptile.pseudorandom.co.uk

Re: One-line licence statement

[Simon McVittie]

(Summary of the thread for Joey's benefit: some software mentioned on
debian-legal had a one-line license which was intended to be
almost-public-domain, but failed to give explicit permission to copy and
modify. Franck is talking to that software's author to get it relicensed in
a DFSG way; I suggested the ikiwiki basewiki license.)

On Fri, 23 Apr 2010 at 11:26:43 +1000, Ben Finney wrote:
 Franck Joncourt franck.m...@dthconnex.com writes:
  On Wed, Apr 21, 2010 at 09:57:58PM +0100, Simon McVittie wrote:
   A 2-line version that seems good is the one Joey Hess uses for the
   parts of ikiwiki that get copied into users' wikis, among other
   things:
   
   http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=debian/copyright
   Redistribution and use in source and compiled forms, with or without
   modification, are permitted under any circumstances. No warranty.
   
   It's shorter than the canonical version of the WTFPL, and seems to
   cover all the necessary things for a permissive free software
   license:
   
   * allows unmodified and modified copying
   * allows binary distributions
   * explicitly disclaims warranty (quite important in some
   jurisdictions, I hear)
 
 My one quibble is that the “No warranty” is open to misinterpretation.
 (I usually make it a complete declarative sentence: “No warranty
 expressed or implied.”) But not very much, so it's a minor quibble, and
 I wouldn't reject any software on that basis.
 
  Upstream took a look at it and is going to adpot this one.
 
  Many thanks for your help.
 
 Yes, thanks for presenting that license text; I agree that it's superior
 to WTFPL, and worth suggesting for these use cases.
 
 Does it have a snappy name that we can use to refer to it?

Not that I know of; judging by putting this wording into Google, only Joey
uses it. I called it the ikiwiki basewiki license above, but I don't think
that's necessarily a good way to refer to it out of context. The rest of
ikiwiki is not under this license (it's mostly GPL), and the definition
of the basewiki is ikiwiki jargon.

Joey, I don't suppose you have a name for this license? :-)

Regards,
Simon


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100423130046.ge23...@reptile.pseudorandom.co.uk

Re: One-line licence statement

[Simon McVittie]

On Wed, 21 Apr 2010 at 20:34:05 +0200, Franck Joncourt wrote:
 As a matter of fact upstream tries to find something as close as possible to 
 the
 public domain but keeping the copyright holders. It is a matter of *how to
 write it?*

A 2-line version that seems good is the one Joey Hess uses for the parts
of ikiwiki that get copied into users' wikis, among other things:

http://git.ikiwiki.info/?p=ikiwiki;a=blob;f=debian/copyright
Redistribution and use in source and compiled forms, with or without
modification, are permitted under any circumstances. No warranty.

It's shorter than the canonical version of the WTFPL, and seems to cover all
the necessary things for a permissive free software license:

* allows unmodified and modified copying
* allows binary distributions
* explicitly disclaims warranty (quite important in some jurisdictions, I hear)

There's also a semi-standard permissive license recommended by the FSF
for READMEs and similar trivial files:

http://www.gnu.org/software/hello/manual/texinfo/All_002dpermissive-Copying-License.html
 Copying and distribution of this file, with or without modification,
 are permitted in any medium without royalty provided the copyright
 notice and this notice are preserved.

Regards,
Simon


-- 
To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100421205758.ga17...@reptile.pseudorandom.co.uk