Jonas Smedegaard <[email protected]> writes:
> What I mean to say is, instead, "this section contains works that I
> cannot meaningfully state copyright and licensing for as a whole but
> also cannot meaningfully inherit from the superset of debian/* (and the
> superset of debian/* I cannot meaningfully omit because at least
> copyright is unlikely to be same for packaging as for upstream work),
> because each of the patches either a) is not copyrightable, or b) was
> cherry-picked upstream so potentially (but not necessarily) have same
> copyright and license as upstream project (i.e. not the nearest
> superset section of debian/* in the machine-readable inheritance logic,
> but topmost superset of *), or c) was created by the same authors as in
> the superset section of debian/* so potentially (but not necessarily)
> have same copyright and licensing as the packaging (which might be same
> as upstream but maybe not), or d) was created by others than both
> upstream and Debian packaging (e.g. contributed in a bugreport) so may
> have any license and certainly differing copyright".
Ah, yes, I was misreading what you were trying to convey.
I think I understand the problem that you're trying to solve, and I think
it's yet another form of a standard free software problem, namely that
most of us do not use copyright assignments, contributor licensing
agreements, or developer certifications because we find them obnoxious,
but there are reasons why things all exist. I think you are trying to be
very precise about software licensing without using any of the tools that
lawyers have developed to allow you to be very precise about software
licenses, and one of those two things has to give.
Let me back up and try to explain this at a higher level. I'm going to say
a bunch of stuff here that you obviously already know, but it was helpful
for my thinking to lay it all out anyway, and that will let other folks
spot any flaws in my reasoning or places where they disagree. Also, I'll
say again that this is all based on my amateur understanding of copyright
law as a free software developer and I'm not a lawyer and probably am
wrong about some of the details.
I believe the following things are roughly true about copyright law under
Berne. There's a lot of per-country variation, so I'm more confident about
this being roughly true under US copyright law and less confident about EU
(or elsewhere) copyright law:
* Anything someone writes that involves non-trivial creative effort is
copyrighted by default. This is a very complicated legal standard that
is easy to oversimplify. Whenever I've seen a layman try to explain this
standard in front of a lawyer, the lawyer starts making distressed
facial expressions.
* The default rule for copyright is that unless you explicitly give your
permission to use your copyrighted work, it can only be used in ways
that fall under fair use or similar concepts, which is another very
complicated legal standard that in the US involves a four-part weighing
test and produces wildly different opinions about whether something is
fair use even among lawyers.
* Therefore, if you produce a patch for some piece of software and you do
not make any explicit statement about licensing of your copyright,
whether that patch can be used by other people is legally ambiguous
along multiple different axes and it's not uncommon for the correct if
unsatisfying answer to the question "can I use this patch," if asked
with legal rigor, to be "uh, hard to tell, the litigation would be
really annoying."
* In 99.999% of these situations, the actual value of the patch is low
enough, and the desires of the parties are sufficiently aligned, that
absolutely no one is going to engage in litigation, and therefore the
legal subtleties will never be tested and the *practical* answer to "can
I use this patch" is "sure, who's going to stop you?"
This situation annoys the crap out of people like me, and I would suspect
also many other people who were drawn to programming because it lets you
say things precisely, who believe in following rules and hate this sort of
practical ambiguity and would prefer to correctly nail down the details
because otherwise this feels like an unsatisfied mental open loop. It also
creates some real legal risk in the 0.001% of cases where someone might
actually sue someone else.
Unfortunately, legally, the way to avoid this ambiguity is to get a
copyright license or other legal agreement from the author of the patch.
If the patch turns out to not be copyrightable or your use is fair use,
there's no harm in having a copyright license, and if both of those turn
out to not be true according to some legal system, you have a license and
you're covered. Getting that agreement is a pain in the ass. You generally
have to do one of the following:
1. Have the person put an explicit license on the patch. Depending on the
license, this may require carrying around additional metadata with the
patch that's annoying and doesn't help the software work any better and
incurs ongoing overhead. There's also a bit of an open question about
whether the person submitting the patch is legally entitled to license
it that mostly people ignore but that may or may not be truly legally
safe to ignore.
2. Have the person sign some sort of legal agreement with you about their
patches. Most people hate this and, more practically, simply aren't
going to do it, and also now you have to be the legal agreement police
and double-check that everyone has signed and you have to worry about
different jurisdictions and a bunch of other nonsense.
3. Have the person include some sort of statement that essentially
formally agrees with the licensing of the patch without requiring a
specific license statement. This is roughly what the Linux Developer
Certificate of Origin is doing. This works legally (I assume, given
that the Linux Foundation has good lawyers) and is somewhat
lighter-weight than the other options, but some people object to it
because it arguably shifts liability to the submitter, and also again
people just won't do it unless you pester them.
The larger projects that face real legal threats and have corporations and
lawyers involved increasingly tend to do one of those three things. Nearly
every other free software project on earth, including, I suspect,
approximately 100% of Debian packaging, does none of these things.
What nearly every free software project does in practice is make an
assumption. That assumption goes roughly like this:
You voluntarily submitted your work to my project and asked for it to
be included, so I am going to assume that this means you agree to the
standard conventions of free software and are okay with your work
being included under the free software license that the work is
already covered by. Asking you to confirm this explicitly is annoying
and requires another back-and-forth, so I'm just going to assume we're
all adults here and you wouldn't have sent me the patch if you didn't
want me to use it.
This is not legally rigorous, but it's also not *entirely* void of legal
meaning either. There are a bunch of legal concepts sort of vaguely
floating around in this area that have names like "promissary estoppel"
that I am not even remotely qualified to analyze, but which roughly amount
to a general informal principle that people are entitled to assume that
you are a reasonable person and you mean what you are clearly implying. If
you try to sue someone for incorporating a patch that you sent them for
incorporation, it's not an unreasonable assumption that a judge is going
to ask questions like "if you didn't want them to use your patch, why did
you send it to them" and "if you didn't want your work covered under the
same license as the software you submitted it to, why didn't you say so"
and arrive at reasonable conclusions.
And, again, the simple reality is that in nearly every case the value of
the work is sufficiently low and the motives of everyone involved are
sufficiently aligned that no one is ever going to contemplate legal action
and therefore at some practical level it doesn't "really" matter. (The
problem, of course, is that this is true up until it's not, and there's
some risk of being unpleasantly surprised.)
I think what you're getting at is that, in practice, you are making this
reasonable assumption, just like nearly everyone else, but it's very
difficult to cast this reasonable assumption in the formal terms of the
debian/copyright file because it's not really a copyright license. It's an
assumption about the intentions of other parties, and in some cases you
may not even know who those parties are. They're just other participants
in an ecosystem with a certain set of shared default assumptions that
you're relying on.
I don't have a foolproof solution for you. I don't think there *is* a
foolproof solution other than CLAs or DCOs or some similar tool, which is
precisely why the projects with lawyers use those tools. If you want to be
formally correct, you have to have the formality, which includes all the
annoying and tedious overhead required to track the formality and pester
people to follow it.
What I can say is what I personally do, which I think is interestingly
different than what you are doing in ways that may produce a useful
discussion.
My position in all the projects I maintain, including Debian packaging, is
that I want to use the implicit community assumption and not require
formal statements because the last thing I need is to spend my scant and
precious free time doing tedious paperwork that's nearly always
meaningless. I therefore am going to lean into the community assumption,
but that means that I have an obligation to also align *my* behavior with
the rest of the community. If I plan on treating people's submissions in
the "expected" way, I also need to behave in the "expected" way myself.
Otherwise, my behavior is at the least unfair, and possibly undermines
whatever legal protection I get from assuming everyone involved is acting
in the normal way.
This means that I have an obligation to not do anything "surprising" that
would break this implicit social contract with submitters. In my
*personal* opinion, and other people can of course reach different
conclusions, that means the following:
1. My software should be clearly and straightforwardly licensed. Most
people expect the whole software package to be under a single license,
so do that where possible. If it's not possible for whatever reason,
all the exceptions should be clearly labeled.
2. I should assume that any contribution someone gives me is intended to
be covered by the same license as the file they're modifying is already
under, and not under some other license that would be more convenient
for me, unless I clarify this with them explicitly.
3. I should state the license of each file prominently at the top of the
file where practical to increase the chances that someone can see that
license, unless the default is really obvious (such as a package with a
LICENSE file at the top level and no exceptions).
4. I have a moral obligation to not take advantage of my reliance on this
implicit assumption to do something against the interests of the
submitter. So, for example, if my whole package is GPLv3 except for one
portion that is MIT-licensed and that I know is used in a non-free
work, and someone submits a patch to a bunch of GPLv3 code but also
non-trivial modifications to the MIT code, I feel some moral obligation
to confirm with them that they're okay with that part being
non-copyleft because that sort of split is surprising. The goal should
be to never surprise the submitter with how I used their code.
5. I use standard licenses, not some weird niche license that a
contributor may not be familiar with.
The practical effect of these personal rules for Debian packaging is that
I always release my Debian modifications to the upstream code (patches,
additional documentation, that sort of thing) under the same license as
the upstream package except for non-free upstreams, because to me that
follows the principle of least surprise. I then feel ethically comfortable
with relying on this implicit assumption of licensing of contributions,
because I am doing the "normal" thing that most free software contributors
expect: Everything related to a given piece of software is covered by the
same license, which is the obvious one declared at the top level or
prominently in the documentation.
For packaging files *that are not upstream modifications*, I think it's
actually hard to do something *that* surprising here. If the package is
GPLv3 and the packaging files are MIT, that follows a fairly typical
pattern of more generously licensing supporting files with (in most cases)
less creative work than the main software package. If the package is MIT
and the packaging files are GPLv3, well, you're allowed to relicense MIT
contributions under the GPLv3 so far as I can tell, so that's legally
allowed by the license even if you assume the contributor intended MIT
licensing. Either way, the chances that you're using someone's
contribution in a way that would make them unhappy is relatively low.
However! The chances that you will *mislabel* someone's contribution in a
way that makes them happy is higher! The labeling will probably have
no practical effect on how the contribution is *used*, but still, people
may well be unhappy having their MIT-licensed contributions labeled GPLv3
or vice versa.
Therefore, even in that case, I personally license the packaging under the
same terms as upstream because I am trying very hard to not be surprising.
Not surprising contributors is more important to me personally (by FAR)
than the precise details of licensing for work in situations, like Debian
packaging, where all of these licenses are going to be functionally
equivalent 99% of the time. That's just my personal opinion, of course,
and I can see lots of room for others to arrive at other conclusions.
In summary, personally I would align licensing between packaging and
upstream when choosing a license because I think it makes everything
simpler and more predictable, and when you are not getting legal
agreements from contributors, I think one is under some degree of moral
obligation to not do anything surprising. But I don't think it's some
great sin if you don't do that, *provided* that you do not do things that
cause surprising things to happen to the licensing of binaries produced by
upstream.
And, in answer to your *actual* question, I think trying to explain all of
these subtleties in debian/copyright is a lost cause and I am dubious you
will gain all that much from trying. I think my best suggestion is to say
that debian/patches/* is under the same license as the upstream code
because this will almost always be correct in practice. Certainly if
you're pulling those patches from upstream, that's a reasonable assumption
to make. If upstream code is under a bunch of different licenses and the
patches are therefore under a bunch of different licenses, I would
probably do something annoying like list all the possible licenses as a
conjunction (with "and") and then add a comment saying that each patch is
under the same license as the file it is patching. (Or write separate
license clauses for every patch, but gah.)
For the rest of the packaging files, I think you can do whatever you're
doing now, but I would personally encourage you, at least a little, to
consider aligning with upstream's licensing just on the grounds of
reducing community friction and avoiding unpleasantly surprising
contributors (and getting into extended and time-consuming discussions
like this one). I personally think those benefits outweigh whatever
relatively minor benefits you would get from choosing a personally
preferable license for Debian packaging files where the precise licensing
terms are unlikely to ever matter in practice. But this is just my
personal opinion and the advice is worth what you paid for it. :)
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
