Hi,
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...
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.
What I suppose is that people porting BSD code to Linux don't mean
closing the doors for back-porting changes. They are simply unaware
or forget about the possibility of dual licensing. Obviously, each
submitter should read Documentation/SubmittingDrivers, where it is
explicitly stated. Yet humans are prone to forgetting, so this may
seem not enough.
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.
Best regards,
Remigiusz Modrzejewski
--
Remigiusz 'lRem' Modrzejewski
I might be *extremely unresponsive* at the From: email...
Contact: http://lrem.net/pages/view/about
Feel free to correct my English.
Remigiusz Modrzejewski <[email protected]> writes:
> 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.
It doesn't make sense in general. Being derived from *BSD may mean
only a tiny fragment comes from *BSD. I can't see any valid reason
to force/ask the author to publish his/her code under BSD
(GPL + BSD = BSD) instead of GPLv2 as used by the whole Linux.
There are exceptions, of course - if you take a *BSD project and
include it with no/minor changes it makes sense to use BSD licence,
because we really want to cooperate, and because we don't have to
fear "evil corporations" taking our code (because it's mostly not
"ours").
--
Krzysztof Halasa
Krzysztof Halasa wrote:
> It doesn't make sense in general. Being derived from *BSD may mean
> only a tiny fragment comes from *BSD. I can't see any valid reason
> to force/ask the author to publish his/her code under BSD
> (GPL + BSD = BSD) instead of GPLv2 as used by the whole Linux.
>
> There are exceptions, of course - if you take a *BSD project and
> include it with no/minor changes it makes sense to use BSD licence,
> because we really want to cooperate, and because we don't have to
> fear "evil corporations" taking our code (because it's mostly not
> "ours").
Well, you've shown both poles, where the correct licensing decision
seems quite obvious. But in between there lies the great gray area,
where it's not so clear. Lets say you take a BSD driver and perform
a medium sized hack, eg add a new feature and include it into Linux
kernel. Now you've got code that has been mainly of appropriate *BSD
authorship, but with a reason for them (and the "evil corporations")
to want the change ported back. The final choice *is* to be made by
the author, it's the right way to be. What I suggest is to encourage
authors to share back, best done by maintainer asking to do so just
before committing.
--
Remigiusz 'lRem' Modrzejewski
Contact: http://lrem.net/pages/view/about
Feel free to correct my English.
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 propietary 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-licesing 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
Theodore Tso wrote:
>> 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-licesing 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.
All of my publicly released code is GPLv2. I just like it, but I don't
like the idea of taking someones else code and prohibiting him from
back-porting changes. On the other hand, you're probably just right,
I could've been decepted about the scale by the whining.
>> 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
This is not my claim. I've just got an idea how to prevent future flame
wars, bad press and other disturbances created by such claims. For me,
the idea looks quite good as it does not cost really much and is the
only thing that we can really do. If even this little additional strain
on the maintainers seems too much, considering the scale of the problem
really is minute, then just forget about the whole thing.
But, on the end of the day, the whole thing remains a problem in my
eyes. BSD folks have explicitly agreed companies/organisations to not
give back. These have divided into those who do give back, and those who
don't. Having Linux community in the second category feels not so good.
However, the fact that in most(?) cases it is not so is relaxing.
--
Remigiusz 'lRem' Modrzejewski
Contact: http://lrem.net/pages/view/about
Feel free to correct my English.
> What I suppose is that people porting BSD code to Linux don't mean
> closing the doors for back-porting changes. They are simply unaware
> or forget about the possibility of dual licensing. Obviously, each
> submitter should read Documentation/SubmittingDrivers, where it is
> explicitly stated. Yet humans are prone to forgetting, so this may
> seem not enough.
>
> 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.
>
> Best regards,
> Remigiusz Modrzejewski
This will result in more code in the Linux tree that has a license other
than the project default. This will impose a greater and greater burden on
developers who have to carefully check the license of files every time they
cut and paste code from one file into another.
It creates a serious risk of incorrect license notices (because someone
cuts/pastes a substantial chunk of GPL-only code into a dual-licensed file
without changing the license notice) and accidental copyright violations
(because someone else took the cut/pasted part into a BSD-licensed project)
if intimately-connected files are under different licenses. Every effort
should be made to avoid this.
Having a clear policy would be a good idea. I think the general policy
should be that any dual-licensed file should contain a clear notice that the
Linux kernel is GPL (that is the only license 'guaranteed' to cover the
entire distribution) and that development may result in the file being
"contaminated" by code that is not dual-licensed.
Just a notice referring to a 'dual license FAQ' in Documention would be
fine, of course. That file should advise developers that they should remove
the dual license if they cause the file to be no longer dual-licensable due
to code they've added, cut/pasted, or modified. Gratuitous removal of
dual-licensing should be discouraged, but removing it should be encouraged
where it's a genuine impediment to development.
The example I always use is if we have a filesystem with a different
license. Imagine if a new function is added to the filesystem interface. It
is offered in a 'generic' version, with the expectation that filesystems
will override it to provide a better-performing version. Imagine if the
generic version is GPLv2-only and a filesystem in-tree is dual licensed.
A developer probably cannot cut/paste the generic version as a base without
breaking the dual license. If they want to keep the dual license, they have
to re-implement the function. This creates an increased risk of bugs or
incompatibilities. Worse, it creates a maintenance headache in that this
function will need to be understood separately from other filesystems'
implementation of the same function. A little imagination will allow one to
imagine many ways this can cause problems.
The only good way this can end is if they change the license on that file to
GPL only. Possible bad ways include accidentally contaminating the
apparently dual-licensed file with code that was offered by its author only
under the GPL.
DS
On 04-11-2007 01:04, Theodore Tso wrote:
> 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.
Why not? Is it better to stay enemies forever? Sometimes, after the
war miracles happen and bitter enemies become friends...
...
> [...] There are those who believe that there is nothing wrong,
> either morally, ethically, or legally, with taking BSD code, and not
> dual-licesing it when adding GPL-specific additions. [...]
IMHO, the main problem is talking about these things instead of
some basics:
1. BSD copyright is simple here:
"1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer."
So, when I read on lkml, there are people, thinking they actually
can add here and there something about GPL, or even remove it at
all, we have a problem... Any legal, moral or ethical reasoning
here is useless (but gathering some weapons should be safe bet).
2. After retaining such a copyright, IMHO the war is over and BSD guys
call as the best friends! If we are very clever and stay with this
only, they probably can even become our slaves (if they are so
"incredibly silly" as presumed).
3. Otherwise, we have a problem: anything added or changed looks like
BSD copyrighted too. And this is really a legal, moral and ethical
problem, but it's our internal problem (I doubt BSD people are
silly enough to fight for these additions). If you haven't guessed,
I'm in the earlier camp...
Regards,
Jarek P.