Re: [Sugar-devel] Full Licence field

[Bill Crawford]

On Tuesday 24 March 2009 10:26:23 Panu Matilainen wrote:

> Hmm okay, any user being able to modivy rpm -V behavior is not exactly
> good, although timestamp verify is pretty feeble business (considering rpm
> doesnt raise conflicts on timestamp differences).

If it's shared, then it should at least verify that the timestamp matches ONE 
OF 
the packages it's shared between :o)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Panu Matilainen]

On Tue, 24 Mar 2009, Jakub Jelinek wrote:

> On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
>>> Basically, have rpm -V ignore timestamp verification on %license files.
>>
>> Make that "have rpm -V ignore timestamp verification on files whose
>> hardlink count is > 1". That's reasonably in line with how rpm -V
>> currently treats files shared among multiple packages and makes
>> hardlink-on-content verification-friendly for any files, and without
>> making licenses a totally oddball special case in verify.
>
> gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
> these I'd prefer if the timestamp verification was done. Also,
> if e.g. /tmp is on the same filesystem as /bin, any user can do
> ln -f /bin/login /tmp/abcdefg
> and avoid timestamp verification of /bin/login on subsequent rpm -V.

Hmm okay, any user being able to modivy rpm -V behavior is not exactly 
good, although timestamp verify is pretty feeble business (considering rpm 
doesnt raise conflicts on timestamp differences).

I just seriously dislike the idea of making license files somehow highly 
special with different rules to everything else, when we're basically 
talking about "files hardlinked outside of packaging".

>>> Then, upon install, if there is already another %license file present
>>> with identical {md5,sha{256,512}} sum and size installed and if so, do a
>>> byte by byte comparison and hardlink the files if they are indeed identical.
>>>
>>> I'm not sure whether that overcomplicates the transaction or not (also,
>>> removal would probably need to make sure we didn't leave a package
>>> without a license text).
>
> A removal of a hardlink just decreases the link count, so as long as there
> is at least once license file, it won't be erased.
>
>> And on every upgrade check that hardlinked files are still shareable and
>> if not undo hardlinks... eww. Sounds like a whole lotta trouble for very
>> little gain.
>
> I thought rpm doesn't overwrite files, but instead unpacks them under a
> temporary name and renames them over.  Which would mean after rename it
> would be no longer a hardlink, so no need to undo hardlinks in any way.

Duh, indeed. I'm not thinking straight :)

- Panu -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Ralf Corsepius]

Jakub Jelinek wrote:
> On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
>>> Basically, have rpm -V ignore timestamp verification on %license files.
>> Make that "have rpm -V ignore timestamp verification on files whose  
>> hardlink count is > 1". That's reasonably in line with how rpm -V  
>> currently treats files shared among multiple packages and makes  
>> hardlink-on-content verification-friendly for any files, and without  
>> making licenses a totally oddball special case in verify.
> 
> gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
> these I'd prefer if the timestamp verification was done. 
What for?

You seem to be forgetting that files system are not read-only. Any user 
has the liberty to "move/copy" around files or "touch" them.

What you really want is "identical contents", not matching timestamps.

Ralf
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Simon Schampijer]

Kevin Kofler wrote:
> Simon Schampijer wrote:
>> So, the point to ship a license per package is fine. I actually did not
>> want to relax that. I had the technical problem to need to access the
>> license field to be able to display it in a dialog inside Sugar.
>>
>> http://shell.sugarlabs.org/~erikos/licence_field.png
>>
>> And since - the file is placed in different places on each distro I
>> wanted to see if a common place would be possible, makes sense. On
>> Fedora this could have been in addition to the per package license
>> field. Not very economic of course.
> 
> FWIW, KDE does exactly that.
> 
> /usr/share/kde4/apps/LICENSES/ (where /usr/share/kde4/apps is the KDE 4
> application data directory, it can vary from distribution to distribution)
> contains the following files (owned by kdelibs):
> ARTISTIC  BSD   GPL_V2GPL_V3LGPL_V2   LGPL_V3   QPL_V1.0
> The KAboutData class in kdelibs provides an enum which allows you to pick
> one of these licenses. If the license is not one of those, the application
> is responsible for loading the exact text of the license explicitly.
> 
>> Anyhow - while thinking about it, I was not even sure the displaying of
>> the full license is correct/needed - or matches the guidelines. For
>> example I have not seen something similar in GNOME.
> 
> KDE does it. (Try "Help / About (application name)" in a KDE application.
> The name of the license is a link, clicking that link opens a dialog box
> with the full text of the license.)
> 
> It's not a bad idea, but it isn't strictly needed either. (There are plenty
> of GPLed applications which don't display the full text of the GPL in the
> UI.)
> 
> Kevin Kofler

Ok, I have placed it now to the sugar data dir so it is accessible on 
each platform/distribution the same way. As Sugar is likely getting into 
areas where people are not that familiar with open source software it is 
maybe a good thing to strengthen it out in the UI as well. I think that 
was part of the idea behind it when done by OLPC.

Thanks for your thoughts,
Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Jakub Jelinek]

On Tue, Mar 24, 2009 at 10:07:30AM +0200, Panu Matilainen wrote:
>> Basically, have rpm -V ignore timestamp verification on %license files.
>
> Make that "have rpm -V ignore timestamp verification on files whose  
> hardlink count is > 1". That's reasonably in line with how rpm -V  
> currently treats files shared among multiple packages and makes  
> hardlink-on-content verification-friendly for any files, and without  
> making licenses a totally oddball special case in verify.

gcc contains hardlinks (e.g. /usr/bin/{,x86_64-redhat-linux-}gcc) and for
these I'd prefer if the timestamp verification was done.  Also,
if e.g. /tmp is on the same filesystem as /bin, any user can do
ln -f /bin/login /tmp/abcdefg
and avoid timestamp verification of /bin/login on subsequent rpm -V.

>> Then, upon install, if there is already another %license file present
>> with identical {md5,sha{256,512}} sum and size installed and if so, do a
>> byte by byte comparison and hardlink the files if they are indeed identical.
>>
>> I'm not sure whether that overcomplicates the transaction or not (also,
>> removal would probably need to make sure we didn't leave a package
>> without a license text).

A removal of a hardlink just decreases the link count, so as long as there
is at least once license file, it won't be erased.

