Newsgroups: fa.linux.kernel
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Proposed ACPI Licensing change
Original-Message-ID: <astkea$6ej$1@penguin.transmeta.com>
Date: Sat, 7 Dec 2002 20:09:21 GMT
Message-ID: <fa.jql04iv.e283i4@ifi.uio.no>

In article <20021207002405.GR2544@fs.tum.de>,
Adrian Bunk  <bunk@fs.tum.de> wrote:
>
>You can't forbid people to send GPL-only patches, so if a person doesn't
>want his patch under your looser license you can't enforce that he also
>releases it under your looser license.

That's true, but on the other hand we've had these dual-license things
before (PCMCIA has been mentioned, but we've had reiserfs and a number
of drivers like aic7xxx too), and I don't think I've _ever_ gotten a
patch submission that disallowed the dual license.

In fact, I don't think I'd even merge a patch where the submitter tried
to limit dual-license code to a simgle license (it might happen with
some non-maintained stuff where the original source of the dual license
is gone, but if somebody tried to send me an ACPI patch that said "this
is GPL only", then I just wouldn't take it).

I suspect the same "refuse to accept license limiting patches" would be
true of most kernel maintainers.  At least to me a choice of license by
the _original_ author is a hell of a lot more important than the
technical legality of then limiting it to just one license.

So yes, dual-license code can become GPL-only, but not in _my_ tree.

Somebody else can go off and make their own GPL-only additions, and
quite frankly I would find it so morally offensive to ignore the intent
of the original author that I wouldn't take the code even if it was an
improvement (and I've found that people who are narrow-minded about
licenses are narrow-minded about other things too, so I doubt it _would_
be an improvement).

		Linus

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Wasting our Freedom
Date: Sun, 16 Sep 2007 20:34:13 UTC
Message-ID: <fa.Z+pAoltjVUZf9GK/n87J/IJc7HM@ifi.uio.no>

On Sun, Sep 16, 2007 at 02:17:53AM -0700, J.C. Roberts wrote:
> Look at what you are saying from a different perspective. Let's say
> someone took the linux kernel source from the official repository,
> removed the GPL license and dedicated the work to public domain or put
> it under any other license, and for kicks back-dated the files so they
> are older than the originals. Then they took this illegal license
> removal copy of your code and put it in a public repository somewhere.

Ok, suppose someone did (precisely) this.  Then the person to be upset
with would be the people who did this, not the people behind the
official repository.  Some folks seem to be unfortuntaely blaming the
people who run the official repository.

Look, it's perhaps a little understandable that people in the *BSD
world might not understand that the Linux development community is
huge, and not understand that the people who work on madwifi.org, the
core kernel community, and the FSF, are distinct, and while they might
interact with each other, one part of the community can't dictate what
another part of the community does.  You wouldn't want us to conflate
all of the security faults of say, NetBSD with OpenBSD, just because
it came from a historically similar code base and "besides all you
*BSD folks are all the same --- if you don't want a bad reputation,
why don't you police yourselves"?  Would you not say this is
unreasonable?  If so, would you kindly not do the same thing to the
Linux community?

Secondly, it looks like people are getting worked up about two
different things, and in some cases it looks like the two things are
getting conflated.  The first thing is a screw-up about attribution
and removal of the BSD license text, and that is one where the SFLC
has already issued advice that this is bad ju-ju, and that the BSD
license text must remain intact.

The second case which seems to get people upset is that there are
people who are taking BSD code, and/or GPL/BSD dual licensed code, and
adding code additions/improvements/changes under a GPL-only license.
This is very clearly legal, just as it is clearly legal for NetApp to
take the entire BSD code base, add proprietary changes to run on their
hardware and to add a proprietary, patent-encrusted WAFL filesystem,
and create a codebase which is no longer available to the BSD
development community.

The first case was clearly a legal foul, whereas the second case is
legally O.K (whether the GPL or NetApp proprietary license is
involved).  However, people are conflating these two cases, and using
words like "theft" and "copyright malpractice", without being clear
which case they are talking about.  If we grant that the first is bad,
and is being rectified before it gets merged into the mainline kernel,
can we please drop this?  If you are truely offended that working
pre-merge copies of the files with the incorrect copyright statements
still exist on the web, feel free to send requests to madwifi.org, the
Wayback Archive, and everywhere else to stamp them out --- but can you
please leave the Linux Kernel Mailing List out of it, please?

As far as the second case is concerned, while it is clearly _legally_
OK, there is a question whether it is _morally_ a good idea.  And this
is where a number of poeple in the Linux camp are likely to accuse the
*BSD people who are making a huge amount of fuss of being hypocrites.
After all, most BSD people talk about how they are *proud* that
companies like NetApp can take the BSD code base, and make
improvements, and it's OK that those improvements never make it back
to the BSD code base.  In fact, these same *BSD folks talk about how
this makes the BSD license "more free" than the GPL.

Yet, when some people want to take BSD code (and let's assume that
proper attributions and copyright statements are retained, just as
I'll assume that NetApp also preserved the same copyright statements
and attributions), and make improvements that are under the GPL, at
least some *BSD developers are rising up and claiming "theft"!  Um,
hello?  Why is it OK for NetApp to do it, and not for some Linux
wireless developers to do precisely the same thing?  Is it because the
GPL license is open source?  At least that way you can see the
improvements (many of them would have been OS-specific anyway, since
the BSD and Linux kernel infrastructures are fundamentally different),
and then reimplement yourself ---- in the case of NetApp, you don't
even get to **see** the sources to the WAFL filesystem; they are,
after all, under a proprietary copyright license.

The final argument that could be made is the practical one; that
regardless of whether or not a Linux wireless developer has any legal
or moral right to do what NetApp developers have done years ago, that
it would be better to cooperate.  That's a judgement call, and I'll
assume that the BSD wireless developers are different from the people
who are screaming and trolling on the kernel mailing list --- since if
there is any overlap between the whiners and kvetchers who have been
invading the LKML, it would seem pretty clear that cooperating with
such a bunch lusers is probably more trouble than it's worth.  But
just as it's not fair to judge Linux developers by the more immature
Slashdot kiddies/fanboys, we can't assume that the people who have
been whining and shooting off their mouth about theft are not
representative of the *BSD developers.

So if we disregard that issue, the practical reality is that BSD and
Linux are different.  While the madwifi drivers were outside of the
tree, it might have made sense to have an OS-independent layer and
then surround the driver with an OS abstraction layer.  But if the
driver is going to be merged with mainline, the general Linux practice
is to make those abstraction layers Go Away.  (There have been a few
exceptions, such as the hideous Irix/vnode #define compatibility mess
in XFS, but that's been gradually cleaned up, and it really is the
exception that proves the rule; it's a great demonstration about why
such abstraction layers make the code less maintainable, and less
readable.)  Once you remove the OS abstraction layer, the code wasn't
going to be very useful to a BSD-based kernel _anyway_, so in
practical matters, whether the code would continue to be dual-licensed
GPL/BSD wouldn't matter anyway.

Hopefully this adds some clarity to the matter.

Regards,

						- Ted

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Wasting our Freedom
Date: Mon, 17 Sep 2007 01:20:26 UTC
Message-ID: <fa.icQ/JU7yQaNnDXT03feM0tiVnEQ@ifi.uio.no>

On Sun, Sep 16, 2007 at 05:29:56PM -0700, David Schwartz wrote:
> In responses and posts, there is over and over a huge confusion
> between two completely different issues. One is about whether you
> can modify licenses, the other is about whether you can modify
> license *notices*.
>
> Again, one more time:
>
> 1) You can obtain, from the GPL, the right to remove a BSD license notice.
>
> 2) You can obtain, from the BSD license, the right to remove a GPL
> license notice.
>
> 3) Neither of these actions has any effect on the fact that these
> licenses still exist from the original author and still grant rights
> to anyone who comes into lawful possession of the work.
>
> Of course, if you take a dual-licensed file, remove the BSD notice,
> and then add more to it, those contributions can be offered *by*
> *their* *original* *authors* under only the GPL.

Careful; the devil is really in the details on this one.  If you have
a file where all of the code was originally dual licensed (say, like
drivers/char/random.c, which was written by me and deliberately dual
licensed because I wanted other OS's to be able to use it), then this
might be true.

However, consider a file which was originally BSD licensed.  Now
suppose it is modified (i.e., a derived work was created) and another
author slaps on a BSD/GPL dual notice.  That's fine, so far; the BSD
license on the original file permits that.  The new code is licensed
under either BSD or GPL (user's choice), and the original code is
under the BSD license, which is compatible with the GPL code, so
regardless of whether the user choose the BSD or GPL license.

However, in such a case it is **NOT** kosher to remove the BSD license
notification.  Why?  Because the lines of code from the original file
was originally licensed under the BSD only.  The second author who
added the BSD/GPL'ed dual license only has the authority to release
the the code which he or she added under the BSD/GPL dual license.
The original code remains only licensed under the BSD license, but
that was OK because the BSD license is compatible with the GPL (but
not vice versa).


Now, in the case of the Atheros wireless code, the original author
(Sam Leffler) has stated that as far as *his* code was concerned, he
was willing to dual license it.  However, in this case, he agreed to
have the code dual-licensed three years after the project was started.
He was amused and had no objections to people retroactively applying
the licensing changes to code that was 3 years old.[1]

HOWEVER, he can only speak for himself.  If anyone in the first 3
years of the project made significant code contributions, they would
have reasonably expected them to be made under the BSD license, and
Sam's agreement to dual-license his code wouldn't apply to some other
major contributor.  And if there is any code which was not written by
Sam contributed dring the first 3 years, then it could only be
distributed under the terms of the BSD license, regardless of Sam's
statements.

This may be one of the reasons why Eben said that very careful
research needs to be done before making any definitive statement on
the subject.  Personally, my recommendation would just be to include
the original copyright statement (removing attribution is bad ju-ju)
and also to leave BSD permission statement in place.  Yes, maybe after
doing a huge amount of research we might be able to determine that all
of the code belonged to Sam at the point when he agreed to dual
license it, but is it worth it to make 100% sure of this question?
Why not just leave the BSD statement in place, and be done with it.
We've done this before; for example, take a look at drivers/net/slhc.c
as evidence of the fact that we do have some BSD code in the Linux
kernel, and having the BSD permission notice really doesn't hurt
anyone.


[1]  http://lkml.org/lkml/2007/9/1/160

						- Ted

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Wasting our Freedom
Date: Mon, 17 Sep 2007 12:20:09 UTC
Message-ID: <fa.YFb11Fa+gL8tuQz/87j6h+o788w@ifi.uio.no>

On Mon, Sep 17, 2007 at 01:18:05PM +0200, Hannah Schroeter wrote:
> >So for code which is single-licensed under a BSD license, someone can
> >create a new derived work, and redistribute it under a more
> >restrictive license --- either one as restrictive as NetApp's (where
> >no one is allowed to get binary unless they are a NetApp customer, or
> >source only after signing an NDA), or a GPL license.  It is not a
> >relicencing, per se, since the original version of the file is still
> >available under the original copyright; it is only the derived work
> >which is under the more restrictive copyright.
>
> No. The derivative work altogether has a *mixed* license. BSD/ISC for
> the parts that are original, the other (restrictive, GPL, whatever)
> license for the modifications/additions.

Yes, agreed.  I was being sloppy.  In actual practice, the GPL is more
restrictive, aod so the terms of the GPL are what tend to have more
effect, but you are absolutely correct.

> *If* you choose to distribute source along with the binaries, the part
> of the source that's original is BSD/ISC licensed even in the derivative
> work (though one may put *the additions/modifications* under restrictive
> conditions, e.g. of commercial non-disclosure type source licensing).

Yes, although actually, the place where the BSD license must be
honored is in a binary distribution, since the BSD license and
copyright attribution must be distributed as part of the binary
distribution.  (Even Microsoft does this when they use BSD code.)

For a source distribution, retaining the copyright attribution and
permission statement in the comments is sufficient to meet the BSD
license requirements, and since the open source world normally deals
mostly with source, we sometimes get sloppy with how we phrase things.

Regards,

						- Ted

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: Policy on dual licensing?
Date: Sun, 04 Nov 2007 13:38:01 UTC
Message-ID: <fa.bzC3M0eQZzfbPAf8kysD0eI0oYk@ifi.uio.no>

On Sat, Nov 03, 2007 at 12:14:15PM +0000, Remigiusz Modrzejewski wrote:
>
> We've all seen the last flame war about Linux stealing BSD code. Due to
> Theo's bad wording whole discussion rolled around the question about
> legality of this, a big waste of time (question answered a thousand
> times). Still, the question about ethics is quite valid...

Please let's not restart the flame war then.  The ethics question is
never going to be settled on LKML.  There are some people who believe
that a GPL license *does* make the world a better place, since it
doesn't allow a company like NetApp to take a open-source licensed OS,
make millions off of it, and not be obligated to contribute changes
back.  There are other people who believe that the BSD license is
morally and/or ethically superior because it allows NetApp to make
millions off of BSD 4.2/3 code, and they don't see any reason why such
a corporation should be obligated to give their improvements back ---
and that the existence of a BSD-licensed OS which allows this makes
the world a better place.

This is the essense of the of the BSD vs. GPL philosophical divide.

Then there are those who believe that it is morally and ethically
consistent not to obligate a company like NetApp to give back to the
original project from when it claim, and yet it is morally and
ethically consistent to try to lay a guilt trip on the Linux project
when they do exactly same thing as NetApp, except they are using a GPL
license instead of proprietary licese.

There are also who believe that such an attempt represents the height
of hypocrisy on the part of the whiners in the BSD camp.  And, of
course, there are those who think the BSD folks are being incredibly
silly, but who are personally willing such gestures in the name of
inter-project amity, while thinking that trying to make any kind of
blanket policy statement is folly.

If you haven't guessed, I'm in the latter camp.

> There are over four hundred C source files that mention BSD, but only
> a hundred of them is dual licensed. Of course not all mentions of BSD
> mean the file is derived from it, as well as not each such licensed file
> must use the acronym.  No matter what the scale really is, the problem
> exists.

First of all, just because it mentioned BSD doesn't necessarily mean
that it came from BSD.  For example, I wrote the /dev/random driver
spceifically from Linux, but dual licensed it because I wanted the BSD
camps to pick it up.  Secondly, you're presupposing that it is a
*problem*.  There are those who believe that there is nothing wrong,
either morally, ethically, or legally, with taking BSD code, and not
dual-licensing it when adding GPL-specific additions.  You are begging
the question by just asserting that it is a _problem_.  Some people
view the GPLv2 license as a feature, not a bug.

At the end of the day, people can choose whatever license they want.
BSD people have intentionally said they don't care if a NetApp takes
there codes and makes adds proprietary licensed code around it, when
they specified a BSD license.  The Open Solaris people have
intentionally said they don't want this, by picking a license which is
GPLv2 incompatible.  People who choose the GPLv2 license, either for a
new driver or when they add Linux-specific glue code as part of a port
of a driver, are also making their own statement.

> What I propose is implementing a policy on accepting such code.
> According to it, every time a maintainer is considering a driver
> that is derived from BSD and licensed GPL-only, should request
> for dual licensing before accepting the patch. If the submitter is
> reluctant to do so - what can we do, it's better to have this inside
> this way than not at all. However, this should minimize such cases
> and, hopefully, satisfy the claims about Linux maintainers not doing
> all that they could to make the world a better place.

Actually, again, you're begging the question.  I have no doubt that
people who write code under a BSD, CDDL, or GPL license all believe
they are making the world a better place in their own way.  For you to
say that Linux maintainers who don't try to get more drivers dual
licensed === not making the world a better place is just as unfair as
asserting that people who only make their code under the CDDL is doing
so only because they are trying to make their Sun options stop from
being underwater (blub blub blub :-).

						- Ted