[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: NOTE: Please publicize any license changes to your packages

On Sat, 2007-07-21 at 10:58 -0700, Toshio Kuratomi wrote:
> On 7/21/07, Ralf Corsepius <rc040203 freenet de> wrote:
> > On Sat, 2007-07-21 at 04:37 -0500, Rex Dieter wrote:
> > > Ralf Corsepius wrote:
> > >
> > > > On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
> > > >> On 7/20/07, Ralf Corsepius <rc040203 freenet de> wrote:
> > > >> > So, the new FESCo is going to act as the "Fedora License Police"
> > > >>
> > > >> Always so negative.
> > > >
> > > > Well, why should I change my opinion on something which had been
> > > > repeatedly discussed to death (E.g. on FPC meetings) and which I
> > > > consider to be "silly and naive"?
> > >
> > > And that was before GPLv3 was released, mind you...
> > A fact which doesn't matter at all
> >
> >
> > 1. Actually, the GPL case is a comparatively simple case, because it's
> > widely used.
> >
> > The situations rendering such "license tagging" absurd are the "not so
> > far spread" and "exotic" licenses, which
> > * FESCO will never be able to handle due to lack of legal knowledge.
> > * RPM's license-tag will not be able to handle without a "license tag"
> > registry/Fedora license tag administration office.
> >
> > 2. Package maintainers are supposed to check their packages for license
> > compatibility. Otherwise Fedora will need a "licensing police".
> >
> > 3. We did cover GPLv3 in our discussions on FPC meetings.
> I tend to agree that the problem is going to lie in the more exotic
> licenses.  I think it would be *relatively* easy to mandate specifying
> GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv3, LGPLv3+, (And
> is there an LGPLv2.1 as well?). 

... and these are by far not all variants of the [L]GPLv2 ;)
Consider e.g. the "GPLv2 w/ <some exceptions>" and the "dual licensed

Also consider the impact on backporting patches against GPLv3'd versions
of a package to their GPLv2(+) predecessors. 

E.g. the GCC project currently is discussing the legal impact of
back-porting upstream (==GPLv3) changes to older releases (e.g. gcc-4.2)
and/or vendor forks/branches (such as Apple's GCC or RH's).

Also, though the FSF has a GPL* compatibility matrix, they don't provide
much help for other licenses' compatibility. I.e. at least I consider
the implications of GPLv3'd run-time packages on packages being licensed
differently to be widely unclear at this point in time.

To put it differently: To which extend is the old "GPL* vs. free-license
compatibility list" still valid?

>  (License proliferation, anyone?)  But
> going further in the License tag is going to be descending into
> madness. 
That's what I wanted to express - There lies madness and insanity inside
of the license tagging.

>  I'll wait for spot's proposal before jumping the gun on what
> I believe to be practical.
IMO, it needs to be a copyright-specialized lawyer to be able to clarify
the situation. Neither the FPC, FAB nor FESCo are able to handle such

> I have a question that I would like answered before the Packaging
> Meeting that will help clarify some things for me:  Who is the target
> audience of this information?  The FPC decided not to establish
> guidelines WRT License tags (other than being accurate) before because
> the target audience was end-users and we decided that end users should
> never take the license tag as authoritative.  If the target audience
> is internal developers, then the tag remains a hint.
IMO, the rpm license tag is both: informative to end-users and a hint to
developers. Active developers will have to carefully check a package
"they use" or "derive their works from" in any case.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]