> And on every upgrade check that hardlinked files are still shareable and 
> if not undo hardlinks... eww. Sounds like a whole lotta trouble for very 
> little gain.

I thought rpm doesn't overwrite files, but instead unpacks them under a
temporary name and renames them over.  Which would mean after rename it
would be no longer a hardlink, so no need to undo hardlinks in any way.

Jakub
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Panu Matilainen]

On Mon, 23 Mar 2009, Tom \spot\ Callaway wrote:

> On 03/22/2009 05:18 AM, Panu Matilainen wrote:
>
>> Heh, actually rpm has had %license special file attribute since rpm
>> 2.5.4, it just doesn't really do much anything at all. It also doesn't
>> play well together with %doc, AND since the ancient copyright -> license
>> tag change, %license as file attribute has gotten globbered with
>> side-effect macro from the License: tag, so you'll have to use %%license
>> in the %files section.
>>
>> Other than that, making --excludedocs not affect %license files is
>> literally a one-liner.
>>
>> Making %license use in spec saner is somewhat more complicated (due to
>> the funny little historical issues listed above). I take it you'd like
>> it to behave exactly like %doc, like
>>
>> %files
>> %doc README NEWS ChangeLog
>> %license COPYING
>> %{_bindir}/*
>>
>> ...which would place COPYING into the default docdir, but with the
>> license attribute set. Right?
>
> Yes, this is almost exactly what I would think would be ideal.

Ok.

> (Yes, it requires a rebuild, but I far prefer being able to mark the 
> license files rather than have some heuristic guess and get it wrong 
> repeatedly).

Yup, magic runtime pattern matching aint going work and aint going to 
happen.

> The only thing I would want on top of that is what Jakub proposed
> earlier in the thread:
>
> Basically, have rpm -V ignore timestamp verification on %license files.

Make that "have rpm -V ignore timestamp verification on files whose 
hardlink count is > 1". That's reasonably in line with how rpm -V 
currently treats files shared among multiple packages and makes 
hardlink-on-content verification-friendly for any files, and without 
making licenses a totally oddball special case in verify.

> Then, upon install, if there is already another %license file present
> with identical {md5,sha{256,512}} sum and size installed and if so, do a
> byte by byte comparison and hardlink the files if they are indeed identical.
>
> I'm not sure whether that overcomplicates the transaction or not (also,
> removal would probably need to make sure we didn't leave a package
> without a license text).

And on every upgrade check that hardlinked files are still shareable 
and if not undo hardlinks... eww. Sounds like a whole lotta trouble for 
very little gain.

- Panu -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Ralf Corsepius]

Jakub Jelinek wrote:
> On Sat, Mar 21, 2009 at 04:58:11AM +0100, Ralf Corsepius wrote:
>> Tom "spot" Callaway wrote:
>>> Now, if there were a clever way to handle this behind the scenes so that
>>> these license files were not duplicated if they were identical, but
>>> instead, symlinked to the license files in a generic license rpm, I
>>> might be more interested. (If they weren't bit for bit identical, it
>>> wouldn't be symlinked).
>> /usr/sbin/hardlink -c /usr/share/doc
>> is pretty close to what you want.
> 
> Yes, but if you have %license support in rpm where all %license files
> would
> 1) not be excluded with --excludedocs
Right.

> 2) for rpm -V ignore timestamp verification
Timestamps are irrelevant, because you want to merge files with 
identical contents.

b) license-wise irrelevant - Contents matters, not timestamps.

c) Generally irrelevant in rpm.

Ralf
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Tom "spot" Callaway]

On 03/22/2009 05:18 AM, Panu Matilainen wrote:

> Heh, actually rpm has had %license special file attribute since rpm
> 2.5.4, it just doesn't really do much anything at all. It also doesn't
> play well together with %doc, AND since the ancient copyright -> license
> tag change, %license as file attribute has gotten globbered with
> side-effect macro from the License: tag, so you'll have to use %%license
> in the %files section.
> 
> Other than that, making --excludedocs not affect %license files is
> literally a one-liner.
> 
> Making %license use in spec saner is somewhat more complicated (due to
> the funny little historical issues listed above). I take it you'd like
> it to behave exactly like %doc, like
> 
> %files
> %doc README NEWS ChangeLog
> %license COPYING
> %{_bindir}/*
> 
> ...which would place COPYING into the default docdir, but with the
> license attribute set. Right?

Yes, this is almost exactly what I would think would be ideal. (Yes, it
requires a rebuild, but I far prefer being able to mark the license
files rather than have some heuristic guess and get it wrong repeatedly).

The only thing I would want on top of that is what Jakub proposed
earlier in the thread:

Basically, have rpm -V ignore timestamp verification on %license files.
Then, upon install, if there is already another %license file present
with identical {md5,sha{256,512}} sum and size installed and if so, do a
byte by byte comparison and hardlink the files if they are indeed identical.

I'm not sure whether that overcomplicates the transaction or not (also,
removal would probably need to make sure we didn't leave a package
without a license text).

~spot
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Panu Matilainen]

On Fri, 20 Mar 2009, Tom \spot\ Callaway wrote:

> On 03/20/2009 04:06 PM, Lyos Gemini Norezel wrote:
>> Pity. A %license (ie., like the %doc) field would be nice to have.
>
> Indeed. This is where I think the most interesting work needs to be
> done. Once rpm knows that a %license file is a special type of %doc that
> gets installed even if --excludedocs is passed, we have solved one of
> the big issues for the OLPC folks.

Heh, actually rpm has had %license special file attribute since rpm 2.5.4, 
it just doesn't really do much anything at all. It also doesn't play well 
together with %doc, AND since the ancient copyright -> license tag change, 
%license as file attribute has gotten globbered with side-effect macro 
from the License: tag, so you'll have to use %%license in the %files 
section.

Other than that, making --excludedocs not affect %license files is 
literally a one-liner.

Making %license use in spec saner is somewhat more complicated (due to the 
funny little historical issues listed above). I take it you'd like it to 
behave exactly like %doc, like

%files
%doc README NEWS ChangeLog
%license COPYING
%{_bindir}/*

...which would place COPYING into the default docdir, but with the license 
attribute set. Right?

- Panu -
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Jakub Jelinek]

On Sat, Mar 21, 2009 at 04:58:11AM +0100, Ralf Corsepius wrote:
> Tom "spot" Callaway wrote:
>> Now, if there were a clever way to handle this behind the scenes so that
>> these license files were not duplicated if they were identical, but
>> instead, symlinked to the license files in a generic license rpm, I
>> might be more interested. (If they weren't bit for bit identical, it
>> wouldn't be symlinked).
>
> /usr/sbin/hardlink -c /usr/share/doc
> is pretty close to what you want.

Yes, but if you have %license support in rpm where all %license files
would
1) not be excluded with --excludedocs
2) for rpm -V ignore timestamp verification
rpm could just cheaply look up if there is already some %license file
with identical {md5,sha{256,512}} sum and size installed and if so, do
a byte by byte comparison and hardlink the files if they are indeed identical.

Jakub
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Ralf Corsepius]

Tom "spot" Callaway wrote:
> Now, if there were a clever way to handle this behind the scenes so that
> these license files were not duplicated if they were identical, but
> instead, symlinked to the license files in a generic license rpm, I
> might be more interested. (If they weren't bit for bit identical, it
> wouldn't be symlinked).

/usr/sbin/hardlink -c /usr/share/doc
is pretty close to what you want.

Ralf


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Tom "spot" Callaway]

On 03/20/2009 04:06 PM, Lyos Gemini Norezel wrote:
> Pity. A %license (ie., like the %doc) field would be nice to have.

Indeed. This is where I think the most interesting work needs to be
done. Once rpm knows that a %license file is a special type of %doc that
gets installed even if --excludedocs is passed, we have solved one of
the big issues for the OLPC folks.

>> * Compare it against the set of known "Generic" licenses.
>> * If it is an exact match, replace it with a symlink to the Generic
>> license.
>>
>> Now, the problem is that if you do this in yum, you'll break rpm
>> verification of any package handled in such a way. 
> 
> Oh? Why is that?

Well, in order for this to work, the license text has to be a real file
in the binary RPM manifest. If yum replaced that actual file with a
symlink, it will no longer match the binary RPM manifest, and rpm -V
will report that the file has been changed (which, is true, but of
little relevance in such a scenario).

~spot
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Lyos Gemini Norezel]

Tom "spot" Callaway wrote:

On 03/20/2009 03:38 PM, Lyos Gemini Norezel wrote:
  

Isn't it possible to figure that out with a bit of bash programming?
Eg., use the 'comm' command.
"comm Compare two sorted files line by line"

and, if different, a diff could be generated to show you exactly what's
different.

Doesn't seem like much of a hassle to me.



Are you volunteering to do the work then?

  


I'm not much of a bash programmer (or any kind of programmer, really...
last time I could, legitimately, call myself a programmer was back in 
the 8086,
6502, etc ASM days), but I'd be willing to give it a shot if there 
is/would be

enough interest in such a tool.

If I had infrastructure support, I could even help setup the script to email
you the diffs when needed, provided such a script is setup on the koji 
boxen.



How difficult would it be to add functionality in yum:
a.) to store the license value of each program, and
b.) to integrate a license reader for easy access/reading?



I'm going to go out on a limb and say this isn't what we want. It will
just bloat the yum metadata for a rather minimal benefit.

  


Perhaps yum could store the values in a text/db file that another program
(say %license_reader) could import?


Returning to the original problem, I'd rather see a transaction workflow
like this:

* Look at what a package has marked as a 'license file' (NOTE: RPM
doesn't really have support for this yet)
  


Pity. A %license (ie., like the %doc) field would be nice to have.


* Compare it against the set of known "Generic" licenses.
* If it is an exact match, replace it with a symlink to the Generic license.

Now, the problem is that if you do this in yum, you'll break rpm
verification of any package handled in such a way. 


Oh? Why is that?


It might be possible to have RPM do this automagically, but I suspect they'd 
think it is a
monstrous hack. There are RPM devs lurking on this list, I wonder if they will 
chime in.
  


I'd like to hear their thoughts on this, too.


Lyos Gemini Norezel
begin:vcard
fn:Lyos Norezel
n:Norezel;Lyos
org:GBES, LLC
adr:Ohio;;United States
email;internet:lyos.gemininore...@gmail.com
title:Computer Repair Technician
note;quoted-printable:"Those who hunt monsters beware, lest they become monsters themselves.Ify=
	ou stare long into the abyss, the abyss stares back into you." --Nietzsch=
	e=0D=0A=
	=0D=0A=
	Mundus Vult Decipi et Decipiatur -- Latin Proverb
version:2.1
end:vcard

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Tom "spot" Callaway]

On 03/20/2009 03:38 PM, Lyos Gemini Norezel wrote:
> Isn't it possible to figure that out with a bit of bash programming?
> Eg., use the 'comm' command.
> "comm Compare two sorted files line by line"
> 
> and, if different, a diff could be generated to show you exactly what's
> different.
> 
> Doesn't seem like much of a hassle to me.

Are you volunteering to do the work then?

> How difficult would it be to add functionality in yum:
> a.) to store the license value of each program, and
> b.) to integrate a license reader for easy access/reading?

I'm going to go out on a limb and say this isn't what we want. It will
just bloat the yum metadata for a rather minimal benefit.

Returning to the original problem, I'd rather see a transaction workflow
like this:

* Look at what a package has marked as a 'license file' (NOTE: RPM
doesn't really have support for this yet)
* Compare it against the set of known "Generic" licenses.
* If it is an exact match, replace it with a symlink to the Generic license.

Now, the problem is that if you do this in yum, you'll break rpm
verification of any package handled in such a way. It might be possible
to have RPM do this automagically, but I suspect they'd think it is a
monstrous hack. There are RPM devs lurking on this list, I wonder if
they will chime in.

~spot
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Lyos Gemini Norezel]

Tom "spot" Callaway wrote:

On 03/20/2009 08:52 AM, Lyos Gemini Norezel wrote:

  

Maybe it's because I'm not a lawyer, that I fail to see the problem with
that. As long as there exists some reference to the license and a location
where it can be read, doesn't that meet the requirements of those licenses?



The short answer is not really. The more assumptions we make, the
farther we get from reality, and for the majority of FOSS licenses, we
(Fedora/Red Hat) bear the burden of informing the user of the licensing
terms of the software that we are distributing.

Here is a common scenario:

The upstream for a package changes licensing from GPL to LGPL. If we are
using a generic-licenses package, we are far less likely to notice this
change, whereas, we would immediately notice that COPYING was replaced
with COPYING.LIBS.
  


That would be the package maintainers responsibility, no? If a change is 
that dramatic,
wouldn't the maintainer notice it right away? (I see alot of emails 
about packages changing

licensing)


Wasn't there a discussion, somewhat recently, about libraries that are
shipped with the program instead
of being stored in /lib or /usr/lib?



This is notably different. The licensing is part of our legal obligation
to our users and downstream consumers.

  


I understand that, but how is a change of license file location going to 
change,

or cause problems with, that obligation?

The licenses would still be available for the user to read, if they 
desire, and this change

won't really inconvenience anyone.


In addition, this comes out to about 17 MB. It is not a huge amount of
disk space, and certainly not worth the rather additional hassle it
would cause.
  


In reality, a change like this really should be pushed to FHS.
Standardizing the %License_File location just makes good common sense.


As it is now, each package maintainer is responsible for keeping the
license text as provided by upstream in the package, and the License tag
correct. If we were to generalize this into a central package, we'd have
to do constant auditing to be sure that the license text in the
generalized "LICENSE.rpm" exactly matched that of the package. And by
we, I mean me. Even if Red Hat Legal signed off on such an arrangement,
I'm not really thrilled by this prospect.

Now, if there were a clever way to handle this behind the scenes so that
these license files were not duplicated if they were identical, but
instead, symlinked to the license files in a generic license rpm, I
might be more interested. (If they weren't bit for bit identical, it
wouldn't be symlinked).

  


Isn't it possible to figure that out with a bit of bash programming?
Eg., use the 'comm' command.
"comm Compare two sorted files line by line"

and, if different, a diff could be generated to show you exactly what's 
different.


Doesn't seem like much of a hassle to me.

How difficult would it be to add functionality in yum:
a.) to store the license value of each program, and
b.) to integrate a license reader for easy access/reading?


~spot


Lyos Gemini Norezel
begin:vcard
fn:Lyos Norezel
n:Norezel;Lyos
org:GBES, LLC
adr:Ohio;;United States
email;internet:lyos.gemininore...@gmail.com
title:Computer Repair Technician
note;quoted-printable:"Those who hunt monsters beware, lest they become monsters themselves.Ify=
	ou stare long into the abyss, the abyss stares back into you." --Nietzsch=
	e=0D=0A=
	=0D=0A=
	Mundus Vult Decipi et Decipiatur -- Latin Proverb
version:2.1
end:vcard

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Lyos Gemini Norezel]

Tom "spot" Callaway wrote:

On 03/18/2009 03:45 PM, Kevin Kofler wrote:
  

Simon Schampijer wrote:


Yes. So the main question is now if Fedora would be willing to ship
general licenses under /usr/share/common-licenses, I think.
  


I really don't want to do this. Here's why:

A) Many copyright holders make minor modifications to the licensing
terms. These modifications usually do not affect the rights granted by
the license (which is why we do not mark them as distinct and individual
licenses), 


Perhaps this is a mistake on our part?


but it would be incorrect to have these packages pointing to
general license texts when those do not apply.
  





B) Many licenses require that any distribution include the license text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.
  


Maybe it's because I'm not a lawyer, that I fail to see the problem with 
that.
As long as there exists some reference to the license and a location 
where it can be read,

doesn't that meet the requirements of those licenses?

It seems awfully wasteful carrying a million or more copies of the same 
blasted license file,

in a million or more locations in the OS.

Wasn't there a discussion, somewhat recently, about libraries that are 
shipped with the program instead

of being stored in /lib or /usr/lib?

Seems, to me, the arguments used to store such files in a *COMMON 
LOCATION* can, and should, be

used here.

Or has common sense been thrown out the window?

Lyos Gemini Norezel
begin:vcard
fn:Lyos Norezel
n:Norezel;Lyos
org:GBES, LLC
adr:Ohio;;United States
email;internet:lyos.gemininore...@gmail.com
title:Computer Repair Technician
note;quoted-printable:"Those who hunt monsters beware, lest they become monsters themselves.Ify=
	ou stare long into the abyss, the abyss stares back into you." --Nietzsch=
	e=0D=0A=
	=0D=0A=
	Mundus Vult Decipi et Decipiatur -- Latin Proverb
version:2.1
end:vcard

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Tom "spot" Callaway]

On 03/20/2009 08:52 AM, Lyos Gemini Norezel wrote:

> Maybe it's because I'm not a lawyer, that I fail to see the problem with
> that. As long as there exists some reference to the license and a location
> where it can be read, doesn't that meet the requirements of those licenses?

The short answer is not really. The more assumptions we make, the
farther we get from reality, and for the majority of FOSS licenses, we
(Fedora/Red Hat) bear the burden of informing the user of the licensing
terms of the software that we are distributing.

Here is a common scenario:

The upstream for a package changes licensing from GPL to LGPL. If we are
using a generic-licenses package, we are far less likely to notice this
change, whereas, we would immediately notice that COPYING was replaced
with COPYING.LIBS.

> Wasn't there a discussion, somewhat recently, about libraries that are
> shipped with the program instead
> of being stored in /lib or /usr/lib?

This is notably different. The licensing is part of our legal obligation
to our users and downstream consumers.

In addition, this comes out to about 17 MB. It is not a huge amount of
disk space, and certainly not worth the rather additional hassle it
would cause.

As it is now, each package maintainer is responsible for keeping the
license text as provided by upstream in the package, and the License tag
correct. If we were to generalize this into a central package, we'd have
to do constant auditing to be sure that the license text in the
generalized "LICENSE.rpm" exactly matched that of the package. And by
we, I mean me. Even if Red Hat Legal signed off on such an arrangement,
I'm not really thrilled by this prospect.

Now, if there were a clever way to handle this behind the scenes so that
these license files were not duplicated if they were identical, but
instead, symlinked to the license files in a generic license rpm, I
might be more interested. (If they weren't bit for bit identical, it
wouldn't be symlinked).

~spot
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Kevin Kofler]

Simon Schampijer wrote:
> So, the point to ship a license per package is fine. I actually did not
> want to relax that. I had the technical problem to need to access the
> license field to be able to display it in a dialog inside Sugar.
> 
> http://shell.sugarlabs.org/~erikos/licence_field.png
> 
> And since - the file is placed in different places on each distro I
> wanted to see if a common place would be possible, makes sense. On
> Fedora this could have been in addition to the per package license
> field. Not very economic of course.

FWIW, KDE does exactly that.

/usr/share/kde4/apps/LICENSES/ (where /usr/share/kde4/apps is the KDE 4
application data directory, it can vary from distribution to distribution)
contains the following files (owned by kdelibs):
ARTISTIC  BSD   GPL_V2GPL_V3LGPL_V2   LGPL_V3   QPL_V1.0
The KAboutData class in kdelibs provides an enum which allows you to pick
one of these licenses. If the license is not one of those, the application
is responsible for loading the exact text of the license explicitly.

> Anyhow - while thinking about it, I was not even sure the displaying of
> the full license is correct/needed - or matches the guidelines. For
> example I have not seen something similar in GNOME.

KDE does it. (Try "Help / About (application name)" in a KDE application.
The name of the license is a link, clicking that link opens a dialog box
with the full text of the license.)

It's not a bad idea, but it isn't strictly needed either. (There are plenty
of GPLed applications which don't display the full text of the GPL in the
UI.)

Kevin Kofler

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Simon Schampijer]

Tom "spot" Callaway wrote:
> On 03/18/2009 03:45 PM, Kevin Kofler wrote:
>> Simon Schampijer wrote:
>>> Yes. So the main question is now if Fedora would be willing to ship
>>> general licenses under /usr/share/common-licenses, I think.
> 
> I really don't want to do this. Here's why:
> 
> A) Many copyright holders make minor modifications to the licensing
> terms. These modifications usually do not affect the rights granted by
> the license (which is why we do not mark them as distinct and individual
> licenses), but it would be incorrect to have these packages pointing to
> general license texts when those do not apply.
> 
> B) Many licenses require that any distribution include the license text.
> Red Hat Legal was very uncomfortable with us using a rpm dependency to
> meet that requirement.
> 
> What I do think we were looking at doing is having rpm mark %license
> texts in a unique way that is different from %doc. This would permit rpm
> --excludedocs but retain the license texts.
> 
> ~spot

So, the point to ship a license per package is fine. I actually did not 
want to relax that. I had the technical problem to need to access the 
license field to be able to display it in a dialog inside Sugar.

http://shell.sugarlabs.org/~erikos/licence_field.png

And since - the file is placed in different places on each distro I 
wanted to see if a common place would be possible, makes sense. On 
Fedora this could have been in addition to the per package license 
field. Not very economic of course.

Anyhow - while thinking about it, I was not even sure the displaying of 
the full license is correct/needed - or matches the guidelines. For 
example I have not seen something similar in GNOME.

Maybe someone from Fedora that has more insights on those legal issues 
can comment what they want/need to see in such a page for Sugar on Fedora.

Thanks,
Simon

PS: Of course, thanks for all the interesting comments about compressing 
the files etc to gain some space.

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Sean DALY]

Questions like these are bread and butter for the SFC.


On Wed, Mar 18, 2009 at 10:24 PM, Walter Bender  wrote:
> On Wed, Mar 18, 2009 at 4:44 PM, David Malcolm  wrote:
>>
>> On Wed, 2009-03-18 at 16:00 -0400, Tom "spot" Callaway wrote:
>>> On 03/18/2009 03:45 PM, Kevin Kofler wrote:
>>> > Simon Schampijer wrote:
>>> >> Yes. So the main question is now if Fedora would be willing to ship
>>> >> general licenses under /usr/share/common-licenses, I think.
>>>
>>> I really don't want to do this. Here's why:
>>>
>>> A) Many copyright holders make minor modifications to the licensing
>>> terms. These modifications usually do not affect the rights granted by
>>> the license (which is why we do not mark them as distinct and individual
>>> licenses), but it would be incorrect to have these packages pointing to
>>> general license texts when those do not apply.
>>>
>>> B) Many licenses require that any distribution include the license text.
>>> Red Hat Legal was very uncomfortable with us using a rpm dependency to
>>> meet that requirement.
>>>
>>> What I do think we were looking at doing is having rpm mark %license
>>> texts in a unique way that is different from %doc. This would permit rpm
>>> --excludedocs but retain the license texts.
>>>
>> Thinking aloud, a couple of other approaches:
>>  (i) Embed the SHA256 checksum of each license into the path e.g.:
>> /usr/share/common-licenses/32b1062f7da84967e7019d01ab805935caa7ab7321a7ced0e30ebe75e5df1670/COPYING
>> then have each file's identical implementation of those bytes overwrite
>> each other, and you might have many packages owning that path on the
>> installed system.  Slight modifications thus lead to different paths.
>>
>> That way you still have duplicates in the .rpm files, but an installed
>> system has just one copy of each, and each rpm does indeed ship the
>> precise license it's required to.
>>
>> I suspect that the arguments from crypto and from the legal side will
>> "pass through one another like angry ghosts", though (and legal thus
>> wins).
>
> What a nice idea.
>
>>  (ii) Compress the licenses?
>>
>>
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Walter Bender]

On Wed, Mar 18, 2009 at 4:44 PM, David Malcolm  wrote:
>
> On Wed, 2009-03-18 at 16:00 -0400, Tom "spot" Callaway wrote:
>> On 03/18/2009 03:45 PM, Kevin Kofler wrote:
>> > Simon Schampijer wrote:
>> >> Yes. So the main question is now if Fedora would be willing to ship
>> >> general licenses under /usr/share/common-licenses, I think.
>>
>> I really don't want to do this. Here's why:
>>
>> A) Many copyright holders make minor modifications to the licensing
>> terms. These modifications usually do not affect the rights granted by
>> the license (which is why we do not mark them as distinct and individual
>> licenses), but it would be incorrect to have these packages pointing to
>> general license texts when those do not apply.
>>
>> B) Many licenses require that any distribution include the license text.
>> Red Hat Legal was very uncomfortable with us using a rpm dependency to
>> meet that requirement.
>>
>> What I do think we were looking at doing is having rpm mark %license
>> texts in a unique way that is different from %doc. This would permit rpm
>> --excludedocs but retain the license texts.
>>
> Thinking aloud, a couple of other approaches:
>  (i) Embed the SHA256 checksum of each license into the path e.g.:
> /usr/share/common-licenses/32b1062f7da84967e7019d01ab805935caa7ab7321a7ced0e30ebe75e5df1670/COPYING
> then have each file's identical implementation of those bytes overwrite
> each other, and you might have many packages owning that path on the
> installed system.  Slight modifications thus lead to different paths.
>
> That way you still have duplicates in the .rpm files, but an installed
> system has just one copy of each, and each rpm does indeed ship the
> precise license it's required to.
>
> I suspect that the arguments from crypto and from the legal side will
> "pass through one another like angry ghosts", though (and legal thus
> wins).

What a nice idea.

>  (ii) Compress the licenses?
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[David Malcolm]

On Wed, 2009-03-18 at 16:00 -0400, Tom "spot" Callaway wrote:
> On 03/18/2009 03:45 PM, Kevin Kofler wrote:
> > Simon Schampijer wrote:
> >> Yes. So the main question is now if Fedora would be willing to ship
> >> general licenses under /usr/share/common-licenses, I think.
> 
> I really don't want to do this. Here's why:
> 
> A) Many copyright holders make minor modifications to the licensing
> terms. These modifications usually do not affect the rights granted by
> the license (which is why we do not mark them as distinct and individual
> licenses), but it would be incorrect to have these packages pointing to
> general license texts when those do not apply.
> 
> B) Many licenses require that any distribution include the license text.
> Red Hat Legal was very uncomfortable with us using a rpm dependency to
> meet that requirement.
> 
> What I do think we were looking at doing is having rpm mark %license
> texts in a unique way that is different from %doc. This would permit rpm
> --excludedocs but retain the license texts.
> 
Thinking aloud, a couple of other approaches:
  (i) Embed the SHA256 checksum of each license into the path e.g.:
/usr/share/common-licenses/32b1062f7da84967e7019d01ab805935caa7ab7321a7ced0e30ebe75e5df1670/COPYING
then have each file's identical implementation of those bytes overwrite
each other, and you might have many packages owning that path on the
installed system.  Slight modifications thus lead to different paths.

That way you still have duplicates in the .rpm files, but an installed
system has just one copy of each, and each rpm does indeed ship the
precise license it's required to.

I suspect that the arguments from crypto and from the legal side will
"pass through one another like angry ghosts", though (and legal thus
wins).

  (ii) Compress the licenses?


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Tom "spot" Callaway]

On 03/18/2009 03:45 PM, Kevin Kofler wrote:
> Simon Schampijer wrote:
>> Yes. So the main question is now if Fedora would be willing to ship
>> general licenses under /usr/share/common-licenses, I think.

I really don't want to do this. Here's why:

A) Many copyright holders make minor modifications to the licensing
terms. These modifications usually do not affect the rights granted by
the license (which is why we do not mark them as distinct and individual
licenses), but it would be incorrect to have these packages pointing to
general license texts when those do not apply.

B) Many licenses require that any distribution include the license text.
Red Hat Legal was very uncomfortable with us using a rpm dependency to
meet that requirement.

What I do think we were looking at doing is having rpm mark %license
texts in a unique way that is different from %doc. This would permit rpm
--excludedocs but retain the license texts.

~spot
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Kevin Kofler]

Simon Schampijer wrote:
> Yes. So the main question is now if Fedora would be willing to ship
> general licenses under /usr/share/common-licenses, I think.

FWIW, I don't think it's legal to do that, licenses need to accompany the
package.

But in any case what really matters is whether RH Legal thinks it's legal,
not whether you or me do.

Kevin Kofler

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Benj. Mako Hill]

> Yeah. Looks like Mandriva has /usr/share/common-licenses and per  
> packages COPYING files. But the ones in /usr/share/common-licenses are  
> named differently then those in Debian (GPL-2 not GPLv2).

Nothing that symlinks can't fix. :)

If we pick one and make a reasonable argument, I don't think either
maintainers would object to adding links.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Simon Schampijer]

Benj. Mako Hill wrote:
> 
>> Yeah. Looks like Mandriva has /usr/share/common-licenses and per  
>> packages COPYING files. But the ones in /usr/share/common-licenses are  
>> named differently then those in Debian (GPL-2 not GPLv2).
> 
> Nothing that symlinks can't fix. :)
> 
> If we pick one and make a reasonable argument, I don't think either
> maintainers would object to adding links.

Yes. So the main question is now if Fedora would be willing to ship 
general licenses under /usr/share/common-licenses, I think.

Regards,
Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Simon Schampijer]

Bernie Innocenti wrote:
> [cc += fedora-de...@]

Sorry to reply late on this.

> Benj. Mako Hill wrote:
>> 
>>> we did show a full license in the Control Panel before. The path was  
>>> hard coded to where OLPC had placed the GPL license. What can we do to  
>>> meet the expectations of all the distributions that want to ship sugar?
>> It would be a great thing if we got the major distributions to agree on
>> a place to put common licenses. Debian puts them in
>> '/usr/share/common-licenses'.  I don't know where Red Hat puts them.
> 
> RedHat does not optimize common licenses at all.
> 
> Each package bears a copy of its own license, which is typically
> installed in /usr/share/doc//COPYING or similar.

Yeah. Looks like Mandriva has /usr/share/common-licenses and per 
packages COPYING files. But the ones in /usr/share/common-licenses are 
named differently then those in Debian (GPL-2 not GPLv2).

So for us, this means in the short term. Request each packager of Sugar 
to do the right thing for his distribution - or we place a COPYING file 
in the Sugar data folder and read it from there.

>> If we got agreement in those two places and on a list of common licenses
>> (even if one group just decides to symlink), we could get a majority of
>> distributions once the changes propogate.
> 
> Seems like a great idea to me... But I think it already came up some
> time ago, and I vaguely remember that RH legal blocked it because the
> license itself -- not just a symlink to it -- had to accompany the
> package.
> 

Of course, having a common place - /usr/share/common-licenses and having 
  a naming standard for the licenses in there would be ideal for our use 
case.

Thanks for your thoughts,
Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Carol Farlow Lerche]

As long as it can be overridden (and I presume it could be.)  I have a
problem in SynPhony of having many contributers to the database content that
are stored along with license details in a table within the database.
Static info in the software packaging is insufficient.

2009/2/28 Bernie Innocenti 

> Tomeu Vizoso wrote:
> > I suggest a palette attached to a button in the toolbar to show this
> > info, or a modal alert similar to the object chooser.
>
> A long time ago, someone at OLPC (was it Eben?) suggested adding an
> About menu item to the Stop button in the activity toolbar.
>
> Sugar-toolkit could contain common code to display a simple About box
> with information extracted from the the activity.info file.
>
> We might also extend the activity.info with fields for authors names
> and emails, license information and so on.  Dennis Gilmore suggested
> to use the same tag names of RPM spec files for easy conversion.
>
> Where does the bundle specification live these days?  Last time I've
> read it, it was still on wiki.laptop.org.
>
> --
>   // Bernie Innocenti - http://www.codewiz.org/
>  \X/  Sugar Labs   - http://www.sugarlabs.org/
>



-- 
"It is difficult to get a man to understand something, when his salary
depends upon his not understanding it." -- Upton Sinclair
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Kevin Kofler]

Elena of Valhalla wrote:
> no, GPL doesn't[1], a pointer is enough, but GNU FDL does
> 
> [1] "You should have received a copy of the GNU General Public License
> along with this program.  If not, see ."

Not true, that sentence is there to cope with projects which don't bother
including the license as required (see also the "should have received"
wording).

Section 4 of the GPLv3 actually requires you to:
"give all recipients a copy of this License along with the Program."
Likewise, section 1 of the GPLv2 requires you to:
"give any other recipients of the Program a copy of this License along with
the Program."

See also:
http://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude

Kevin Kofler

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Elena of Valhalla]

On Mon, Mar 2, 2009 at 1:52 AM, Kevin Kofler  wrote:
> Caius "kaio" Chance wrote:
>> GPL requires attachment of COPYING?
> Yes.

no, GPL doesn't[1], a pointer is enough, but GNU FDL does

[1] "You should have received a copy of the GNU General Public License
along with this program.  If not, see ."

-- 
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valha...@gmail.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Benj. Mako Hill]

> Seems like a great idea to me... But I think it already came up some
> time ago, and I vaguely remember that RH legal blocked it because the
> license itself -- not just a symlink to it -- had to accompany the
> package.

Well, including common licenses so that they be shown from within
applications certainly does not preclude shipping a copy of the license
with the application and would still be a very useful thing in this case
and in others. The top 10 licenses aren't big either so space
constraints shouldn't be an issue.

Maybe if we choose the same location and naming scheme used in Debian
and Ubuntu, this could be very solved very easily.

Regards,
Mako


-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Caius "kaio" Chance]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bernie Innocenti さんは書きました:
> Seems like a great idea to me... But I think it already came up some
> time ago, and I vaguely remember that RH legal blocked it because the
> license itself -- not just a symlink to it -- had to accompany the
> package.

GPL requires attachment of COPYING?

- - kaio


- --
Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com
JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmrIlUACgkQmo+B7bGj5dL7OwCfQ/E9y/BNSZZFpwqXcnreXeN0
hCEAoItONezCX92meuXqc/UhRqHPKWau
=7Y0y
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Benj. Mako Hill]

> we did show a full license in the Control Panel before. The path was  
> hard coded to where OLPC had placed the GPL license. What can we do to  
> meet the expectations of all the distributions that want to ship sugar?

It would be a great thing if we got the major distributions to agree on
a place to put common licenses. Debian puts them in
'/usr/share/common-licenses'.  I don't know where Red Hat puts them.

If we got agreement in those two places and on a list of common licenses
(even if one group just decides to symlink), we could get a majority of
distributions once the changes propogate.

Regards,
Mako

-- 
Benjamin Mako Hill
m...@atdot.cc
http://mako.cc/

Creativity can be a social contribution, but only in so far
as society is free to use the results. --GNU Manifesto


signature.asc
Description: Digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Mar 02, 2009 at 01:52:49AM +0100, Kevin Kofler wrote:
>Caius "kaio" Chance wrote:
>> GPL requires attachment of COPYING?
>
>Yes.

I believe the way Debian handles this is by interpreting the 
distribution as a whole as being shipped as one.

  - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmrS90ACgkQn7DbMsAkQLhuigCePC4ow77Tjo4V7XVZ/xtriQ9a
SAAAn3z1YCC0ivbacrcccq2IzKKd11MI
=lu/m
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Kevin Kofler]

Caius "kaio" Chance wrote:
> GPL requires attachment of COPYING?

Yes.

Kevin Kofler

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Bernie Innocenti]

[cc += fedora-de...@]

Benj. Mako Hill wrote:
> 
>> we did show a full license in the Control Panel before. The path was  
>> hard coded to where OLPC had placed the GPL license. What can we do to  
>> meet the expectations of all the distributions that want to ship sugar?
> 
> It would be a great thing if we got the major distributions to agree on
> a place to put common licenses. Debian puts them in
> '/usr/share/common-licenses'.  I don't know where Red Hat puts them.

RedHat does not optimize common licenses at all.

Each package bears a copy of its own license, which is typically
installed in /usr/share/doc//COPYING or similar.


> If we got agreement in those two places and on a list of common licenses
> (even if one group just decides to symlink), we could get a majority of
> distributions once the changes propogate.

Seems like a great idea to me... But I think it already came up some
time ago, and I vaguely remember that RH legal blocked it because the
license itself -- not just a symlink to it -- had to accompany the
package.

-- 
   // Bernie Innocenti - http://www.codewiz.org/
 \X/  Sugar Labs   - http://www.sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Carol Farlow Lerche]

I liked Wade's suggestion of making it part of help, as it is in other
desktops.  (help->about)  Of course this presumes that the great help debate
results in a help button/thingy!! (My challenged GUI nomenclature is one
more piece of evidence as to why I don't build GUIs for a living.)

On Sat, Feb 28, 2009 at 7:14 AM, Tomeu Vizoso  wrote:

> I suggest a palette attached to a button in the toolbar to show this
> info, or a modal alert similar to the object chooser.
>
> Regards,
>
> Tomeu
>
> On Fri, Feb 20, 2009 at 19:52, Carol Farlow Lerche  wrote:
> > This brings up an issue I have been thinking about, since the SynPhony
> > database comprises several "with attribution" components.  Would it make
> > sense to have a common design element that was "about " or
> > "credits" that would allow contributions to be acknowledged?  Leaving
> aside
> > whether it is a license requirement I think it is good practice to show
> > Sugar users, aka kids, that some people cared enough to build this stuff,
> > and that if they build stuff they can receive acknowledgement too.
> >
> > On Fri, Feb 20, 2009 at 4:06 AM, Simon Schampijer 
> > wrote:
> >>
> >> Hi,
> >>
> >> we did show a full license in the Control Panel before. The path was
> >> hard coded to where OLPC had placed the GPL license. What can we do to
> >> meet the expectations of all the distributions that want to ship sugar?
> >>
> >> Thanks for inputs on this,
> >>Simon
> >>
> >> http://dev.sugarlabs.org/ticket/357
> >> ___
> >> Sugar-devel mailing list
> >> Sugar-devel@lists.sugarlabs.org
> >> http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
> >
> > --
> > "It is difficult to get a man to understand something, when his salary
> > depends upon his not understanding it." -- Upton Sinclair
> >
> > ___
> > Sugar-devel mailing list
> > Sugar-devel@lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>



-- 
"It is difficult to get a man to understand something, when his salary
depends upon his not understanding it." -- Upton Sinclair
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Bernie Innocenti]

Tomeu Vizoso wrote:
> I suggest a palette attached to a button in the toolbar to show this
> info, or a modal alert similar to the object chooser.

A long time ago, someone at OLPC (was it Eben?) suggested adding an
About menu item to the Stop button in the activity toolbar.

Sugar-toolkit could contain common code to display a simple About box
with information extracted from the the activity.info file.

We might also extend the activity.info with fields for authors names
and emails, license information and so on.  Dennis Gilmore suggested
to use the same tag names of RPM spec files for easy conversion.

Where does the bundle specification live these days?  Last time I've
read it, it was still on wiki.laptop.org.

-- 
   // Bernie Innocenti - http://www.codewiz.org/
 \X/  Sugar Labs   - http://www.sugarlabs.org/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Tomeu Vizoso]

I suggest a palette attached to a button in the toolbar to show this
info, or a modal alert similar to the object chooser.

Regards,

Tomeu

On Fri, Feb 20, 2009 at 19:52, Carol Farlow Lerche  wrote:
> This brings up an issue I have been thinking about, since the SynPhony
> database comprises several "with attribution" components.  Would it make
> sense to have a common design element that was "about " or
> "credits" that would allow contributions to be acknowledged?  Leaving aside
> whether it is a license requirement I think it is good practice to show
> Sugar users, aka kids, that some people cared enough to build this stuff,
> and that if they build stuff they can receive acknowledgement too.
>
> On Fri, Feb 20, 2009 at 4:06 AM, Simon Schampijer 
> wrote:
>>
>> Hi,
>>
>> we did show a full license in the Control Panel before. The path was
>> hard coded to where OLPC had placed the GPL license. What can we do to
>> meet the expectations of all the distributions that want to ship sugar?
>>
>> Thanks for inputs on this,
>>Simon
>>
>> http://dev.sugarlabs.org/ticket/357
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
>
> --
> "It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it." -- Upton Sinclair
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Luke Faraone]

On Fri, Feb 20, 2009 at 1:52 PM, Carol Farlow Lerche  wrote:

> This brings up an issue I have been thinking about, since the SynPhony
> database comprises several "with attribution" components.  Would it make
> sense to have a common design element that was "about " or
> "credits" that would allow contributions to be acknowledged?  Leaving aside
> whether it is a license requirement I think it is good practice to show
> Sugar users, aka kids, that some people cared enough to build this stuff,
> and that if they build stuff they can receive acknowledgement too.


Agreed, but it might be a good idea to implement a standard for such
copyrights, to make them machine-readable. See
http://wiki.debian.org/Proposals/CopyrightFormat and
http://fedoraproject.org/wiki/Licensing for two such formats.

-- 
Luke Faraone
http://luke.faraone.cc
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Wade Brainerd]

Agreed that an "about this activity" (credits, license, etc) UI element
should be standard.
This should be part of a ubiquitous help button, which would become part of
the standard activity toolbar.  When clicked, it opens a localized .html
file from within the activity bundle.  It could open in Browse, or else a
modal dialog.

On Fri, Feb 20, 2009 at 1:52 PM, Carol Farlow Lerche  wrote:

> This brings up an issue I have been thinking about, since the SynPhony
> database comprises several "with attribution" components.  Would it make
> sense to have a common design element that was "about " or
> "credits" that would allow contributions to be acknowledged?  Leaving aside
> whether it is a license requirement I think it is good practice to show
> Sugar users, aka kids, that some people cared enough to build this stuff,
> and that if they build stuff they can receive acknowledgement too.
>
>
> On Fri, Feb 20, 2009 at 4:06 AM, Simon Schampijer wrote:
>
>> Hi,
>>
>> we did show a full license in the Control Panel before. The path was
>> hard coded to where OLPC had placed the GPL license. What can we do to
>> meet the expectations of all the distributions that want to ship sugar?
>>
>> Thanks for inputs on this,
>>Simon
>>
>> http://dev.sugarlabs.org/ticket/357
>> ___
>> Sugar-devel mailing list
>> Sugar-devel@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>
>
>
> --
> "It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it." -- Upton Sinclair
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Full Licence field

[Carol Farlow Lerche]

This brings up an issue I have been thinking about, since the SynPhony
database comprises several "with attribution" components.  Would it make
sense to have a common design element that was "about " or
"credits" that would allow contributions to be acknowledged?  Leaving aside
whether it is a license requirement I think it is good practice to show
Sugar users, aka kids, that some people cared enough to build this stuff,
and that if they build stuff they can receive acknowledgement too.

On Fri, Feb 20, 2009 at 4:06 AM, Simon Schampijer wrote:

> Hi,
>
> we did show a full license in the Control Panel before. The path was
> hard coded to where OLPC had placed the GPL license. What can we do to
> meet the expectations of all the distributions that want to ship sugar?
>
> Thanks for inputs on this,
>Simon
>
> http://dev.sugarlabs.org/ticket/357
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
"It is difficult to get a man to understand something, when his salary
depends upon his not understanding it." -- Upton Sinclair
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Full Licence field

[Simon Schampijer]

Hi,

we did show a full license in the Control Panel before. The path was 
hard coded to where OLPC had placed the GPL license. What can we do to 
meet the expectations of all the distributions that want to ship sugar?

Thanks for inputs on this,
Simon

http://dev.sugarlabs.org/ticket/357
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel