License in new files

[Simo Sorce]

Hi Ellie,

On Wed, 2020-04-15 at 10:24 +1000, ellie timoney wrote:
> It's worth observing that the only reason we're even ABLE to consider
> moving away from the 4-clause BSD licence is because all copyrights
> from all contributors have historically been assigned to a single
> entity (CMU), who can then choose to transfer ownership or relicense
> if they desire.

Keep in mind that with a liberal license like the current one, you can
always move to a different overall license. Original contributions
won't be changed without owner's permission, but you can simply switch
to use a new license for any new contribution. The situation is not as
dire as it may seem. And it is not as complicated as changing the
license on a copyleft project where you have to change it all at once
or do nothing.

The 4th clause is annoying, and generally will probably be violated,
unintentionally of course, in most settings. So it is worth avoiding it
simply because it places an undue burden that is not reasonable in this
day and age where you may be using literally thousands of works in a
single piece of software delivered to a final user.

> If we had had a historical practice of letting individual
> contributors add their own copyright to individual contributions,
> even under the same 4-clause licence, this would require chasing
> approval dozens of individual copyright holders (who might not be
> contactable or might no longer exist), and it would probably never
> happen.
> 
> Whatever license we end up going with, and wherever the existing
> copyright assignment ends up landing (if it gets transferred), I
> kinda think we should maintain the same practice of requiring
> contributions to assign copyright to the single entity.

I hear this argument a lot lately, and I really do not buy it.

I have been historically quite adverse to CLAs (I had a talk at FOSDEM,
in the legal room, against them a few years ago, for example), and
Copyright assignment in general due to personal experiences.
It is a high barrier to entry and doesn't really give the benefit you
think except when you have a bad license to start with, OR you want to
have the ability to take the code private and shunt your community.

There are very successful projects that do not need CA as evidence,
these are not just my words.

For high visibility and well funded/marketed projects, people do jump
through hoops in order to participate. But I have been in lower key
projects were contributors simply walked away because it was too hard
for them to obtain any sort of legal approval for (C) transfer/CLA
signing, or it was simply too much of a pain to do so.

Using an inbound/outbound process is generally much better suited for
drive-by contributions like cyrus-sasl generally receives.

I suggest you read this link if you want the perspective of a lawyer:
https://opensource.com/article/19/2/cla-problems

> I'm not a lawyer, and I don't pay a lot of attention to the minutiae
> of open source project licensing (because I don't have to, because
> it's all assigned to CMU and all using the same licence!).  There's
> probably good examples out there of big projects that allow
> individual copyrights.  But the other factor to think about is -- do
> we have the resources to manage the administrative overhead
> introduced by such a scheme?  My gut feel says no: including both
> regular cyrus-imap and cyrus-sasl contributors, we're what, a dozen
> people tops?

Exactly, CLAs or Copyright assignment cause a ton of overhead.
A license that does not make one entity "more important" than the other
contributors (like the current license somewhat does in clause 4) is a
much smoother ride. Sure you have multiple (C) ownership, but it is a
liberal license, so in general there will be no problem at all.

> I think it would be naive to assume we're never going to need to
> relicense ever again (after all, 4-clause BSD seemed like a good idea
> once upon a time), so let's not make things hard on our future
> selves.

It *may* happen, but it is also a very rare thing, does it make sense
to optimize for once-in-a-lifetime events? Or is it better to optimize
for lowest overhead all the time and leave a little pain concentrated
in one event if and when it happens?

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc