
Theo de Raadt on LLVM license change - protomyth
https://marc.info/?l=openbsd-misc&m=147503691302850&w=2
======
DannyBee
I'm not sure why anyone thinks there will not be a real license change
process. There will. This is just the stage of settling the question of what
the license should be. Everyone is quite aware of the work it will take to
actually change the license (I've managed the process for a number of large
projects before) and random commentary from Theo that it will just be
unilaterally changed is simply wrong.

Chris's email even says this " Once we reach an agreement on the path to take,
we can start talking about logistics of how to get there."

As for the corporate wannabes comment, the truth is that folks have gone out
of their way to talk to both users and contributors, at the developer
conference and elsewhere (and in fact, we've spent a year trying to come up
with licensing solutions to ensure we don't cause problems for various one off
users, whereas most projects who have relicensed usually just told them tough
luck).

Past that, I'll be honest:I'm pretty uninterested in what a bunch of random
people on an unrelated mailing list, who don't participate in the community at
all, want to think. Especially when they have pretty much no data and have
never bothered to simply ask questions on the llvm mailing list in the thread
(or at the developer conference, or...), like others did. If they have real
concerns, they are welcome to raise them in any of the normal ways.

------
robert_tweed
Reproducing the text because the site is under too much load and Coral Cache
can't resolve it:

    
    
      List:       openbsd-misc
      Subject:    Re: LLVM license change
      From:       "Theo de Raadt" <deraadt () openbsd ! org>
      Date:       2016-09-28 4:27:44
      Message-ID: 91077.1475036864 () cvs ! openbsd ! org
      [Download message RAW]
    
      > And that is because corporate "contributor-wannabes" put pressure on the
      > LLVM foundation.
      > http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
      > 
      > It does say "this is an RFC" but that was last year. We are now in this
      > year:
      > http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
      > 
      > What I particularly do not like is the "IANAL but let's do it anyway"
      > drift emanating from a lot of high profile developers there.
    
      Well, I hope they do it.
    
      And then -- I hope a year or two later, some author of a component
      (especially one from Europe where the moral rights of an author still
      carries substantial weight) submarines the new licence, surfacing to
      indicate that they never signed off on the additional terms applied to
      them as a significant author, and will accept no cash to solve the
      problem.
    
      Then they are dead in the water.
    
      A cataclysm like CSRG went through.
    
      Then a fork of code on the original license can flourish.  A fork
      based upon the last free version -- but let's remember that is the
      history of another piece of important software...
    
      So this problem could be fixed, if enough people care.
    
      In this situation, I suspect a few people are being paid a lot of
      wages to act as agents permitting theft from their co-contributors.
      They worked with others but now they are ready to steal from them.  A
      list of all contributers (and every single one of them must agree) has
      not been published, so it is really likely this is a well-financed
      effort being performed by paralegals.  Meanwhile day by day that list
      of contributors operating under the existing model is growing..
    
      Someone is hoping they can get away with copyright theft.
    
      Want to have fun?  Submit a major diff, which (seperately) in the
      submission says you'll never agree.  Eventually most large projects
      find their inner Xfree86, I'm afraid to say.

~~~
refulgentis
Painting the situation as "corporate contributer-wannabes" and "IANAL but
let's do it anyway" is loaded language that seems intended to bring up
negative tropes. The first is sneering at the host of potential contributors,
because the host is willing to pay the salary of the contributors. The second
is not remotely backed up by the facts.

They've hired lawyers, and consulted the community. The community's
predominant concern was whether the new license (Apache2) would be compatible
with GPLv2.

In the "We are now in this year" link, it's explicated how they consulted a
gaggle of open source lawyers, determined the predominant belief was the new
license was compatible with GPLv2. But they didn't stop there – they had a
lawyer draft an addendum to really ensure that!

Not a good look. Fever swamp paranoia, and wishing ill on a series of people
clearly trying to do well and address every concern.

~~~
protomyth
> Painting the situation as "corporate contributer-wannabes" and "IANAL but
> let's do it anyway" is loaded language that seems intended to bring up
> negative tropes.

Theo de Raadt said neither phrase.

~~~
karlshea
I think everybody here knows what ">" means.

~~~
notaplumber
Except for refulgentis, apparently.

~~~
karlshea
I don't see where refulgentis claims Theo did. Clearly, those are quotes from
the person Theo is replying to.

