[Panel-devel] [PATCH] Beginnings of a panel implementation for discussion

[Thomas Fjellstrom]

On Sun August 19 2007, Jos Poortvliet wrote:
> On 8/19/07, Thomas Fjellstrom <tfjellstrom at strangesoft.net> wrote:
> > On Sat August 18 2007, Jos Poortvliet wrote:
> > > On 8/18/07, Thomas Fjellstrom <tfjellstrom at gmail.com> wrote:
> > > > On Fri August 17 2007, Aaron J. Seigo wrote:
> > > > > On Friday 17 August 2007, Robert Knight wrote:
> > > > > > This is mainly here to discuss the API for the Panel class and so
> > > > > > that we can put something together for the applet developers to
> >
> > test
> >
> > > > > > with.
> > > > >
> > > > > there are many issues with this code as it stands, but i'm fine
> > > > > with
> > > >
> > > > using
> > > >
> > > > > it as a start. issues, in no particular order, none of which imho
> >
> > block
> >
> > > > you
> > > >
> > > > > putting this into svn as a draft right now:
> > > > >
> > > > > - the dptr in Panel needs to be const'd
> > > > >
> > > > > - can you put it under the "LGPLv2 or later" please? thanks....
> > > >
> > > > Just a random thought, but that "or later" bit seems a little
> >
> > dangerous.
> >
> > > > They
> > > > (FSF) could put anything they want into v3, and the code would
> > > > automatically
> > > > be licenced under it. Not like they'd do anything like that though ;)
> > >
> > > They can't, it has to stay 'in the spirit of LGPLv2'. Now that term of
> > > course could mean a lot, but NOT something like BSD or proprietary. So
> >
> > it's
> >
> > > rather limited what they can do. Besides, KDE can just not start using
> >
> > the
> >
> > > 'later' part if we're not happy with the terms...
> >
> > Tis all I'm saying. Better safe than sorry. AFAIK, several projects have
> > already done search and replace on their source and docs for the "or
> > later"
> > bit. Just so they didn't get caught with terms they didn't agree with.
> >
> > IMO, its like saying to someone "I agree with you, now and forever!"
>
> Well, yes, it is. So it comes down to trust, I guess. Personally, I'd trust
> the FSF - they're pretty clear on what they want, and they can't change
> their opinion.

No, but they can keep adding more and more clauses to the licence that 
restrict what can be done with your code. If you like that, fine.

> Practically, having all code under "or later" is easier. If you don't want
> to go to the next version, as a project, no problem. Just don't. Of course,
> tell contributers to use GPLv2"or later", not GPLv3... If you want to go
> that way, you can. But if there is code without the "or later", you have to
> contact people to be able to go to a newer version.

If a version says "GPL2 or later" that includes 3, as v3 is "later". As soon 
as a new licence is out, it gets bumped up to it. People can start claiming 
(because it is) that "OMG ProjectX is GPL3" and then that gets blown out 
proportion, and theres a good chance that many potential (commercial) users 
will be put off, and decide to stay away.

>
> The only problem is if a contributer contributed code with GPLv2 or later,
> and there comes a gplv3 along the road which he doesn't like. KDE starts
> using it. Now he can't deny KDE the use of his code, while in the no "or
> later" situation, he could.
>
> I could see why a individual contributer would prefer the latter situation,
> but for KDE, it's worse. KDE is best off with a "or later" clause, because
> WE can then decide what to do.

Can you? I don't think so. If you say "or later" that means anyone using it 
can claim any version from 2 and onwards, weather you like it or not. You'd 
have to go back and make a request to all the copyright holders to change the 
licence (not an entirely easy task in many cases).

With the "or later" bit you are essentially being forced into agreeing to 
whatever gets put into new versions.

Whats better? Licence change on the project's terms or on the licence author's 
terms?

> And if a contributor doesn't like that, of 
> course, he can talk about it. And it's possible some don't want to
> contribute due to this clause (I think it's unlikely). Overall I think it's
> best to set this policy by default.

-- 
Thomas Fjellstrom
tfjellstrom at strangesoft.net