Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

Alexandre Oliva
2007-06-18T18:43:03Z

On Jun 18, 2007, Johannes Stezenbach <js@linuxtv.org> wrote:

> I think those two goals are somewhat conflicting. If you want to
> win people for free software, you need to make it easy for them
> to accept your ideas. However, in order to make it easy you have to
> make compromises wrt the four freedoms.

If you make compromises, it ceases to be free software. *And*, in the
pragmatic plane, you lose the benefits from users whose freedoms will
be restricted by others.

> If you look at the lenght of this thread, don't you realize
> that even when you talk to software developers on a mailing list
> dealing with free software/open source, you have trouble
> to get acceptance for your fundamentalistic view of the
> ethical principles of free software?

I do. I get rejection from a number of people from whom I expected to
get rejection, those with fundamentalist but opposing positions.
Meanwhile, in private, I get lots of voices of encouragement and
gratitude for what I'm doing. I suppose they might even do that in
public if they didn't care about getting verbal abuse for exposing
dissenting opinions.

> And you haven't even started to talk to the business people,
> executives and lawyers which you need to convince if you
> want to make free software ubiquitous.

Oh, really? How do you know?

People talk a lot about TiVo here, but do they the faintest idea of
how the conversations with TiVo are proceeding? I thought so...

> "It's a bargain, you can use it for free and all you have to do is
> give back your changes" is what might work to win them.

And that's precisely what I've been working on. But fundamentalism
can indeed blind people. It works both ways, I guess.

> The bottom line is that I think your perception is completely wrong.

Do you think any part of this reasoning is wrong?

> no tivoization => more users able to tinker their formerly-tivoized
> computers => more users make useful modifications => more
> contributions in kind

I know you see the other possibility:

> no tivoization => fewer contributions from manufacturers that demand
> on tivoization

and there's another, that's break-even for the community so I didn't
even mention it:

no tivoization => ROM software, no difference for the community

So, you see, when people who oppose anti-tivoization measure the
outcome for the community, they only look at the second possibility,
assuming the vendor would immediately switch to some other software.
As if that was easy for the vendor, and as if the software sucked so
much that the vendor was just looking for a reason to switch.

But since the software is good, and moving to another software would
be costly in various dimentions, the vendor has an incentive to stick
with the software they have.

So the vendor will look into respecting users' freedoms, and they
might just do that, rather than switching to a tivoizable software or
facing the potential costs of ROM replacements at every software
update.

And if just a few vendors take the stance of respecting users'
freedoms, the community will gain not only more users, but also more
developers more motivated to improve the software to serve their own
interests, because they *will* be able to use the results of their
modifications on their devices.

So you see, the picture of anti-tivozation is not as bleak as people
try to frame it. In fact, it's not bleak at all. If one out of 10,
maybe even 1 out of 100 vendors start respecting users' freedoms, when
faced with anti-tivoization provisions, the community will already win
big time, because each vendor is likely to have thousands of
customers, some of which will use the freedoms to serve the goals of
the community, in the very terms the community claims to care about.

So, what flaw do you see in this reasoning?

--
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}