Theo seems to agree with that person though, and "wishing ill on a series of
people clearly trying to do well" certainly could apply to both parties in the
email.

------
d33
A bit of reminder on who Theo is:

> Theo de Raadt (/ˈθiː.oʊ dɛˈrɔːt/; Dutch: [ˈteː.o dɛˈraːt]; born May 19,
> 1968) is a software engineer who lives in Calgary, Alberta, Canada. He is
> the founder and leader of the OpenBSD and OpenSSH projects, and was also a
> founding member of the NetBSD project.

~~~
dleslie
Living in Canada allowed him to avoid the USA's onerous export restrictions on
strong encryption; at a time when good, consumer-accessable encryption was
expensive and patent-encumbered. The 'net is secure in no small part to his
efforts and that of the rest of the OpenBSD team.

~~~
nickpsecurity
You mean DJB, Zimmerman, and others fighting the governments to change the
status quo encryption policy followed by deployment of higher-quality stuff
than average proprietary in FreeBSD and Linux that got widely adopted by most
of the Internet? Nobody has ever showed me evidence that Theo or OpenBSD had
any impact on the security of the Internet as a whole. Maybe on specific users
of OpenBSD or the developers' higher-quality software. Not the big picture,
though.

I'm open to specific examples if you have them of widespread changes in
INFOSEC or massive adoption of better tech due to Theo de Raadt.

EDIT: I'm aware of many good apps they've made. To clarify, my comment is
addressing this broad claim:

"The 'net is secure in no small part to his efforts and that of the rest of
the OpenBSD team."

OpenSSH might get credit due to massive use. Good example. Past that, what
else does most of the net on client side (mainly Windows & Mac) or server-side
(mainly Win, FreeBSD, and Linux) depend on from OpenBSD developers?

~~~
pyvpx
Androids libc?

~~~
nickpsecurity
OpenBSD team made that? You got a link?

