headers
Richard Hughes | 2 Dec 2007 19:48

packagekit: Branch 'master' - 2 commits

 backends/zypp/pk-backend-zypp.cpp |    8 ++++++++
 backends/zypp/zypp-utils.cpp      |   17 +++++++++++++++++
 backends/zypp/zypp-utils.h        |    2 ++
 libpackagekit/wscript_build       |    1 +
 4 files changed, 28 insertions(+)

New commits:
commit fc53450dc8eeddb44d20f3f5c18b254985150f04
Author: Gustavo Carneiro <gjc@...>
Date:   Sat Dec 1 14:02:23 2007 +0000

    Fix x86_64 build (missing -fPIC).

diff --git a/libpackagekit/wscript_build b/libpackagekit/wscript_build
index 59dd423..5e31272 100644
--- a/libpackagekit/wscript_build
+++ b/libpackagekit/wscript_build
 <at>  <at>  -15,6 +15,7  <at>  <at>  obj = bld.create_obj('gnome', 'objects')
 obj.includes = '. ../libgbus ../libselftest'
 obj.target = 'libpkgkit_common_source'
 obj.uselib = 'GLIB GOBJECT DBUS DBUS_GLIB'
+obj.env.append_value('CCFLAGS', obj.env['shlib_CCFLAGS'])
 obj.source = """
 	pk-debug.c
 	pk-connection.c
commit e04930e488a37c08f4a9bb4f69c72f1696f92c2d
Author: Boyd Timothy <btimothy@...>
Date:   Fri Nov 30 15:50:53 2007 -0700

    Fleshing out more of the backend_search_name for zypp backend
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Hughes | 3 Dec 2007 19:10
Picon

Free and non-free filter

For the soon to be discussed EULA licence stuff, I want to add another
filter; "free" and "~free" based on the package licence.

For example, I could do "SearchDescription available;free
virtualisation" to get all the packages I could install for
non-proprietary solutions. I guess we can just whitelist the GPL, GPLv2,
GPLv2+ type strings for this and keep it nicely simple.

Of course, "free" can take all the usually debates on it's meaning, but
I take "free" to mean "FSF declared this licence as free" rather than
"this costs nothing".

The GPLv2+ matching should probably be shared somewhere in a nice
boolean=pk_backend_license_is_free(string) matching function. We can use
http://fedoraproject.org/wiki/Licensing as an initial reference, as I
guess most of the other backends will have similar short names.

So, I guess this feature is useful (it's useful to me, just so I install
the correct free flash package). I'm guessing it's mostly trivial to get
this information from the metadata, and so wouldn't be too hard to add.
Correct me if I'm wrong. Comments?

Thanks.

Richard.
Permalink | Reply | 14 comments |
headers
Tom Parker | 3 Dec 2007 19:22
Gravatar

Re: Free and non-free filter

On 03/12/2007, Richard Hughes <hughsient@...> wrote:
> So, I guess this feature is useful (it's useful to me, just so I install
> the correct free flash package). I'm guessing it's mostly trivial to get
> this information from the metadata, and so wouldn't be too hard to add.
> Correct me if I'm wrong. Comments?

Apt-based stuff still has all the problems mentioned by me before
(namely, we don't have a clue about this, and metadata is thin on the
ground). We can cheat a little here, by noting that for official
Debian repos (and also similarly for Ubuntu) we can separate between
DFSG-free and not-DFSG-free (which is diffferent from FSF-free), but
this will involve a certain amount of "oh, look, it says 'main', ergo
is must be all free" which will massively screw-up on most external
repositories.

Tom
Permalink | Reply | 0 comments |
headers
Richard Hughes | 3 Dec 2007 19:23
Picon

EULA Prompts

First things first: I'm not a big fan of proprietary software. I know it
sometimes has to exists, and lots of people already use it.

Proprietary software usually requires agreeing to a EULA (or other
special licence or terms of use). The EULA can be per-repo (e.g. livna),
per-package (flash) or per-group (vmware-*)for packages. It can also be
per-system or per-user. We need to be able to support each of these in
PackageKit.

We already have RepoSignatureRequired (so we can add a GPG key for a
repo), but I think the issue of repo signing and agreeing to a package
eula is orthogonal, and hence isn't part of this discussion.

Now, I see a few ways that installing proprietary software can be
handled currently in PackageKit:
 * We just don't support installing packages that are non-free from the
GUI or pkcon tools and hide available packages from the search results
 * We silently agree to the licence when downloading and installing the
product, and show a Message() post transaction that we need to review
the licence and uninstall the software if we do not agree to it (legally
questionable)
 * We install the package, and error out (with ErrorCode) if we have to
agree to a EULA of any sort, with the logic that this software will have
to be installed from the console using native tools
 * We install the package, and special ErrorCode which we have to agree
to for a requeue. If we agree, then the transaction is requeued with
additional flags to indicate that the licence has been agreed to. Of
course, nothing stops a client program just doing the install with the
extra flag and not showing the licence at all.
 * We add the licences to a licence database and the user agrees or
(Continue reading)

Permalink | Reply | 4 comments |
headers
S.Çağlar Onur | 3 Dec 2007 19:28
Picon
Favicon

Re: Free and non-free filter

Hi;

Monday 03 December 2007 Tarihinde 20:10:46 yazmıştı:
> For the soon to be discussed EULA licence stuff, I want to add another
> filter; "free" and "~free" based on the package licence.
>
> For example, I could do "SearchDescription available;free
> virtualisation" to get all the packages I could install for
> non-proprietary solutions. I guess we can just whitelist the GPL, GPLv2,
> GPLv2+ type strings for this and keep it nicely simple.
>
> Of course, "free" can take all the usually debates on it's meaning, but
> I take "free" to mean "FSF declared this licence as free" rather than
> "this costs nothing".
>
> The GPLv2+ matching should probably be shared somewhere in a nice
> boolean=pk_backend_license_is_free(string) matching function. We can use
> http://fedoraproject.org/wiki/Licensing as an initial reference, as I
> guess most of the other backends will have similar short names.
>
> So, I guess this feature is useful (it's useful to me, just so I install
> the correct free flash package). I'm guessing it's mostly trivial to get
> this information from the metadata, and so wouldn't be too hard to add.
> Correct me if I'm wrong. Comments?

It will cause no problem for us, as you said, our metadata provides that 
information, so PiSi backend can start to use as soon as you added that 
filter to PK :).

Cheers
(Continue reading)

Permalink | Reply | 1 comment |
headers
Richard Hughes | 3 Dec 2007 19:57
Picon

Re: Free and non-free filter

On Mon, 2007-12-03 at 20:28 +0200, S.Çağlar Onur wrote:
> It will cause no problem for us, as you said, our metadata provides
> that information, so PiSi backend can start to use as soon as you
> added that filter to PK :).

Pushed. If you do any python backend stuff can we try and make sure as
much as possible is shared. Cheers dude!

Richard.

_______________________________________________
PackageKit mailing list
PackageKit <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/packagekit
Permalink | Reply | 0 comments |
headers
Tim Lauridsen | 3 Dec 2007 20:50
Gravatar

Re: Free and non-free filter

Richard Hughes wrote:
> For the soon to be discussed EULA licence stuff, I want to add another
> filter; "free" and "~free" based on the package licence.
>
> For example, I could do "SearchDescription available;free
> virtualisation" to get all the packages I could install for
> non-proprietary solutions. I guess we can just whitelist the GPL, GPLv2,
> GPLv2+ type strings for this and keep it nicely simple.
>
> Of course, "free" can take all the usually debates on it's meaning, but
> I take "free" to mean "FSF declared this licence as free" rather than
> "this costs nothing".
>
> The GPLv2+ matching should probably be shared somewhere in a nice
> boolean=pk_backend_license_is_free(string) matching function. We can use
> http://fedoraproject.org/wiki/Licensing as an initial reference, as I
> guess most of the other backends will have similar short names.
>
> So, I guess this feature is useful (it's useful to me, just so I install
> the correct free flash package). I'm guessing it's mostly trivial to get
> this information from the metadata, and so wouldn't be too hard to add.
> Correct me if I'm wrong. Comments?
>
> Thanks.
>
> Richard.
>
> _______________________________________________
> PackageKit mailing list
> PackageKit@...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Norwood | 3 Dec 2007 20:53
Picon
Favicon
Subject: Re: Free and non-free filter

Re: Free and non-free filter

Richard Hughes <hughsient@...> writes:

> For the soon to be discussed EULA licence stuff, I want to add another
> filter; "free" and "~free" based on the package licence.
>
> For example, I could do "SearchDescription available;free
> virtualisation" to get all the packages I could install for
> non-proprietary solutions. I guess we can just whitelist the GPL, GPLv2,
> GPLv2+ type strings for this and keep it nicely simple.
>
> Of course, "free" can take all the usually debates on it's meaning, but
> I take "free" to mean "FSF declared this licence as free" rather than
> "this costs nothing".
>
> The GPLv2+ matching should probably be shared somewhere in a nice
> boolean=pk_backend_license_is_free(string) matching function. We can use
> http://fedoraproject.org/wiki/Licensing as an initial reference, as I
> guess most of the other backends will have similar short names.
>
> So, I guess this feature is useful (it's useful to me, just so I install
> the correct free flash package). I'm guessing it's mostly trivial to get
> this information from the metadata, and so wouldn't be too hard to add.
> Correct me if I'm wrong. Comments?

I've Cc'ed Tom Callaway, He's effectively The Fedora Licensing guy, and
might have some input.

Personally, I love this idea.  Fedora, at least, has been making lots of
progress with validating and regularizing the License field for our
rpms, through lots of work from the aforementioned Mr. Callaway.  I
(Continue reading)

Permalink | Reply | 9 comments |
headers
Richard Hughes | 3 Dec 2007 21:01
Picon

Re: Free and non-free filter

On Mon, 2007-12-03 at 14:53 -0500, Robin Norwood wrote:
> I've Cc'ed Tom Callaway, He's effectively The Fedora Licensing guy, and
> might have some input.

Cool, thanks. I think licencing is very important, well, much more
important that agreeing to random EULA's.

> If we're using the FSF definition of Free, I guess this is the
> definitive page:
> 
> http://www.fsf.org/licensing/licenses/
> 
> We should probably reference that somewhere in the docs/help.

Yes, please commit ;-)

> Do we care about flagging 'open source' too?
> (http://www.opensource.org/licenses/alphabetical, for instance)

No, I don't want to convey the difference to the users. Free is easy to
comprehend.

> Also, from a practical point of view, would we mark anything that
> doesn't match the list of Free licenses as 'non free'?  This seems the
> only way to do it, but will lead to false positives.

No, I think we have to whitelist, not blacklist. i.e. if a package has
no licence field then it's non-free - it's only free if the licence
explicitly says so.
(Continue reading)

Permalink | Reply | 8 comments |
headers
David Zeuthen | 3 Dec 2007 21:03
Picon
Gravatar

Re: EULA Prompts


Hi,

Maybe this would be easier to discuss / analyze if someone came up with
a few concrete examples of different apps with different EULA
requirements.

      David
Permalink | Reply | 0 comments |

Gmane