1:45 p.m.
The Fedora Engineering Steering Committee would like to remind maintainers
that a license change in a package is a very serious event - it has as many,
if not more, implications for related packages as ABI changes do.
Therefore, if your package changes license, even if it just changes the
license version, it is required that you announce it, whether on this list
or fedora-devel-list.
Note that any license change to a more restrictive license or license
version may affect the legality of portions of Fedora as a whole; ergo,
FESCo reserves the right to block upgrades of packages to versions with
new licenses to ensure the legal distribution of Fedora.
Please contact FESCo if you have any questions.
Bill
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
10:02 a.m.
On Thu, Jul 19, 2007 at 02:45:00PM -0400, Bill Nottingham wrote:
The Fedora Engineering Steering Committee would like to remind
maintainers
that a license change in a package is a very serious event - it has as many,
if not more, implications for related packages as ABI changes do.
Therefore, if your package changes license, even if it just changes the
license version, it is required that you announce it, whether on this list
or fedora-devel-list.
Note that any license change to a more restrictive license or license
version may affect the legality of portions of Fedora as a whole; ergo,
FESCo reserves the right to block upgrades of packages to versions with
new licenses to ensure the legal distribution of Fedora.
BTW, shouldn't we start changing License: tags in packages for *GPL
packages, so that it include the exact version?
E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
Jakub
10:21 a.m.
Somebody in the thread at some point said:
BTW, shouldn't we start changing License: tags in packages for
*GPL
packages, so that it include the exact version?
E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
There is a whole subject here... distributors of GPL2 "or later" have
the opportunity to specify the terms they are distributing it on. For
example, it is a legit option AIUI to specify that you are giving people
GPL2 "or later" stuff under specifically GPL2 terms.
-Andy
10:24 a.m.
On Fri, 2007-07-20 at 16:21 +0100, Andy Green wrote:
Somebody in the thread at some point said:
> BTW, shouldn't we start changing License: tags in packages for *GPL
> packages, so that it include the exact version?
> E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
> LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
There is a whole subject here... distributors of GPL2 "or later" have
the opportunity to specify the terms they are distributing it on. For
example, it is a legit option AIUI to specify that you are giving people
GPL2 "or later" stuff under specifically GPL2 terms.
Not really. If you have "or later" then someone can take the source
code and redistribute it under GPLv3. The "or later" is an additional
permission that is granted and you can't just go take that away without
removing all references to it. Even then, someone can just take an
older release and use that.
josh
10:40 a.m.
Somebody in the thread at some point said:
Not really. If you have "or later" then someone can take
the source
code and redistribute it under GPLv3. The "or later" is an additional
permission that is granted and you can't just go take that away without
removing all references to it. Even then, someone can just take an
older release and use that.
Sure, it doesn't affect the recipient's rights. But if a future version
of the GPL includes stronger demands on the distributor, specifying the
actual version of the rules under which you provided it will become
attractive real fast.
Nothing actually stops GPL v26 including unthinkable things someone
might demand you live up to.
-Andy
10:22 a.m.
On Fri, 2007-07-20 at 11:02 -0400, Jakub Jelinek wrote:
On Thu, Jul 19, 2007 at 02:45:00PM -0400, Bill Nottingham wrote:
> The Fedora Engineering Steering Committee would like to remind maintainers
> that a license change in a package is a very serious event - it has as many,
> if not more, implications for related packages as ABI changes do.
>
> Therefore, if your package changes license, even if it just changes the
> license version, it is required that you announce it, whether on this list
> or fedora-devel-list.
>
> Note that any license change to a more restrictive license or license
> version may affect the legality of portions of Fedora as a whole; ergo,
> FESCo reserves the right to block upgrades of packages to versions with
> new licenses to ensure the legal distribution of Fedora.
BTW, shouldn't we start changing License: tags in packages for *GPL
packages, so that it include the exact version?
E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
We're working on something like that, yes. See the FESCo meeting
minutes that Brian sent out today.
josh
10:26 a.m.
On Fri, 2007-07-20 at 11:02 -0400, Jakub Jelinek wrote:
On Thu, Jul 19, 2007 at 02:45:00PM -0400, Bill Nottingham wrote:
> The Fedora Engineering Steering Committee would like to remind maintainers
> that a license change in a package is a very serious event - it has as many,
> if not more, implications for related packages as ABI changes do.
>
> Therefore, if your package changes license, even if it just changes the
> license version, it is required that you announce it, whether on this list
> or fedora-devel-list.
>
> Note that any license change to a more restrictive license or license
> version may affect the legality of portions of Fedora as a whole; ergo,
> FESCo reserves the right to block upgrades of packages to versions with
> new licenses to ensure the legal distribution of Fedora.
BTW, shouldn't we start changing License: tags in packages for *GPL
packages, so that it include the exact version?
E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
Not yet. FESCo is currently working on how we want to handle this.
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
10:35 a.m.
Jakub Jelinek (jakub(a)redhat.com) said:
BTW, shouldn't we start changing License: tags in packages for
*GPL
packages, so that it include the exact version?
E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
This is currently a task for the Packaging committee to standardize.
Bill
12:27 a.m.
On Fri, 2007-07-20 at 11:35 -0400, Bill Nottingham wrote:
Jakub Jelinek (jakub(a)redhat.com) said:
> BTW, shouldn't we start changing License: tags in packages for *GPL
> packages, so that it include the exact version?
> E.g. License: GPL2 (or GPL2only?) for GPL 2 without any later,
> LGPL2.1+ (or LGPL2.1?) for LGPL 2.1 or any later, etc.
This is currently a task for the Packaging committee to standardize.
FPC several
times discussed this issue.
The result had been us voting against using versioned licenses, because
a) we consider the License-tag to be "informative" and not to be a legal
statement nor to have a legally binding effect.
b) we considered it inapplicable and to introduce too much
overhead/bureaucracy, because in general, there are too many
"un-numbered" variations of licenses around.
Ralf
12:30 a.m.
On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote:
The Fedora Engineering Steering Committee would like to remind
maintainers
that a license change in a package is a very serious event - it has as many,
if not more, implications for related packages as ABI changes do.
Therefore, if your package changes license, even if it just changes the
license version, it is required that you announce it, whether on this list
or fedora-devel-list.
Yet more bureaucrazy.
Please contact FESCo if you have any questions.
So, the new
FESCo is going to act as the "Fedora License Police"
Sorry, but I can't deny to consider this development unhelpful.
Ralf
1:32 a.m.
On 7/20/07, Ralf Corsepius <rc040203(a)freenet.de> wrote:
So, the new FESCo is going to act as the "Fedora License
Police"
Always so negative.
I'd personally like to think of it more as a Licensing Neighborhood
Watch Program. The goal here is to make sure that maintainers who are
depending on other packages such as libraries aren't blind-sided by a
licensing change that causes some sort of licensing violation. Trust
me, we don't want to have to deal with a licensing problem after the
fact. Nobody wants to end up in a situation where someone has to drop
the hammer and take a decisive corrective action to hot fix an
existing licensing problem. We minimize the chance of such things by
communicating amongst ourselves as maintainers when licensing changes
occur.
At the end of the day all maintainers are responsible for knowing the
licensing issues surrounding the distribution and linking of the
packages they maintain.. but there's an incentive for everyone to be
neighborly and make sure that licensing changes for packages are being
communicated to other maintainers that need to know about it before
those changes enter into the common repository of software.
Unless as a community we are prepared to support narrowing what we
allow in to exactly one version of one license there is going to have
to be an in-house pro-active effort to watch for potential problems in
the license arena. If you're not happy with FESCO playing the role of
'good cop' in this affair you might be significantly less thrilled
with my oscar worthy performance as 'bad cop.'
-jef"I shot a baby moose standing no futher than 6 feet away from me
in my yard yesterday. It shot it with a Nikon D200, through my front
window..several seconds after i peed my pants from the shock of
opening the window blinds to stare into the eyes of the large pony-ish
form in my yard"spaleta.
2:36 a.m.
On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
On 7/20/07, Ralf Corsepius <rc040203(a)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"?
Seems to me as if any new FESCo is going to commit the same beginner's
mistakes others had been trapped into before.
Ralf
4:37 a.m.
Ralf Corsepius wrote:
On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
> On 7/20/07, Ralf Corsepius <rc040203(a)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...
-- Rex
6:46 a.m.
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(a)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.
Ralf
8:54 a.m.
On Sat, 21 Jul 2007 13:46:36 +0200
Ralf Corsepius <rc040203(a)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(a)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
Yes, it does. GPLv3 and GPLv2 are incompatible. We are simply trying
to make sure we don't inadvertently commit a GPL violation.
josh
12:58 p.m.
On 7/21/07, Ralf Corsepius <rc040203(a)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(a)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?). (License proliferation, anyone?) But
going further in the License tag is going to be descending into
madness. I'll wait for spot's proposal before jumping the gun on what
I believe to be practical.
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.
-Toshio
1:58 a.m.
On Sat, 2007-07-21 at 10:58 -0700, Toshio Kuratomi wrote:
On 7/21/07, Ralf Corsepius <rc040203(a)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(a)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
cases".
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
situations.
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.
Ralf
2:52 p.m.
On Sat, 21 Jul 2007 09:36:34 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
> On 7/20/07, Ralf Corsepius <rc040203(a)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"?
Seems to me as if any new FESCo is going to commit the same beginner's
mistakes others had been trapped into before.
I'd like to point out this mandate came from the Board. FESCo did not
start this on their own, they were told to do it.
josh
9:50 a.m.
On Sat, 2007-07-21 at 14:52 -0500, Josh Boyer wrote:
On Sat, 21 Jul 2007 09:36:34 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
> On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
> > On 7/20/07, Ralf Corsepius <rc040203(a)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"?
>
> Seems to me as if any new FESCo is going to commit the same beginner's
> mistakes others had been trapped into before.
I'd like to point out this mandate came from the Board. FESCo did not
start this on their own, they were told to do it.
A couple of more items on this decision:
1. we're not looking for things to be programming-api-perfect when it
comes to license specification in the License: tag.
2. We want to make it easier to do a global query to look for certain
things:
ie: license X Requires a package which is license Y - these two are
incompatible and we need to deal with that.
Now, we're not expecting perfection, but it should be started.
-sv
10:12 a.m.
On 22.07.2007 16:50, seth vidal wrote:
On Sat, 2007-07-21 at 14:52 -0500, Josh Boyer wrote:
> On Sat, 21 Jul 2007 09:36:34 +0200
> Ralf Corsepius <rc040203(a)freenet.de> wrote:
>
>> On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
>>> On 7/20/07, Ralf Corsepius <rc040203(a)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"?
>>
>> Seems to me as if any new FESCo is going to commit the same beginner's
>> mistakes others had been trapped into before.
> I'd like to point out this mandate came from the Board. FESCo did not
> start this on their own, they were told to do it.
A couple of more items on this decision:
1. we're not looking for things to be programming-api-perfect when it
comes to license specification in the License: tag.
2. We want to make it easier to do a global query to look for certain
things:
ie: license X Requires a package which is license Y - these two are
incompatible and we need to deal with that.
Now, we're not expecting perfection, but it should be started.
/me can see the reasons for kind of GPL2, GPL2+, LGPL2+ stuff in the
license tag as well
But what I'd like to see added at the same time are some automatic check
to make sure properly done license changes get noticed automatically. A
basic "sha1sum the LICENSE file from upstream (most ship one) once and
put a small script into the %pre section that compares the know sha1sum
with the current one from the tarball and aborts if something changed"
should find properly done license changes automatically and keeps load
off the maintainer.
Sure, in an ideal world all maintainers would notice a license change by
reading the changelog or when interacting with upstream -- but we don't
live in and ideal world afaics and computers are made for such automatic
checks, so why not use them for what they were made?
Just my 2 cent.
Cu
thl
12:53 a.m.
On 7/22/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
But what I'd like to see added at the same time are some
automatic check
to make sure properly done license changes get noticed automatically. A
basic "sha1sum the LICENSE file from upstream (most ship one) once and
put a small script into the %pre section that compares the know sha1sum
with the current one from the tarball and aborts if something changed"
should find properly done license changes automatically and keeps load
off the maintainer.
That's actually a pretty good idea i think. For a lot of packages...
packages that can easily define a set of license/copying files...this
sort of automatic file checking would help flag problems. Granted its
not going to work for all packages, but it might help a lot in the
specific case of entire project codebases transitioning to gpl3 from a
previous license. But I would definitely like to stress the need for
individual maintainers to keep watch as to what the upstream projects
are planning as for re-licensing and communicate licensing changes to
the other fedora maintainers before they enter cvs/build system.
-jef
1:20 a.m.
On Sun, 2007-07-22 at 21:53 -0800, Jeff Spaleta wrote:
On 7/22/07, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
> But what I'd like to see added at the same time are some automatic check
> to make sure properly done license changes get noticed automatically. A
> basic "sha1sum the LICENSE file from upstream (most ship one) once and
> put a small script into the %pre section that compares the know sha1sum
> with the current one from the tarball and aborts if something changed"
> should find properly done license changes automatically and keeps load
> off the maintainer.
That's actually a pretty good idea i think. For a lot of packages...
packages that can easily define a set of license/copying files...
... __can__ ...
the critical cases are those which don't.
this
sort of automatic file checking would help flag problems.
In trivial cases such as
the GPLv3 change, it could help.
In cases of packages changing from FOO-license v1.283 to BAR-license
v32.100 it doesn't. In cases of packages pointing to web-sites, it
doesn't ... etc. If you try to track these you'll end up with 100s of
different license tags - This would require the often mentioned
bureaucracy.
Granted its
not going to work for all packages, but it might help a lot in the
specific case of entire project codebases transitioning to gpl3 from a
previous license.
If you think so, I disagree. You are driving away contributors
from
fedora, by imposing more and more bureaucracy. If you really want this
YOU (Jef Spaleta in person) will have to do it yourselves.
Ralf
1:33 a.m.
Somebody in the thread at some point said:
> sort of automatic file checking would help flag problems.
In trivial cases such as the GPLv3 change, it could help.
In cases of packages changing from FOO-license v1.283 to BAR-license
v32.100 it doesn't.
Wouldn't it notice the deletion of the FOO-license file at least though
and flag it up? At least then someone can examine it further, learn
about the change and tell it to track the BAR-license file.
In cases of packages pointing to web-sites, it
Yes I guess so, although it could wget the URL periodically and hash
that (assuming there are no "today's date" and crud on the page)
doesn't ... etc. If you try to track these you'll end up with
100s of
different license tags - This would require the often mentioned
bureaucracy.
> Granted its
> not going to work for all packages, but it might help a lot in the
> specific case of entire project codebases transitioning to gpl3 from a
> previous license.
If you think so, I disagree. You are driving away contributors from
fedora, by imposing more and more bureaucracy. If you really want this
The automated technique is a small burden if it works for most packages.
Since care is taken about the license to get it into Fedora it is
consistent to take some care about the license after it is in... and
with fun things like "or later" now...
-Andy
2:10 a.m.
On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote:
Somebody in the thread at some point said:
>> sort of automatic file checking would help flag problems.
> In trivial cases such as the GPLv3 change, it could help.
>
> In cases of packages changing from FOO-license v1.283 to BAR-license
> v32.100 it doesn't.
Wouldn't it notice the deletion of the FOO-license file at least though
and flag it up?
If there is any, may-be - If there isn't any, no.
Also consider: Detached license files are legally questionable/doubtful.
What matters is the license inlined or referenced by each files. Non
copyright owner added licenses are even more questionable.
At least then someone
someone == Jef Spaleta or other people
from the Board
> In cases of packages pointing to web-sites, it
Yes I guess so, although it could wget the URL periodically and hash
that (assuming there are no "today's date" and crud on the page)
Feel
free to do so ... Feel free to do so if these URLs change or vanish ;)
>> Granted its
>> not going to work for all packages, but it might help a lot in the
>> specific case of entire project codebases transitioning to gpl3 from a
>> previous license.
> If you think so, I disagree. You are driving away contributors from
> fedora, by imposing more and more bureaucracy. If you really want this
The automated technique is a small burden if it works for most packages.
We already
_have_ way too much bureaucracy in Fedora.
Since care is taken about the license to get it into Fedora it is
consistent to take some care about the license after it is in... and
with fun things like "or later" now...
Feel free to do so - Without me.
Shall the "Board" (Whatever
board-de-jour we might be talking about) and the dark forces surrounding
it inside of RH do so - Without me - Period.
Ralf
7:59 a.m.
On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote:
On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote:
> Somebody in the thread at some point said:
>
> >> sort of automatic file checking would help flag problems.
> > In trivial cases such as the GPLv3 change, it could help.
> >
> > In cases of packages changing from FOO-license v1.283 to BAR-license
> > v32.100 it doesn't.
>
> Wouldn't it notice the deletion of the FOO-license file at least though
> and flag it up?
If there is any, may-be - If there isn't any, no.
Also consider: Detached license files are legally questionable/doubtful.
What matters is the license inlined or referenced by each files. Non
copyright owner added licenses are even more questionable.
> At least then someone
someone == Jef Spaleta or other people from the Board
> > In cases of packages pointing to web-sites, it
>
> Yes I guess so, although it could wget the URL periodically and hash
> that (assuming there are no "today's date" and crud on the page)
Feel free to do so ... Feel free to do so if these URLs change or vanish ;)
> >> Granted its
> >> not going to work for all packages, but it might help a lot in the
> >> specific case of entire project codebases transitioning to gpl3 from a
> >> previous license.
> > If you think so, I disagree. You are driving away contributors from
> > fedora, by imposing more and more bureaucracy. If you really want this
>
> The automated technique is a small burden if it works for most packages.
We already _have_ way too much bureaucracy in Fedora.
> Since care is taken about the license to get it into Fedora it is
> consistent to take some care about the license after it is in... and
> with fun things like "or later" now...
Feel free to do so - Without me. Shall the "Board" (Whatever
board-de-jour we might be talking about) and the dark forces surrounding
it inside of RH do so - Without me - Period.
dark forces?
JFC Ralf.
josh
11:14 a.m.
On Mon, 2007-07-23 at 07:59 -0500, Josh Boyer wrote:
On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote:
> On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote:
> > Somebody in the thread at some point said:
> >
> > >> sort of automatic file checking would help flag problems.
> > > In trivial cases such as the GPLv3 change, it could help.
> > >
> > > In cases of packages changing from FOO-license v1.283 to BAR-license
> > > v32.100 it doesn't.
> >
> > Wouldn't it notice the deletion of the FOO-license file at least though
> > and flag it up?
> If there is any, may-be - If there isn't any, no.
>
> Also consider: Detached license files are legally questionable/doubtful.
> What matters is the license inlined or referenced by each files. Non
> copyright owner added licenses are even more questionable.
>
> > At least then someone
> someone == Jef Spaleta or other people from the Board
>
>
> > > In cases of packages pointing to web-sites, it
> >
> > Yes I guess so, although it could wget the URL periodically and hash
> > that (assuming there are no "today's date" and crud on the page)
> Feel free to do so ... Feel free to do so if these URLs change or vanish ;)
>
> > >> Granted its
> > >> not going to work for all packages, but it might help a lot in the
> > >> specific case of entire project codebases transitioning to gpl3 from
a
> > >> previous license.
> > > If you think so, I disagree. You are driving away contributors from
> > > fedora, by imposing more and more bureaucracy. If you really want this
> >
> > The automated technique is a small burden if it works for most packages.
> We already _have_ way too much bureaucracy in Fedora.
>
> > Since care is taken about the license to get it into Fedora it is
> > consistent to take some care about the license after it is in... and
> > with fun things like "or later" now...
> Feel free to do so - Without me. Shall the "Board" (Whatever
> board-de-jour we might be talking about) and the dark forces surrounding
> it inside of RH do so - Without me - Period.
dark forces?
The person @RH or the person from whatever
"committee-de-jour", who is
pushing this nonsense onto users and devs. - Give names, please.
Ralf
11:19 a.m.
On Tue, 2007-07-24 at 18:14 +0200, Ralf Corsepius wrote:
> dark forces?
The person @RH or the person from whatever "committee-de-jour", who is
pushing this nonsense onto users and devs. - Give names, please.
I'm one of them. We're asking for this information in the packages b/c
we are worried about licensing version conflicts making it a problem for
us to ship certain packages linked against other ones. This was after
conversation with legal.
So, if you want, I'm one of the "Dark Forces".
WE NEED THE INFORMATION. The board has been empowered to make this
decision. Supposedly, fesco and fpc implement the decisions that the
board has made. That's why we asked for it to be addressed there.
That's how the system is supposed to work. Exactly where are the dark
forces?
-sv
2:20 p.m.
On Tue, 2007-07-24 at 12:19 -0400, seth vidal wrote:
On Tue, 2007-07-24 at 18:14 +0200, Ralf Corsepius wrote:
> > dark forces?
> The person @RH or the person from whatever "committee-de-jour", who is
> pushing this nonsense onto users and devs. - Give names, please.
>
I'm one of them. We're asking for this information in the packages b/c
we are worried about licensing version conflicts making it a problem for
us to ship certain packages linked against other ones. This was after
conversation with legal.
Then spare your breath. I've been told all FSF owned
packages will
change to [L]GPLv3 by RMS order until 2007-07-31.
GCC/binutils/gdb already are changing. I don't know about others.
Once glibc will change, you can mark all packages for "review by legal".
So, if you want, I'm one of the "Dark Forces".
WE NEED THE INFORMATION. The board has been empowered to make this
decision. Supposedly, fesco and fpc implement the decisions that the
board has made. That's why we asked for it to be addressed there.
That's how the system is supposed to work. Exactly where are the dark
forces?
The dark forces are those people behind the various (almost daily
mushrooming - At least I've lost oversight) committees trying to push
volunteering contributors around.
Wake up RedHat, FAB, FPB, FPC, FESCo, FMB ...! We are volunteers!
You can try to push us - but not for very much longer. My camel's back
already is broken, I've significantly reduced my involvement.
Ralf
2:34 p.m.
On Tue, 24 Jul 2007 21:20:45 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
Then spare your breath. I've been told all FSF owned packages
will
change to [L]GPLv3 by RMS order until 2007-07-31.
GCC/binutils/gdb already are changing. I don't know about others.
Once glibc will change, you can mark all packages for "review by
legal".
Until the FSF figures out what the hell they're going to do with gplv2
being incompatible with gplv3, we can't allow it in the distribution.
--
Jesse Keating
Release Engineer: Fedora
2:40 p.m.
On Tue, 2007-07-24 at 15:34 -0400, Jesse Keating wrote:
On Tue, 24 Jul 2007 21:20:45 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
> Then spare your breath. I've been told all FSF owned packages will
> change to [L]GPLv3 by RMS order until 2007-07-31.
>
> GCC/binutils/gdb already are changing. I don't know about others.
> Once glibc will change, you can mark all packages for "review by
> legal".
Until the FSF figures out what the hell they're going to do with gplv2
being incompatible with gplv3, we can't allow it in the distribution.
Check the
gcc list. There is pretty monsterous discussion on related
topics taking place (100+ postings so far).
Ralf
2:48 p.m.
On Tue, 24 Jul 2007 21:40:52 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
Check the gcc list. There is pretty monsterous discussion on related
topics taking place (100+ postings so far).
I know. The outcome of such discussions is what is important, and
preventing anything from 'jumping the gun' is really important to
Fedora. This is why we want to be on top of any and all license
changes.
--
Jesse Keating
Release Engineer: Fedora
2:49 p.m.
On Tue, 2007-07-24 at 15:34 -0400, Jesse Keating wrote:
On Tue, 24 Jul 2007 21:20:45 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
> Then spare your breath. I've been told all FSF owned packages will
> change to [L]GPLv3 by RMS order until 2007-07-31.
>
> GCC/binutils/gdb already are changing. I don't know about others.
> Once glibc will change, you can mark all packages for "review by
> legal".
Until the FSF figures out what the hell they're going to do with gplv2
being incompatible with gplv3, we can't allow it in the distribution.
that's sort of an unfair statement of the situation.
gplv3 is not compatible with v2, but for what would it need to be? YOu
can have v2 and v3 programs in the same distro just like you can have v2
and other licensed programs in the same distro.
It only becomes a problem when you're linking (and for most cases that
is fine) or are otherwise a derived work.
2:57 p.m.
On Tue, 24 Jul 2007 12:49:59 -0700
Arjan van de Ven <arjan(a)infradead.org> wrote:
gplv3 is not compatible with v2, but for what would it need to be?
YOu
can have v2 and v3 programs in the same distro just like you can have
v2 and other licensed programs in the same distro.
It only becomes a problem when you're linking (and for most cases that
is fine) or are otherwise a derived work.
Yes, and that's why we need to know, so we can examine the linking path
and ensure that we're not breaking any (l)gplv2 only licenses. We
can't just rely upon upstream, as they have no idea what we're linking
to their software.
--
Jesse Keating
Release Engineer: Fedora
5:42 a.m.
On Tue, 2007-07-24 at 15:57 -0400, Jesse Keating wrote:
On Tue, 24 Jul 2007 12:49:59 -0700
Arjan van de Ven <arjan(a)infradead.org> wrote:
> gplv3 is not compatible with v2, but for what would it need to be? YOu
> can have v2 and v3 programs in the same distro just like you can have
> v2 and other licensed programs in the same distro.
>
> It only becomes a problem when you're linking (and for most cases that
> is fine) or are otherwise a derived work.
Yes, and that's why we need to know, so we can examine the linking path
and ensure that we're not breaking any (l)gplv2 only licenses. We
can't just rely upon upstream, as they have no idea what we're linking
to their software.
Not so easy, some packages may contain differently licensed
binaries/libraries.
As an example samba is GPLv2 (GPLv3 with the next release) but some key
libraries are LGPLv2 (v3 next). These libraries have been released under
the LGPL explicitly because some other projects wanted to use them and
needed (because of foreign constraints) a more liberal license.
So a tool that marks samba as GPLv3 may raise a high number of false
positives. I guess many other projects will fall under the same
conditions.
Also sometimes plugins falls in a grey area while technically a graph
may seem to link incompatible licensed code that is not clearly
derivative. Lots of corner cases.
Finally managing exceptions (like the OpenSSL one many projects have)
may not be easy at all.
Simo.
6:05 a.m.
On Wed, 25 Jul 2007 06:42:53 -0400
Simo Sorce <ssorce(a)redhat.com> wrote:
So a tool that marks samba as GPLv3 may raise a high number of false
positives. I guess many other projects will fall under the same
conditions.
Also sometimes plugins falls in a grey area while technically a graph
may seem to link incompatible licensed code that is not clearly
derivative. Lots of corner cases.
Finally managing exceptions (like the OpenSSL one many projects have)
may not be easy at all.
I think you're missing the point of the task. The task isn't to mark
perfectly in every spec file exactly what a package contains. Instead
it can mark the easy cases, and denote something in the hard cases so
that when an issue arises, we can easily weed out the easy cases and
focus on the hard ones manually.
--
Jesse Keating
Release Engineer: Fedora
6:26 a.m.
On 25.07.2007 13:05, Jesse Keating wrote:
On Wed, 25 Jul 2007 06:42:53 -0400
Simo Sorce <ssorce(a)redhat.com> wrote:
> So a tool that marks samba as GPLv3 may raise a high number of false
> positives. I guess many other projects will fall under the same
> conditions.
> [...]
I think you're missing the point of the task. The task isn't to mark
perfectly in every spec file exactly what a package contains. Instead
it can mark the easy cases, and denote something in the hard cases so
that when an issue arises, we can easily weed out the easy cases and
focus on the hard ones manually.
In addition -- in some cases like the quoted one for samba it *might* be
the easiest and cleanest solution for everyone to just put the libs with
a different license into a different (sub)package.
Cu
thl
7:43 a.m.
On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote:
On 25.07.2007 13:05, Jesse Keating wrote:
> On Wed, 25 Jul 2007 06:42:53 -0400
> Simo Sorce <ssorce(a)redhat.com> wrote:
>
>> So a tool that marks samba as GPLv3 may raise a high number of false
>> positives. I guess many other projects will fall under the same
>> conditions.
>> [...]
> I think you're missing the point of the task. The task isn't to mark
> perfectly in every spec file exactly what a package contains. Instead
> it can mark the easy cases, and denote something in the hard cases so
> that when an issue arises, we can easily weed out the easy cases and
> focus on the hard ones manually.
In addition -- in some cases like the quoted one for samba it *might* be
the easiest and cleanest solution for everyone to just put the libs with
a different license into a different (sub)package.
While it may be the case, the decision should absolutely not be dictated
by the license.
Simo.
7:55 a.m.
Le Mer 25 juillet 2007 14:43, Simo Sorce a écrit :
On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote:
> In addition -- in some cases like the quoted one for samba it
> *might* be
> the easiest and cleanest solution for everyone to just put the libs
> with
> a different license into a different (sub)package.
While it may be the case, the decision should absolutely not be
dictated
by the license.
I respectfuly disagree - for every project that uses a mix of licenses
the licensing split is motivated either by different code origin or by
a careful reflexion on what part can be re-used in what context. In
both cases bundling everything in a single package or subackage is not
doing anyone any favour.
--
Nicolas Mailhot
8:09 a.m.
On Wed, 2007-07-25 at 14:55 +0200, Nicolas Mailhot wrote:
Le Mer 25 juillet 2007 14:43, Simo Sorce a écrit :
> On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote:
>> In addition -- in some cases like the quoted one for samba it
>> *might* be
>> the easiest and cleanest solution for everyone to just put the libs
>> with
>> a different license into a different (sub)package.
>
> While it may be the case, the decision should absolutely not be
> dictated
> by the license.
I respectfuly disagree - for every project that uses a mix of licenses
the licensing split is motivated either by different code origin or by
a careful reflexion on what part can be re-used in what context. In
both cases bundling everything in a single package or subackage is not
doing anyone any favour.
I believe packaging splits should be done based on the functionality
they provide. As long as licenses are compatible I don't see why you
should package stuff based on the component license.
Simo.
8:24 a.m.
On Wed, 25 Jul 2007 09:09:44 -0400
Simo Sorce <ssorce(a)redhat.com> wrote:
I believe packaging splits should be done based on the functionality
they provide. As long as licenses are compatible I don't see why you
should package stuff based on the component license.
Compatible with eachother is different than compatible in the same ways
with other licensed software you may wish to combine with it. (yes
this is hyperbole)
--
Jesse Keating
Release Engineer: Fedora
8:57 a.m.
On Wed, Jul 25, 2007 at 02:55:39PM +0200, Nicolas Mailhot wrote:
> While it may be the case, the decision should absolutely not be
> dictated
> by the license.
I respectfuly disagree - for every project that uses a mix of licenses
the licensing split is motivated either by different code origin or by
a careful reflexion on what part can be re-used in what context. In
both cases bundling everything in a single package or subackage is not
doing anyone any favour.
Additionally, if the -devel packages were split on license boundaries,
then perhaps the buildsystem could flag attempts to link to
incompatibly-licensed libararies.
10:20 a.m.
Chuck Anderson <cra(a)WPI.EDU> wrote:
[...]
Additionally, if the -devel packages were split on license
boundaries,
then perhaps the buildsystem could flag attempts to link to
incompatibly-licensed libararies.
This is worse than I feared the fabled GPLv3 fallout could be...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
7:06 p.m.
On 7/25/07, Horst H. von Brand <vonbrand(a)inf.utfsm.cl> wrote:
This is worse than I feared the fabled GPLv3 fallout could be...
Worse in what way exactly? Isn't licensing transparency important?
Splitting packages based on licensing might look like a crap load of
work that noone is thrilled about doing... but the reality is, noone
is going to be thrilled about doing the work to that makes license
compliance a managable endeavor. There is nothing sexy from a
technical perspective about license compliance, but the need for it a
reality...especially now that we've run into a situation where lots of
concurrent codebase relicensing will be happening higgly-piggly. If
we are serious about having tools in our buildsystem that make this
less painful moving forward, then what Chuck has suggested seems like
a reasonably valid point of discussion. If we are serious about
building programmatic automation tools, then we will have to adapt how
we do things to make the automation reliable. The only question is how
much error are we prepared to deal with, and how much effort are we
prepared to expend.
-jef"Are there people out there who enjoy exploring the minutia of
open source licensing? If you are reading this, feel free to talk to
me off-list about potentially contributing time for Fedora licensing
auditing"spaleta
3:02 a.m.
Le Mer 25 juillet 2007 17:20, Horst H. von Brand a écrit :
Chuck Anderson <cra(a)WPI.EDU> wrote:
[...]
> Additionally, if the -devel packages were split on license
> boundaries,
> then perhaps the buildsystem could flag attempts to link to
> incompatibly-licensed libararies.
This is worse than I feared the fabled GPLv3 fallout could be...
Don't be ridiculous, we're addressing this now because some people
have decided to make GPLv3 an issue, but licence tagging and checking
is a longstanding problem which was going to bite us sooner or later
once Fedora expanded from a small well-known core to a huge package
collection.
Some software pools have standardised on a single well-understood
licence. Many haven't and this was true before the GPLv3 endeavour was
announced.
--
Nicolas Mailhot
10:46 a.m.
On Wed, 25 Jul 2007, Chuck Anderson wrote:
On Wed, Jul 25, 2007 at 02:55:39PM +0200, Nicolas Mailhot wrote:
> I respectfuly disagree - for every project that uses a mix of licenses
> the licensing split is motivated either by different code origin or by
> a careful reflexion on what part can be re-used in what context. In
> both cases bundling everything in a single package or subackage is not
> doing anyone any favour.
Additionally, if the -devel packages were split on license boundaries,
then perhaps the buildsystem could flag attempts to link to
incompatibly-licensed libararies.
Oooh. While that would still require the License tags to be correct,
that seems like a really clever idea to me.
Jima
8:41 a.m.
On Wed, 2007-07-25 at 13:26 +0200, Thorsten Leemhuis wrote:
On 25.07.2007 13:05, Jesse Keating wrote:
> On Wed, 25 Jul 2007 06:42:53 -0400
> Simo Sorce <ssorce(a)redhat.com> wrote:
>
>> So a tool that marks samba as GPLv3 may raise a high number of false
>> positives. I guess many other projects will fall under the same
>> conditions.
>> [...]
> I think you're missing the point of the task. The task isn't to mark
> perfectly in every spec file exactly what a package contains. Instead
> it can mark the easy cases, and denote something in the hard cases so
> that when an issue arises, we can easily weed out the easy cases and
> focus on the hard ones manually.
In addition -- in some cases like the quoted one for samba it *might* be
the easiest and cleanest solution for everyone to just put the libs with
a different license into a different (sub)package.
This would only be sensible if we had a way to tag the license for the
source and the main binary package differently. Unless that exists, we
can only put "License: <all licenses combined>" into such a package
because you'd need to cover the source RPM.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
3:02 p.m.
On Tue, Jul 24, 2007 at 12:49:59PM -0700, Arjan van de Ven wrote:
> > GCC/binutils/gdb already are changing. I don't know
about others.
> > Once glibc will change, you can mark all packages for "review by
> > legal".
>
> Until the FSF figures out what the hell they're going to do with gplv2
> being incompatible with gplv3, we can't allow it in the distribution.
that's sort of an unfair statement of the situation.
gplv3 is not compatible with v2, but for what would it need to be? YOu
can have v2 and v3 programs in the same distro just like you can have v2
and other licensed programs in the same distro.
It only becomes a problem when you're linking (and for most cases that
is fine) or are otherwise a derived work.
The only problem is lgplv3, I don't see any problems with including
gplv3 programs in Fedora and including gplv3 gcc or binutils in Fedora
will be soon a necessity.
Jakub
3:10 p.m.
On Tue, 2007-07-24 at 16:02 -0400, Jakub Jelinek wrote:
On Tue, Jul 24, 2007 at 12:49:59PM -0700, Arjan van de Ven wrote:
> > > GCC/binutils/gdb already are changing. I don't know about others.
> > > Once glibc will change, you can mark all packages for "review by
> > > legal".
> >
> > Until the FSF figures out what the hell they're going to do with gplv2
> > being incompatible with gplv3, we can't allow it in the distribution.
>
>
> that's sort of an unfair statement of the situation.
> gplv3 is not compatible with v2, but for what would it need to be? YOu
> can have v2 and v3 programs in the same distro just like you can have v2
> and other licensed programs in the same distro.
>
> It only becomes a problem when you're linking (and for most cases that
> is fine) or are otherwise a derived work.
The only problem is lgplv3, I don't see any problems with including
gplv3 programs in Fedora and including gplv3 gcc or binutils in Fedora
will be soon a necessity.
And I don't even see the problem with lgplv3 - we just have to ensure
that we don't link any gplv2 only program to such library. Such as we
have to ensure that we don't link any gpl program to openssl library and
so on.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
3:15 p.m.
Tomas Mraz napsal(a):
And I don't even see the problem with lgplv3 - we just have to
ensure
that we don't link any gplv2 only program to such library. Such as we
have to ensure that we don't link any gpl program to openssl library and
so on.
Fedora currently packages software under GPLv2. What happens to the
software if we update glibc go a lgplv3 version?
Mirek
3:18 p.m.
Hi.
On Tue, 24 Jul 2007 22:10:18 +0200, Tomas Mraz wrote
And I don't even see the problem with lgplv3 - we just have to
ensure
that we don't link any gplv2 only program to such library. Such as we
have to ensure that we don't link any gpl program to openssl library
and so on.
Errr.. like these?
stunnel: GPL
ssmtp: GPL
wget: GPL
slrn: GPL
htdig: GPL
cadaver: GPL
pam_ccreds: GPL
lftp: GPL
openvpn: GPL
ctorrent: GPL
elinks: GPL
wpa_supplicant: GPL
perl-Crypt-SSLeay: GPL or Artistic
libdhcp6client: GPL
xen: GPL
dhcpv6_client: GPL
git-core: GPL
fetchmail: GPL
rdesktop: GPL
claws-mail: GPL
claws-mail-plugins-pgp: GPL
gkrellm: GPL
3:28 p.m.
On Tue, 2007-07-24 at 22:18 +0200, Ralf Ertzinger wrote:
Hi.
On Tue, 24 Jul 2007 22:10:18 +0200, Tomas Mraz wrote
> And I don't even see the problem with lgplv3 - we just have to ensure
> that we don't link any gplv2 only program to such library. Such as we
> have to ensure that we don't link any gpl program to openssl library
> and so on.
Errr.. like these?
stunnel: GPL
ssmtp: GPL
wget: GPL
slrn: GPL
htdig: GPL
cadaver: GPL
pam_ccreds: GPL
lftp: GPL
openvpn: GPL
ctorrent: GPL
elinks: GPL
wpa_supplicant: GPL
perl-Crypt-SSLeay: GPL or Artistic
libdhcp6client: GPL
xen: GPL
dhcpv6_client: GPL
git-core: GPL
fetchmail: GPL
rdesktop: GPL
claws-mail: GPL
claws-mail-plugins-pgp: GPL
gkrellm: GPL
Either they have exception for linking with openssl or we are already
breaking the licenses and we should stop doing that. Why nobody noticed
that earlier?
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
3:31 p.m.
On Tue, 24 Jul 2007 22:28:22 +0200
Tomas Mraz <tmraz(a)redhat.com> wrote:
Either they have exception for linking with openssl or we are
already
breaking the licenses and we should stop doing that. Why nobody
noticed that earlier?
Maybe because we were assuming that the maintainers knew what they were
doing? (not that I know if there is any problem here...)
--
Jesse Keating
Release Engineer: Fedora
3:47 p.m.
Hi.
Maybe this link can help?
http://www.gnome.org/~markmc/openssl-and-the-gpl.html
Regards,
Fabio
On 7/24/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 24 Jul 2007 22:28:22 +0200
Tomas Mraz <tmraz(a)redhat.com> wrote:
> Either they have exception for linking with openssl or we are already
> breaking the licenses and we should stop doing that. Why nobody
> noticed that earlier?
Maybe because we were assuming that the maintainers knew what they were
doing? (not that I know if there is any problem here...)
--
Jesse Keating
Release Engineer: Fedora
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
3:51 p.m.
Once upon a time, Ralf Ertzinger <fedora(a)camperquake.de> said:
claws-mail: GPL
fetchmail: GPL
openvpn: GPL
rdesktop: GPL
stunnel: GPL
wget: GPL
These include an OpenSSL exception.
elinks: GPL
This has a sort-of OpenSSL exception.
claws-mail-plugins-pgp: GPL
This is a collection of different things; some list an OpenSSL exception
(and may be the only ones that use OpenSSL).
cadaver: GPL
ctorrent: GPL
git-core: GPL
gkrellm: GPL
lftp: GPL
pam_ccreds: GPL
slrn: GPL
ssmtp: GPL
No mention of an exception.
htdig: GPL
LGPL not GPL (not sure what that means for OpenSSL linking though).
wpa_supplicant: GPL
Dual-licensed GPLv2 and BSD.
perl-Crypt-SSLeay: GPL or Artistic
I believe Artistic is okay with OpenSSL.
dhcpv6_client: GPL
libdhcp6client: GPL
Boy, this looks like a mess. No overall license that I can find
(looking at dhcpv6-0.10-42.fc7), most files under a BSD-style (3 clause)
license from IBM, and one file that is patched out under LGPL. The
libdhcp6client subdirectory files are mixed as well; some have no
license and some have GPL (no version).
xen: GPL
Some files are dual-licensed BSD; I'm not sure which link to OpenSSL.
This is a good example of why license changes need to be clearly
announced and researched.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
3:59 p.m.
On Tue, 24 Jul 2007 15:51:15 -0500
Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Ralf Ertzinger <fedora(a)camperquake.de> said:
> dhcpv6_client: GPL
> libdhcp6client: GPL
Boy, this looks like a mess. No overall license that I can find
(looking at dhcpv6-0.10-42.fc7), most files under a BSD-style (3 clause)
license from IBM, and one file that is patched out under LGPL. The
libdhcp6client subdirectory files are mixed as well; some have no
license and some have GPL (no version).
The things added should all be under GPLv2 with Red Hat as the copyright holder. Double
checking as this is one of my packages.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat / Westford, MA
3:51 p.m.
On 7/24/07, Tomas Mraz <tmraz(a)redhat.com> wrote:
And I don't even see the problem with lgplv3 - we just have to
ensure
that we don't link any gplv2 only program to such library. Such as we
have to ensure that we don't link any gpl program to openssl library and
so on.
"We" have to ensure.... let me stress the "We" in that first
sentence.
The individual library maintainers are the absolute best people to be
running point for the library packages they are maintaining. They are
best positioned to make sure information gets to the other maintainers
who depend on that package, before a re-licensed version of the
library gets into one of the build trees. It would be best if "we"
could prevent situations where "we" have inadvertent linking
violations. But each individual maintainer needs to try the find the
time to review their packages to see what the hell is going on
upstream for the libraries they are linking against. Pretty please,
with sugar on top.
I'd really like to avoid a situation where we have to start
arbitrarily rolling back commits to clean up linking violations which
could have been avoided through reasonable communication. As more
individual projects who were previous under LGPL2/GPL2 start
relicensing we may need to adjust how we do things until the licensing
situation settles out and upstream projects are back to a consistent
understood licensing state.
-jef"i need a new watch, i smashed mine against something yesterday
and now the glass face as an internal crack. There's no way that thing
is going to survive the winter"spaleta
3:55 p.m.
On Tue, 2007-07-24 at 12:51 -0800, Jeff Spaleta wrote:
I'd really like to avoid a situation where we have to start
arbitrarily rolling back commits to clean up linking violations which
could have been avoided through reasonable communication. As more
individual projects who were previous under LGPL2/GPL2 start
relicensing we may need to adjust how we do things until the licensing
situation settles out and upstream projects are back to a consistent
understood licensing state.
this is where tools help!
if the License: tag is machine parsable, at least some of the "mistakes"
can be detected. It won't be perfect, but it's at least some level of
safeguard.
4:09 p.m.
On Tue, 24 Jul 2007 13:55:52 -0700
Arjan van de Ven <arjan(a)infradead.org> wrote:
this is where tools help!
if the License: tag is machine parsable, at least some of the
"mistakes" can be detected. It won't be perfect, but it's at least
some level of safeguard.
The Fedora Packaging Committee is working on exactly that. Defining a
valid set of content that can be in License so that it can be machine
parsable, or at least easy to weed out the easy cases and get a list of
things that need closer inspection.
--
Jesse Keating
Release Engineer: Fedora
4:18 p.m.
On Tue, 2007-07-24 at 13:55 -0700, Arjan van de Ven wrote:
On Tue, 2007-07-24 at 12:51 -0800, Jeff Spaleta wrote:
> I'd really like to avoid a situation where we have to start
> arbitrarily rolling back commits to clean up linking violations which
> could have been avoided through reasonable communication. As more
> individual projects who were previous under LGPL2/GPL2 start
> relicensing we may need to adjust how we do things until the licensing
> situation settles out and upstream projects are back to a consistent
> understood licensing state.
this is where tools help!
if the License: tag is machine parsable, at least some of the "mistakes"
can be detected. It won't be perfect, but it's at least some level of
safeguard.
We should be *reducing* the amount of manually-created goo[1] involved
in putting software into Fedora, not increasing it.
An automatic tool which scans the actual sources included upstream
wouldn't be difficult to write. In fact it seems very likely to already
exist, though I couldn't find something in a quick search.
Automating the checking would also allow us to catch changes
automatically.
4:21 p.m.
On Tue, 2007-07-24 at 17:18 -0400, Colin Walters wrote:
On Tue, 2007-07-24 at 13:55 -0700, Arjan van de Ven wrote:
> On Tue, 2007-07-24 at 12:51 -0800, Jeff Spaleta wrote:
>
> > I'd really like to avoid a situation where we have to start
> > arbitrarily rolling back commits to clean up linking violations which
> > could have been avoided through reasonable communication. As more
> > individual projects who were previous under LGPL2/GPL2 start
> > relicensing we may need to adjust how we do things until the licensing
> > situation settles out and upstream projects are back to a consistent
> > understood licensing state.
>
> this is where tools help!
> if the License: tag is machine parsable, at least some of the "mistakes"
> can be detected. It won't be perfect, but it's at least some level of
> safeguard.
We should be *reducing* the amount of manually-created goo[1] involved
in putting software into Fedora, not increasing it.
An automatic tool which scans the actual sources included upstream
wouldn't be difficult to write. In fact it seems very likely to already
exist, though I couldn't find something in a quick search.
when spot looked into all of our licenses before he found this was not
all that much that case. Especially when it has to look for things like
'or later' and multiple licenses per package.
-sv
4:29 p.m.
Colin Walters wrote:
An automatic tool which scans the actual sources included upstream
wouldn't be difficult to write. In fact it seems very likely to already
exist, though I couldn't find something in a quick search.
That winds up having a lot of weird caveats -- not the least of which
being things like cdrecord, which is full of additional restrictions
(thus invalidating *something*, though it's not quite clear what.)
Basically, an automatic tool is ok for finding potential problems with
the License: line, but not very good for choosing it to start with.
--
Peter
4:05 p.m.
Tomas Mraz (tmraz(a)redhat.com) said:
And I don't even see the problem with lgplv3 - we just have to
ensure
that we don't link any gplv2 only program to such library. Such as we
have to ensure that we don't link any gpl program to openssl library and
so on.
Right, but that means the LPGLv3 change just suddenly made software
we already ship undistributable. That's bad, obviously.
Bill
10:25 a.m.
On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote:
On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote:
> The automated technique is a small burden if it works for most
packages.
We already _have_ way too much bureaucracy in Fedora.
automation != bureaucracy
> Since care is taken about the license to get it into Fedora it
is
> consistent to take some care about the license after it is in... and
> with fun things like "or later" now...
Feel free to do so - Without me. Shall the "Board" (Whatever
board-de-jour we might be talking about) and the dark forces surrounding
it inside of RH do so - Without me - Period.
Dark forces? Man, I'd like to have your imagination...
I'll repeat myself, but: notifying others of license changes is only
courteous. If there is a rule to do it that way, so much for the better
-- no nasty surprises for me as the packager or developer person using
the package. If that can be assisted in an automated fashion, what is
the problem?
And Ralf, please refrain from PMs just to make comments that are way out
of line. Thanks.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
11:17 a.m.
On Mon, 2007-07-23 at 17:25 +0200, Nils Philippsen wrote:
On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote:
> On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote:
> > The automated technique is a small burden if it works for most packages.
> We already _have_ way too much bureaucracy in Fedora.
automation != bureaucracy
Which automation are you referring to?
The merger with Core (==RH) hasn't brought automation, it has caused
more bureaucracy and further regressions to contributors.
Ralf
8:56 a.m.
On Tue, 2007-07-24 at 18:17 +0200, Ralf Corsepius wrote:
On Mon, 2007-07-23 at 17:25 +0200, Nils Philippsen wrote:
> On Mon, 2007-07-23 at 09:10 +0200, Ralf Corsepius wrote:
> > On Mon, 2007-07-23 at 07:33 +0100, Andy Green wrote:
>
> > > The automated technique is a small burden if it works for most packages.
> > We already _have_ way too much bureaucracy in Fedora.
>
> automation != bureaucracy
Which automation are you referring to?
The merger with Core (==RH) hasn't brought automation, it has caused
more bureaucracy and further regressions to contributors.
Sorry for the late reply. Talking about the merger, you're drifting off
into a totally different area here that's been discussed to death
already.
Andy was talking about the plan that we should be able to automatically
(== with tools) check licenses of the packages because it would reduce
the burden on the maintainers which should only be in your interest.
It's out of the question that we need to ensure that what we distribute
is properly licensed. Requiring that every package maintainer regularly
checks for license changes in components required by his packages would
be a stupid waste of resources. It's much better that maintainers are
responsible to inform people if the license of one of their packages
(which might be used by other packages) changes.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
10:58 a.m.
On 7/22/07, Ralf Corsepius <rc040203(a)freenet.de> wrote:
If you think so, I disagree. You are driving away contributors from
fedora, by imposing more and more bureaucracy. If you really want this
YOU (Jef Spaleta in person) will have to do it yourselves.
I am watching for upstream licensing changes in about as many places
as I can think to look. But I am only two people... two very stupid
people, with a reading comprehension problem.
And please, I sincerely would like to hear off-list from any
contributors( other than Ralf) who are being driven away from fedora
because of the request to keep the rest of the contributor pool
informed of re-licensing issues.
I realize that every policy decision has an implementation cost. But
given the importance of licensing to the overall availability of the
software repository, I don't think the request to keep the maintainer
pool informed is over-burdensome. I very much would like to avoid
getting into a situation where a serious re-licensing issues
necessitates a major disruption in workflow for everyone who currently
uses cvs commit access. I'm not much of a gambler, so given the
choice I'd rather encourage a proactive approach to the initial season
of gpl3 re-licensing, then to wait to be reactive to a licensing
problem after it appears inside our software repository.
I'd absolutely love it if we could all collectively bury our heads in
the sand as upstream codebases choose to re-license under gpl3. I'd
love it if we could all be free to be irresponsible. But we can't, the
continued availability of the software repository and build system
depends on making sure we don't inadvertently introduce licensing
violations. The only way we are going to avoid problems, especially
with violations concerning library linking, is if we, as a community
of peers, communicate re-licensing issues before they enter our
repository.
-jef"death eater's local #205"spaleta
2:46 p.m.
On Fri, 2007-07-20 at 22:32 -0800, Jeff Spaleta wrote:
-jef"I shot a baby moose standing no futher than 6 feet away
from me
in my yard yesterday. It shot it with a Nikon D200, through my front
window..several seconds after i peed my pants from the shock of
opening the window blinds to stare into the eyes of the large pony-ish
form in my yard"spaleta.
I want to see that. The baby moose that is, not Jef peeing his
pants ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
2:48 p.m.
On Sat, 2007-07-21 at 07:30 +0200, Ralf Corsepius wrote:
On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote:
> The Fedora Engineering Steering Committee would like to remind maintainers
> that a license change in a package is a very serious event - it has as many,
> if not more, implications for related packages as ABI changes do.
>
> Therefore, if your package changes license, even if it just changes the
> license version, it is required that you announce it, whether on this list
> or fedora-devel-list.
Yet more bureaucrazy.
> Please contact FESCo if you have any questions.
So, the new FESCo is going to act as the "Fedora License Police"
Sorry, but I can't deny to consider this development unhelpful.
FESCo felt the need to codify something which should be a matter of
common courtesy. I wonder why that's the case (no I don't really).
I for my part find this very helpful because it works against some lib
or other dependency drawn away from under my feet due to a non-announced
licence change.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
2:53 p.m.
On Sat, 21 Jul 2007 21:48:59 +0200
Nils Philippsen <nphilipp(a)redhat.com> wrote:
On Sat, 2007-07-21 at 07:30 +0200, Ralf Corsepius wrote:
> On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote:
> > The Fedora Engineering Steering Committee would like to remind
> > maintainers that a license change in a package is a very serious
> > event - it has as many, if not more, implications for related
> > packages as ABI changes do.
> >
> > Therefore, if your package changes license, even if it just
> > changes the license version, it is required that you announce it,
> > whether on this list or fedora-devel-list.
> Yet more bureaucrazy.
>
> > Please contact FESCo if you have any questions.
> So, the new FESCo is going to act as the "Fedora License Police"
>
> Sorry, but I can't deny to consider this development unhelpful.
FESCo felt the need to codify something which should be a matter of
The Board felt the need. FESCo is just trying to figure out how to do
that.
josh
2:58 p.m.
On Sat, 2007-07-21 at 14:53 -0500, Josh Boyer wrote:
On Sat, 21 Jul 2007 21:48:59 +0200
Nils Philippsen <nphilipp(a)redhat.com> wrote:
> On Sat, 2007-07-21 at 07:30 +0200, Ralf Corsepius wrote:
> > On Thu, 2007-07-19 at 14:45 -0400, Bill Nottingham wrote:
> > > The Fedora Engineering Steering Committee would like to remind
> > > maintainers that a license change in a package is a very serious
> > > event - it has as many, if not more, implications for related
> > > packages as ABI changes do.
> > >
> > > Therefore, if your package changes license, even if it just
> > > changes the license version, it is required that you announce it,
> > > whether on this list or fedora-devel-list.
> > Yet more bureaucrazy.
> >
> > > Please contact FESCo if you have any questions.
> > So, the new FESCo is going to act as the "Fedora License Police"
> >
> > Sorry, but I can't deny to consider this development unhelpful.
>
> FESCo felt the need to codify something which should be a matter of
The Board felt the need. FESCo is just trying to figure out how to do
that.
Whoever did it ;-) felt the need to do it and I think with reason.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
5:25 p.m.
New subject: [LICENSE CHANGE] emelfm2-0.3.5-1 (was Re: NOTE: Please publicize any license changes to your packages)
Am Donnerstag, den 19.07.2007, 14:45 -0400 schrieb Bill Nottingham:
The Fedora Engineering Steering Committee would like to remind
maintainers
that a license change in a package is a very serious event - it has as many,
if not more, implications for related packages as ABI changes do.
Therefore, if your package changes license, even if it just changes the
license version, it is required that you announce it, whether on this list
or fedora-devel-list.
emelfm2's license changed from GPL v.2 to v.3 in emelfm2 0.3.5. Sorry
that I didn't announce this earlier, because it's already in rawhide and
updates-testing.
Christoph
11:59 a.m.
New subject: [LICENSE CHANGE] emelfm2-0.3.5-1 (was Re: NOTE: Please publicize any license changes to your packages)
Christoph Wickert (christoph.wickert(a)nurfuerspam.de) said:
Am Donnerstag, den 19.07.2007, 14:45 -0400 schrieb Bill Nottingham:
> The Fedora Engineering Steering Committee would like to remind maintainers
> that a license change in a package is a very serious event - it has as many,
> if not more, implications for related packages as ABI changes do.
>
> Therefore, if your package changes license, even if it just changes the
> license version, it is required that you announce it, whether on this list
> or fedora-devel-list.
emelfm2's license changed from GPL v.2 to v.3 in emelfm2 0.3.5. Sorry
that I didn't announce this earlier, because it's already in rawhide and
updates-testing.
Doesn't seem to provide any libraries, so it's safe in that regard.
Bill
6106
days inactive
6124
days old
71 comments
28 participants
participants (28)
-
Andy Green -
Arjan van de Ven -
Bill Nottingham -
Brian Pepple -
Chris Adams -
Christoph Wickert -
Chuck Anderson -
Colin Walters -
David Cantrell -
Fabio Comolli -
Horst H. von Brand -
Jakub Jelinek -
Jef Spaleta -
Jesse Keating -
Jima -
Josh Boyer -
Miloslav Trmač -
Nicolas Mailhot -
Nils Philippsen -
Peter Jones -
Ralf Corsepius -
Ralf Ertzinger -
Rex Dieter -
seth vidal -
Simo Sorce -
Thorsten Leemhuis -
Tomas Mraz -
Toshio Kuratomi