~~~
Sanddancer
Google used bits and pieces of various BSD libcs in bionic. It's not
definitive, but wiki has a list.
[https://en.m.wikipedia.org/wiki/Bionic_(software)](https://en.m.wikipedia.org/wiki/Bionic_\(software\))

------
freedomtaco
Theo's right of course.

Paradoxically, projects on github flourish because contributors and users by
in large ignore the licenses. Granted, licenses are extremely important to
protect intellectual property but nothing kills contributions to open source
more than bureaucracy.

~~~
tingol
What makes you think of all the things ignoring the licenses (citation needed)
is the one that made github flourish?

~~~
freedomtaco
I won't bother contributing to a project if I have to jump through hoops. The
Github ecosystem removes these hoops. The license is a secondary concern for
in-house software.

~~~
tingol
I still don't see what you mean by this. All of the top projects on github
have pretty clear licenses which are automatically accepted by you (the
contributor).

In fact if you choose not to specify a license your work counts as copyrighted
(as per github licensing documentation). So Github doesn't really remove any
"hoops".

------
FiloSottile
All the comments here seem to focus on Theo, the Apache license vs. the BSD
one, and for some reason the OpenBSD policy.

But my understanding of that email is about the irregularity of a unilateral
change of license. The contributors own their work and licensed it under one
license, and the project wants to change it without doing the Herculean job of
getting permission from all.

I think Theo is correct there saying that there is a risk that one of those
contributors will then come out of the woods and wreak havoc, risking a forced
fork from the relicense point.

IANAL, but "you don't change the license" is one of the few things I was
taught.

~~~
drewcrawford
Both of the licenses used in LLVM contain the following clause:

> Permission is hereby granted... to deal with the Software without
> restriction, including... the rights to... sublicense

The effect of this clause is that all LLVM contributors have already consented
to a chance in license, whether that change is done by you, me, Debian, or the
Pope.

The only question is whether the LLVM organization wishes to exercise this
authority itself. It's clear that the majority of the key contributors are in
favor of it, so it seems like a foregone conclusion at this point.

~~~
johncolanduoni
The whole reason that this license change is coming up is that some people in
the project (and I assume Apple as well) want to provide some level of
protection from patent infringement cases for the users of LLVM. The ability
to sublicense doesn't help here because the patent clause in the Apache 2.0
license would only apply to the patents owned by you, the one who is doing the
sub-licensing. They want these protections to apply to the patents of any of
the authors of LLVM, which of course cannot be done without their consent.

~~~
drewcrawford
There is debate about to what extent patent protection is already extant in
the current licenses. One example, the MIT has

> to deal in the Software without restriction, including without limitation
> the rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or sell copies of the Software

The word "patent" does not appear here, but the words "use" and "distribute"
seem to imply the granting of rights necessary to achieve those ends (of which
a limited patent license would be one), and the phrase "deal in the software
without restriction" is a statement so broad that it seems difficult to argue
a patent license (and perhaps many future IP innovations unknown to us today)
was not granted by the rules of equitable estoppel.

The reason for this license change is to resolve the ambiguity that arises
because the word "patent" does not appear as a word in this clause. It was
found that the GPLv2 did not grant patent rights because it was not mentioned
in that license [0], although the circumstances of that case and the text of
the MIT are far apart.

As a result of all this LLVM may go around and get people to sign off on the
Apache grant but it is likely to be under the banner of "clarifying" an
implied patent grant rather than establishing a new one. Depending on how
worried the lawyers are about the legal meaning of "deal in the Software
without restriction" they may not be worried about the contributors they are
unable to track down.

[0] See
[https://www.fenwick.com/FenwickDocuments/potential_defenses....](https://www.fenwick.com/FenwickDocuments/potential_defenses.pdf)
for an analysis of the GPLv2 situation

~~~
johncolanduoni
You're correct, I should have said better patent protection, not patent
protection at all.

------
StreamBright
Could somebody tl;dr me what is going on with LLVM and why the new licensing
would be bad according to Theo?

~~~
lambda
LLVM wants to switch from a BSD-style license to Apache 2.0, with a few
exceptions, one allowing use with GPLv2 code, another allowing the bits of
compiler-rt and other components that get built into binaries to be
redistributed without restriction.

The main benefit of Apache 2.0 is that it includes a patent grant as well.
Right now, LLVM relies on a custom "developer agreement" for anyone who
contributes code that includes a grant of patent rights, but it's kind of
vague and fuzzy and so makes it hard for some people to contribute, and the
license itself doesn't actually mention patents at all:

[http://lists.llvm.org/pipermail/llvm-
dev/2015-October/091536...](http://lists.llvm.org/pipermail/llvm-
dev/2015-October/091536.html)

Theo objects to any license that applies more restrictions than the original
BSD license. OpenBSD makes an exception for GPLv2 licensed utilities that have
been traditionally shipped with BSDs that there's not a good replacement for,
but has stopped upgrading things that have moved to GPLv3 and apparently
objects to the Apache license as well.

~~~
saurik
The existing patent agreements seem to make the current license not comparable
BSD but instead comparable to an awkward or even apparently extreme Apache
2.0, so isn't this about in practice removing restrictions, not adding
restrictions? (This thought process is backed up by their stated reasoning and
the kinds of contributors that are supposedly complaining.)

~~~
drewcrawford
"Additional restrictions" can be funny. You may recall the FSF's position that
the app store EULA placed "additional restrictions" on the GPL, a position
that was and remains controversial.

In this case, it is a little harder to understand OpenBSD's interpretation of
additional restrictions because they haven't listed their objections in any
centralized place, but from reading around, they seem to believe:

* "You must cause any modified files to carry prominent notices stating that You changed the files" is an additional restriction * "any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License" is an additional restriction * The sheer length and complexity of the Apache license suggests to them there are other additional restrictions buried in there somewhere

~~~
cyphar
> You may recall the FSF's position that the app store EULA placed "additional
> restrictions" on the GPL, a position that was and remains controversial.

I don't think that the position was contraversial, I just think that people
took it the wrong way. The Apple EULA _objectively_ has clauses in it that
state that users must follow the "acceptable usage policy" and it is enforced
regardless of any external agreements -- this would mean that Apple would be
violating the GPL if they distribute any GPL software in their store.

You can add additional terms that permit distribution in the Apple store (as
Signal has done), but the stock GPL does not permit distribution in the Apple
store because the "acceptable use policy" is one of the things the GPL was
made to fight against (the idea that users must act in an "acceptable" way to
Apple when running software on their own computing devices).

~~~
drewcrawford
> The Apple EULA _objectively_ has clauses in it that state that users must
> follow the "acceptable usage policy" and it is enforced regardless of any
> external agreements -- this would mean that Apple would be violating the GPL
> if they distribute any GPL software in their store.

And Red Hat EULA _objectively_ has clauses in it that you may not redistribute
RHEL.

There is a slippery slope here, the FSF has decided for whatever reason that
RHEL's restrictions "weren’t really restrictive, because they were so easy to
comply with" [0] but there is really nothing "objective" about that
determination.

[0] [https://www.gnu.org/licenses/quick-guide-
gplv3.html](https://www.gnu.org/licenses/quick-guide-gplv3.html)

~~~
cyphar
You're being a tad disingenuous here. RHEL's EULA[1] is basically the same as
SLE's, openSUSE's, Ubuntu's and so on. It only states that you are not allowed
to use the RedHat trademarks when you redistribute RHEL -- and since RHEL (and
the other distributions I mentioned) puts all of their trademarked components
in a single "branding" package then it is not _practically restrictive_ to
make such a requirement. RHEL has no requirement that you cannot distribute
some software (in fact, the distribution is under GPLv2 much like openSUSE and
SLE).

Apple's EULA restricts users to only being able to use software they
distribute under their "acceptable use policy". This is simply a violation of
the GPL, with no wiggle room for discussion.

[1]: [https://www.redhat.com/en/about/red-hat-end-user-license-
agr...](https://www.redhat.com/en/about/red-hat-end-user-license-agreements)

------
johncolanduoni
I'm confused. The post he's responding to is just saying that they want to
move to the Apache 2.0 license if possible. Chris certainly doesn't seem to be
assuming they can just flick a switch and make it happen, considering he talks
about "logistics" and is pretty clear it is still in the discussion stage.

Is it a dick move just to ask the contributors if they're willing to provide
the code under the Apache 2.0 license so people can use LLVM without worrying
about being sued for patent infringement? This looks to me like Apple and
other corporate contributors with large patent portfolios giving users without
such bargaining chips some protections from litigation.

I find it hard to see that as a bad thing, unless they were in fact deciding
to pretend they own the copyright of the whole project and dare contributors
to sue them. Thus far I see no evidence of that.

------
kod
Theo deRaadt complaining about "copyright theft" is hilarious given his
original stance on the ipfilter debacle.

~~~
mrweasel
I might very well be wrong, but I believed that the licensing of the IPFilter
code, and the clarification of the attached license was part of the reason
that OpenBSD, and Theo, is so much against complex licenses.

While better than the GPL, version 2 and 3, in the sense that it's shorter,
the Apache 2 license is still much more complex than the ISC or the BSD/MIT
licenses. Another part of the issue, for some developers at least, is that the
Apache 2 license sort of acknowledges that software patents are a thing. So if
you disagree that companies should be allowed to patent software, mathematics
and processes, you might not pick a license that validates the existence of
those patents.

~~~
icebraining
_So if you disagree that companies should be allowed to patent software,
mathematics and processes, you might not pick a license that validates the
existence of those patents._

This sounds absurd to me. Software patents don't go away because one stops
believing in them. Either the courts enforce them or not.

~~~
fungos
Sure, but I see the idea as a kind of boycott/protest. I disagree with
patents, mainly software patents, consequently I will never use a license that
consider patents.

~~~
cyphar
That's not how laws work. At all. Even the GPLv3 (authored by one of the
biggest activists against software patents) has clauses relating to software
patents -- because they are a legitimate threat to software freedom and need
to be addressed. Just because you don't like patents doesn't make the problem
go away -- in fact by ignoring it you're making the problem _worse_ because
then your code's license has no protection for your users.

------
notaplumber
OpenBSD's been around for a long time, it would be unwise to dismiss these
concerns, especially considering they've demonstrated this has happened
before.

LLVM/clang was recently imported into OpenBSD and is being brought into shape
to potentially replace GCC, having OpenBSD developers eyes on a codebase has
also historically been a good thing.. I think a future without their input
will be bleak.

------
Someone
[http://llvm.org/docs/DeveloperPolicy.html#copyright](http://llvm.org/docs/DeveloperPolicy.html#copyright):

 _" The LLVM project does not require copyright assignments, which means that
the copyright for the code in the project is held by its respective
contributors who have each agreed to release their contributed code under the
terms of the LLVM License.

An implication of this is that the LLVM license is unlikely to ever change:
changing it would require tracking down all the contributors to LLVM and
getting them to agree that a license change is acceptable for their
contribution. Since there are no plans to change the license, this is not a
cause for concern.

As a contributor to the project, this means that you (or your company) retain
ownership of the code you contribute, that it cannot be used in a way that
contradicts the license (which is a liberal BSD-style license), and that the
license for your contributions won’t change without your approval in the
future."_

OOPS.

~~~
JoshTriplett
The LLVM license (the UofI/NCSA license) is permissive, and thus compatible
with just about everything, including the Apache 2.0 license. All the existing
code can stay under the old license unless someone agrees to the new one. New
contributions can go under the new license. The _effective_ license of the
codebase will become Apache 2.0, with some pieces still available under the
previous permissive license.

~~~
notaplumber
This is considered a _dick move_ for a project to make, often this means any
non-trivial changes to existing code will be under the more restrictive
licence, with no backward compatibility, preventing such changes from being
incorporated by the original authors or anyone perusing a fork of the
originally permissive codebase.

A common example of this kind of behaviour is GPL proponents forking BSD or
other similiarly licensed software, and exclusively wrapping their
contributions to it under the GPLv3.

~~~
cyphar
> A common example of this kind of behaviour is GPL proponents forking BSD or
> other similiarly licensed software, and exclusively wrapping their
> contributions to it under the GPLv3.

A _much_ more common example is a proprietary software vendor taking a lax
licensed project and creating a proprietary fork of it. Of course, BSD
proponents don't mention the _far more common_ case (because it wouldn't help
the narrative that GPL proponents only spend their time relicensing code).

Why you don't have a problem with proprietary forks but do have a problem with
copyleft forks is beyond me. Especially since sometimes copyleft forks are
created because the developers made so many changes that it stands in its own
right as a separate project (and the developers feel that user freedom trumps
upstreamability).

~~~
notaplumber
The proprietary "forks" are often not distributed as source, they're either
internal forks, or simply part of a larger product. The difference is that
proprietary forks of permissive code is often kept in sync with upstream and
you only ever learn of its existence when they decide to contribute back
patches. They typically have the courtesy of making those available under the
original license terms for everyone to benefit from.

~~~
icebraining
Internal forks are not subject to the GPL requirements anyway, so that can't
be an argument against it.

~~~
cyphar
In fact, licenses that do not permit private copies of the modified software
are not considered free software according to the FSF[1] (which I agree with).

[1]: [https://www.gnu.org/licenses/license-
list.en.html#NonFreeSof...](https://www.gnu.org/licenses/license-
list.en.html#NonFreeSoftwareLicenses)

------
Keyframe
Is dual license a possibility?

~~~
petertodd
Not really.

The anti-patent protections Apache provides don't work if the patent holder
has the option to use the license without those protections instead. I believe
this is why it's common for projects to dual-license under Apache and GPLv3 -
both licenses have anti-patent provisions.

~~~
eridius
But it's not the patent holder that uses the license at all. It's the
downstream user. Any downstream user would be protected by the patent clause
as long as they're using the Apache 2.0 license regardless of what the patent
holder wishes.

~~~
petertodd
Hmm. That's a good point; I've probably misunderstood that. Thanks! I'll do
some more research.

------
maxlybbert
It's common for open source projects to change licenses. To be honest, I'm
pretty sure that most projects have set the bar much higher than it legally
is. In other words, I think de Raadt's fantasy isn't going to happen, and if
it did, the fallout would likely be that many projects would lose the ability
to enforce their licenses.

Usually, when a project changes its license, it either tries to get permission
from each contributor; or it makes an announcement that if any contributor
objects, they will remove that person's contributions on request. But US law
doesn't actually require that. In the US (
[http://copyright.universityofcalifornia.edu/ownership/joint-...](http://copyright.universityofcalifornia.edu/ownership/joint-
works.html) ):

"Each joint author has the right to exercise any or all of the exclusive
rights inherent in the joint work. Each author may:

"• Grant third parties permission to use the work on a nonexclusive basis
without the consent of other joint authors

"• Transfer his or her entire ownership interest to another person without the
other joint authors' consent".

In other words, unless you have some kind of enforceable agreement between all
contributors, _any_ _contributor_ can relicense the work, without the consent
of the other contributors. I'm not sure whether the GPL qualifies as the kind
of agreement that could prevent this; the FSF has spent years saying the GPL
doesn't meet all the standard requirements of a contract because it doesn't
need to be a contract. The FSF famously requires contributors to transfer
their copyright interest to the FSF because Stallman says an attorney told him
that makes it easier to enforce the GPL. Or, as Eben Moglen says (
[https://www.gnu.org/licenses/why-
assign.en.html](https://www.gnu.org/licenses/why-assign.en.html) ):

"If there are multiple authors of a copyrighted work, successful enforcement
depends on having the cooperation of all authors.

"... [I]n order to be able to enforce the GPL most effectively, FSF requires
that each author of code incorporated in FSF projects provide a copyright
assignment, and, where appropriate, a disclaimer of any work-for-hire
ownership claims by the programmer's employer."

Many open source licenses other than the GPL don't have any chance of
qualifying as the kind of agreement that could prevent a single contributor
from relicensing the project on a whim.

Also note that "contributor" doesn't necessarily mean to "contributor to the
parent project." I haven't been able to find any legal reason somebody can't
fork a project (following the license), make enough changes to become a joint
copyright owner as far as their fork is concerned, and then relicense the
fork. I guess the original contributors would also be joint copyright holders
as far as the fork is concerned, and could relicense the fork as well. I'm not
sure where that would end; and I'm glad that so far nobody's been creative
enough to start such a battle.

So, back to LLVM: Apple is, without question, a joint copyright holder and can
relicense the code as desired. De Raadt's idea is that a European could say
"well, the relicensing was OK under US law, but not under European law." But I
don't see how moral rights would prevent relicensing. The Berne Convention
establishes moral rights as (
[https://en.wikipedia.org/wiki/Moral_rights](https://en.wikipedia.org/wiki/Moral_rights)
):

"Independent of the author's economic rights, and even after the transfer of
the said rights, the author shall have the right to claim authorship of the
work and to object to any distortion, modification of, or other derogatory
action in relation to the said work, which would be prejudicial to the
author's honor or reputation."

Note, (1) that is "independent of an author's economic rights" and (2) the
contributor has the ability to object to any modification, mutilation,
distortion, etc., _of_ _the_ _work_ ; not of the terms the work is distributed
under. Countries can establish their own idea of moral rights, but I'm pretty
sure they will follow the Berne Convention's definition pretty closely.

So I would predict the outcome would be a court opinion that any contributor
has the right to change the license, and that moral rights aren't the right
tool to stop a relicensing. And if anybody can fork, become a contributor in
the fork, and relicense the fork, I don't see how anyone can enforce any
license restrictions.

~~~
throwaway76543
"I would predict the outcome would be a court opinion that any contributor has
the right to change the license"

You think Microsoft, who has put tens of thousands of lines into Linux, has a
right to change the license of Linux away from GPL? Is that really what you're
positing?

~~~
maxlybbert
I'm saying that I don't see a legal obstacle to Microsoft doing that. There
are other potential obstacles, such as reputation damage.

So far, open source projects act like copyright either requires unanimous
agreement among the copyright owners to make changes, or each contributor has
copyright only in their specific contribution (so, in practice, you need
unanimous agreement). That's simply wrong for joint works, and joint works are
defined as works meant to be combined together to make one work (the
alternative being a collective work, where the parts are simply combined into
a collection, does follow the "each contributor has copyright in just their
contribution" model).

Copyright law is based on certain assumptions, like "if the co-authors get
into an argument, it will be about how to divvy up royalties, and there will
be a contract involved." Another is "co-authors work together at the same
time, and know each other." Those assumptions are wrong for open source
projects.

~~~
ori_b
You're wrong. Absolutely, undeniably, wrong.

A party simply can't change the license for code that they did not write. They
can only change the license for their own work.

~~~
maxlybbert
A party can become a joint author, and then they can change the license on the
entire work. The part "joint copyright holders can distribute the entire work
under any conditions they feel like, even without agreement from any other
joint copyright owner" is well established. You may not believe me, but it is
the law (I already linked to the University of California, and Eben Motown's
statement that to enforce a licence you need the cooperation of each copyright
holder, acknowledging that a single dissenting copyright holder can kill an
enforcement action; but here's a link to Stanford:
[http://fairuse.stanford.edu/overview/faqs/copyright-
ownershi...](http://fairuse.stanford.edu/overview/faqs/copyright-
ownership/#who_owns_the_copyright_in_a_joint_work)).

The FSF avoids this problem by requiring copyright assignment. To be honest,
I'm not sure that's enough, but I think they're hoping for a sympathetic
judge. Most projects have never looked at what the law actually says regarding
joint work, and think it works the way they would write the law. I know what
the outcome of that will be.

~~~
cyphar
I don't think that your claim has been tested in court when it comes to code.
This might be true for some kind of music or something, but I find it hard to
believe that a court would agree that two people who have never met and have
only communicated over the internet would have formed an implict contract
allowing relicensing of a work several orders of magnitude larger than the
contribution of the relicenser.

It's like claiming that someone shouting outside of a recording studio has the
right to relicense the music created inside the recording studio. While it
might be true, I'd want to see an actual legal case before claiming things
that are that outlandish.

Not to mention that the GPL has been tested in court and has held. So there's
that.

~~~
maxlybbert
It's not a question about contract. It's about how joint copyright works.

I know what the arguments would be, but I'm not sure how the court would rule.
The hypothetical depends on legally making a fork, and the GPL (as an example)
only gives permission to fork if you agree that any distribution will be under
the terms of the GPL. If you violate those terms, you've committed copyright
infringement. But can a joint copyright owner be guilty of infringing his own
work?

I remember Eric Raymond discussing a commercial copyright infringement case
where a contractor was hired to update a program, and started distributing the
updated program without permission. This was his argument.

However, he hadn't made significant changes to the program. Using your words,
the program was several orders of magnitude larger than what the contractor
added. The court got creative, and declared the contractor only had a
collective copyright -- like somebody who has copyright on a single article in
an encyclopedia -- and not a joint copyright -- even though his changes were
meant to be combined with the original work to create a single work and not a
collection of works. A collective copyright owner only has copyright in his
contribution.

You are right that courts would be reluctant to allow the tail to wag the dog,
but there is some threshold where the contributor has made enough changes that
he has joint copyright, and at that point he can do what the law says a joint
copyright holder can do.

------
Koshkin
Everybody enjoys free (as in "freedom") software. Turns out, even quality-wise
free software is often much better than non-free, closed-source software. On
the other hand, it may be hard to really understand the rationale behind it.
The idea goes against the principles of capitalism (based on property rights).
Also, if it is completely OK for hardware design to be proprietary, why should
it not be OK for software? What is so special about it? The arguments put
forward by proponents of free software do not seem very convincing, and
sometimes their personalities do not help attracting people to their cause.
Often, this ideal becomes a nuisance even in the world of open source. If you
want to use Debian, for instance, you are pretty much forced to use "non-free"
repositories (or a "non-free" Debian re-distribution) for your setup to be
useful.

~~~
rubber_duck
>Turns out, even quality-wise free software is often much better than non-
free, closed-source software.

This is only true in the very narrow segment of 'tools for geeks by geeks',
'tools that big software companies need but don't provide a competitive
edge/need to be OSS for adoption so they opensource' (Apple, Google,
Microsoft) and companies that sell support for OSS (RedHat, Novell, Canonical,
etc.)

As soon as you move from IT infrastructure/dev tools there is no contest
between OSS and commercial packages or they only cover small a niche. Compare
GIMP vs Photoshop, Blender vs Maya/3DSMax/ZBrush, Cycles/Yafaray vs
VRay/Renderman/Lux, OSS CAD tools, LibreOffice vs Office, etc. They aren't in
the same league most of the time in both quality and functionality supported.

~~~
cyphar
The point of the free software movement is not quality, it's user freedom.
Would you prefer having an electronic heart implant that is proprietary and is
"totally safe trust me", or is free software but isn't the best thing in the
world to interface with. I know which I'd pick, and the same logic applies to
everything else I rely on in my daily life.

~~~
rubber_duck
The parent comment was making a statement about quality to which I responded.

And if the proprietary software has been an industry standard and deployed in
millions of cases before I would have no problem taking the closed source
variant. It would be nice to have the source but in most cases I wouldn't know
what to do with it anyway as it requires specialist knowledge, so I'd be
relying on the community vetting it vs. legal requirements for approval by the
regulatory agencies, I mean it would still be better to have the source but I
could live without it.

Anyway my point isn't even related to preference, I'm just saying that the
conditions for successful OSS software are limited to one of the models under
which it makes sense commercially for the companies using it (most often IT
giants), some sort of commercial support/free software deal or in rare cases
it's a labor of love for geeks. Most of the software written out there doesn't
fall nicely in to those categories and so OSS is not viable in those areas.

