[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Gentoo internal structure
From:       Jason Rhinelander <jason () gossamer-threads ! com>
Date:       2003-11-26 22:58:12
[Download RAW message or body]


Your retirement demonstration brings up a good point.  Unless 
specifically indicated, a license change is neither retroactive nor 
proactive; if the user agreed to the original license, they are under 
the original license so long as they don't change their software (unless 
the license is also time-limited in some way).  If an updated version of 
the program now comes with an updated (i.e. pay me $1,000,000 dollars) 
license, it's up to the developer responsible for the ebuild to take 
that into account, which will most definitely require a new 
ACCEPT_LICENSE value.

This will need to be taken into account when writing up an 
"ACCEPT_LICENSE" policy - every time a license changes, even if it is a 
very minor wording change, the license values have to change as well. 
If VMware, for example, adds a clause to their license agreement, this 
needs to be reflected with a new license value (let's call it, for the 
sake of discussion, 'vmware-2').  If they later add another one, that 
means a vmware-3 license is needed, and so on and so forth.

I'm certainly with you on not allowing * for licenses, but as has also 
been suggested here, I'm completely against a default that only allows 
includes OSI/FSF-approved software.  As often as possible, users should 
be able to just "emerge someprog" and have "someprog" be installed.  The 
default should include all licenses that don't require explicit license 
acceptance for installation - vmware is a good example - so that adding 
an ACCEPT_LICENSE option to portage does not require Gentoo users to do 
anything more than they have to now, but more easily allows packages 
that require explicit license acceptance.

However, we _do_ need to support a "-*" option, to allow the free 
software jihadists to have their way, without inconveniencing the rest 
of us.  The fact that I've seen comments in this thread to the effect of 
"having a choice of free and non-free software is not a choice," or 
"everyone should have a choice only as long as it's the same thing I 
choose" truly saddens me.

-- Jason Rhinelander
-- Gossamer Threads, Inc.


Bob Miller wrote:
> Christian Birchinger wrote:
> 
> 
>>It might sound a bit rude but i think the defaults should be
>>defined that most of the time only zealots need to tweak
>>them. I think most users don't care about most licenses and
>>shouldn't need to mess with this.
> 
> 
> I've seen several people express this attitude, and I like it a lot.
> 
> Let me tell you about my retirement plan.  I'm going to write a game,
> Linux-only, make it good enough that a few hundred of you will emerge
> it and try it out.  Then I'll change the license agreement so that
> next time you emerge the game you'll owe me $1million US.  Since
> you all have ACCEPT_LICENSES="*" as the default, you'll all accept my
> new license, I'll take you all to court (after subpoenaing apache logs
> from all the mirrors so I know who you are, and subpoenaing your
> make.conf and make.globals to prove you accepted the license), and sue
> you for my license fee.  If I can recover 1% of what you'll all owe
> me, I'll be happy enough.
> 
> Okay, that's NOT REALLY my plan.  I'm at least slightly ethical. (-:
> But it illustrates why you don't under any circumstances want
> ACCEPT_LICENSES="*", either as the default or as an option.  Accepting
> a license has consequences, and those consequences can hurt you.*  I'd
> recommend against letting the parser recognize a wildcard for licenses
> -- there's just too much danger for people who don't know any better
> to hurt themselves.
> 
> That's my opinion.  It's worth what you paid for it.
> 
> 
> * For a real life example that's somewhat less heinous, consider the
>   BitKeeper license.


--
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]