[gentoo-dev] Re: John Jawed Alex Tarkovsky's einput eclass
Rémi Cardona schrieb: As you pointed it out, ebuilds should not be interactive. Imho, adding an eclass to encourage it is counter-productive. While that's true, there might be a use case in pkg_config. For example postgresql which needs quiet a few parameters to initialize the first database cluster. If we could present the user a couple of options in a list where he can just select the one he wants. Cheers, Tiziano signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: John Jawed Alex Tarkovsky's einput eclass
Steve Long schrieb: Hi, A link on bugzilla somehow led me (isn't the web wonderful ;) to this: http://thread.gmane.org/gmane.linux.gentoo.devel/40596 which appears (to a user) like a really good idea. There is a version still at: http://jawed.name/dev/gentoo/einput.eclass A newer version of the mentioned eclass is available here: http://overlays.gentoo.org/proj/postgresql/browser/testing/eclass/einput.eclass Cheers, Tiziano signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: John Jawed Alex Tarkovsky's einput eclass
Sorry for the atomic posts, I should rather first think before hitting the send button :-\ The problem with the proposed einput.eclass is that the user has to use the commandline for that, which is fine for a lot of people. At the moment I'd rather like to see a proposal for an API (together with the use cases it tries to solve) and leave the implementation aside. Hoping that we get a solution which doesn't depend on the commandline but can also be used with a GUI, a braille-display, etc. Regards, Tiziano signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Non-new developer: Tobias Heinlein (keytoaster)
Luca Barbato wrote: Denis Dupeyron wrote: So please, everybody, give a warm non-welcome to Tobias. Happy break^Whacking! Yeah, I think that might be one of those occasions where the humourous intent was somewhat diverted by linguistic differences.. in this case to absolutely hilarious effect! :P -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Watch out for license changes to GPL-3.
Petteri Räty wrote: David kirjoitti: Was suggested I make a post on the mailing list in addition to lodging bug https://bugs.gentoo.org/184522 Don't know why you were suggested it but any way yes everyone should be on the lookout for license changes. That's why ;) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Inotify and (f)crontabs
Mike Frysinger wrote: I have to disagree in this particular case. The anacron homepage, anacron.sourceforge.net, gives this exact situation as its primary example of what anacron is intended for. Sure, it's not good for handling more complex scheduling, but it seems to do what run-crons tries to do: run jobs that should have been executed while the computer was off, as soon as it comes back on. Am I missing something subtle? run-crons transparently gives all crons this behavior with very little overhead rather than making every user set up a dual system: a standard cron and anacron. run-crons is a default helper for crons that just works. if you want to not use it but opt for anacron instead, nothing is stopping you from doing exactly that. I think Mr Frysinger is grudgingly conceding the point, so can we have some stats eg on CPU time saved blah blah blah? But it'd be really sweet if you could post em on the forums, as the technical discussion seems over for now. (At least to this friendly-coder ;-)) ie: market it to the user base please, not the devs ;) Please be sure that this works from a clean install and test it on a live box as the only system-- for a period of at least a week, as you collect sample data. A write up of how to make it work would be ideal for Documentation, Tips Tricks imo. 2 of 5 - recall to pub *bzzt*.. click. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] automated extended information gathering
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent Fredric wrote:
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package aint installed yet' and info was
'for working but bust packages only', but that can be superceded with
a CHECKLIST and a conditional driven INFO function.
CHECKLIST=
a? ( some-cat/a-lib )
b? ( some-cat/b-lib )
That would make building a checklist for lazy people as simple as
CHECKLIST=${RDEPEND}
This seems to be quite a heavy solution just to get a little more
information. Info seems much more simple and flexible. If you're
having to encode information in the ebuild about what dependencies to
check when you break then how will you diagnose missing dependencies?
From Mike's idea, I envisaged something more along the lines of:
Bug:
Compilation failed as followed:
Package X failed to install
...stuff...
X.c: ../Y.h not found
X.c: ../Z.h not found
...stuff...
Response:
Could you please run emerge --info --verbose Y Z and paste the output here
Counter-Response:
Lots of useful standard info
Y was compiled with USE flags blah
Y was compiled from overlay BLAH
Y's manifest was not signed
Y's internal env included myconf='--disable-something-critical'
Z wasn't emerged
Speedy response:
Ah, your problem is that for some reason, something-critical was
disabled in package Y, and Z wasn't included in the dependencies.
Please try this to solve it...
It's difficult to think of situations where you'd ask for information
from an uninstalled ebuild that you couldn't ask for from installed
dependencies, but I'd rather do that manually than try encoding it into
the ebuilds and then still have to ask the user to do it manually in
some circumstances.
Most of this could be in a default pkg_info, but it allows for
overriding by an eclass, and on a per package basis, without requiring
each package writing custom error-locating code. This is, after all,
just giving more information, it's not guaranteed to find the error.
I hope that makes some sense?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)
iD8DBQFGkMBIu7rWomwgFXoRAghUAJ0a/EP6wRQlT2j+GcND5LZoNoqWMwCbBhbR
WwvnMHqEgmlz/auL00YvhIQ=
=kmNa
-END PGP SIGNATURE-
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What about moving Gentoo stuff to `GPLv3 or later'? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkMS4p/VmCx0OL2wRAmkvAKDJCYN0B/i7Pxyg1rDPCVeaSQxZAwCfQeb0 994588RE/uxHALCw4JlcZRM= =UEr5 -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: automated extended information gathering
Kent Fredric wrote:
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote:
often times when i get a bug report about certain packages, there's
information about that package that i usually ask for ... i wonder if
this can be automated
pkg_getinfo(){
if [[ installed ]]; then
someSelfCheck;
someSelfCheck;
echo someversionNumberStuff;
fi
someBasicSystemCheckRequiredForPkgToWork();
if [[ someCondition ]]; then
get_info( some-cat/d-lib ); # its not on the dep list, but we
want
to check its info status as part of /our/ info status.
fi
}
Sorry to have skipped the rest of this fascinating discussion, but all I
want to know is does the above fulfil the original criteria? I'm guessing
it does, since the pkgInfo() function ``trumped it all.
The basic concept of 'check' was
'this will work even if the package aint installed yet' and info was
'for working but bust packages only', but that can be superceded with
a CHECKLIST and a conditional driven INFO function.
hmm sounds a bit complex to me. Abstract designs are simple. tuomov
But hey, there appear to be loads of 3 line functions all over the shop..
the claim i'm making is that there generally isnt any code/checks worth
adding to ebuilds that would be useful for the purpose of an ebuild
I think the intent was for the maintainer to decide what to put there?
diagnosing
itself to determine whether it is broken and how it is broken. we just
dont have a language yet to properly describe the process of diagnosing
and fixing
oneself. a fun thesis for an AI doctorate :p
Er no a fun project for a noob programmer in a VVHLL. An interesting project
would be to make a semantic map of all the terms you guys have finally
settled on for the portage API, and then tie that into linguistic analysis
(and perhaps even consider i18n for portCore?) all that other stuff you
were thinking of, yadda yadda. Have you got a PhD yet? ;P
/me runs to pub
Er ofc it's not my trademark... *sheesh*. But I'll claim it if you lot don't
hurry up.
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] net-mail/cyrus-imapd needs an active maintainer
This ebuild has a security bug open for almost one year (Bug 142817), plus lots of other bugs as well. If you are interested, please see http://tinyurl.com/32webs -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Script for easier stabilising of ebuilds
* Christian Faulhammer [EMAIL PROTECTED] [07/07/08 12:31 +0200]: Lars Weiler [EMAIL PROTECTED]: Comments are welcome! Have a look at app-portage/gatt-svn and help improve it. :) It's C++ :-( Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Instant Messaging : [EMAIL PROTECTED] Gentoo Linux PowerPC : Developer Gentoo Infrastructure : CVS Administrator pgpgcemsKm6jd.pgp Description: PGP signature
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sun, 2007-07-08 at 13:50 +0200, Wulf C. Krueger wrote: On Sunday, 08. July 2007 13:04:24 Marijn Schouten (hkBst) wrote: What about moving Gentoo stuff to `GPLv3 or later'? I'm strongly opposed to the or later part for the simple reason that this implicates we will agree with stuff we don't even know yet. Hear hear. That's why we removed the or later rubbish from our licenses about 4 years ago. I haven't studied GPL-3 fully yet so I haven't formed an opinion about moving to it alone. I'm not certain what it buys us to move to v3, to be honest. Unless there are compelling reasons to do so, I don't think it's worth the effort to change it. Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Inotify and (f)crontabs
On 7/8/07, Steve Long [EMAIL PROTECTED] wrote: Mike Frysinger wrote: run-crons is a default helper for crons that just works. if you want to not use it but opt for anacron instead, nothing is stopping you from doing exactly that. I think Mr Frysinger is grudgingly conceding the point, so can we have some stats eg on CPU time saved blah blah blah? But it'd be really sweet if you could post em on the forums, as the technical discussion seems over for now. (At least to this friendly-coder ;-)) ie: market it to the user base please, not the devs ;) Please be sure that this works from a clean install and test it on a live box as the only system-- for a period of at least a week, as you collect sample data. A write up of how to make it work would be ideal for Documentation, Tips Tricks imo. 2 of 5 - recall to pub *bzzt*.. click. Well, as you can tell from the fact that I use fcron, this point is of academic interest to me. It's also secondary to my main concern in this thread, which is getting Gentoo to use incron; right now I'm just waiting for people to comment on the ebuild I posted yesterday. In my opinion, this is really an issue for the developers, and indeed I think Mike Frysinger agrees with that since he views the periodic scripts (now handled by run-crons) to be something that should just work, i.e. be beneath the notice of the user. Replacing it with an anacron setup that just works should be equivalent from the user's perspective. After all, how much of Gentoo is carefully preconfigured to just work out of the box? Until I installed fcron, the file I saw most often in /etc was make.conf. It's one thing to have to configure cron to do your daily chores; that's necessary, of course, since only you can know what you want done (but note that Gentoo already includes daily makewhatis and updatedb jobs, which are the two big ones). It's another to have anacron set up just to do the generalized task of handling this; the user doesn't even need to know it's there. Just like they don't know that run-crons is there. As for CPU savings: are you kidding? Right now, run-crons is run every ten minutes, and anacron would be run on boot and every 24 hours thereafter. The advantages are clear. I don't think the users are invested in the particular implementation at all; since run-crons is, as Mr. Frysinger wrote in his original response to me, a Gentooism, that question is really one for the developers. To be more pointed about it, it is not even my problem to justify using anacron, since this is the canonical answer to the question which Gentoo answers by using a home-grown script run-crons. Whoever implemented run-crons should justify reinventing the wheel and explain how anacron's failings prevent it from working as intended (and why, at the same time, Gentoo also recommends installing it, or using fcron). I'm just here to ask them why. -- Ryan Reich -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Inotify and (f)crontabs
On 7/8/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Sunday 08 July 2007, Ryan Reich wrote: I have to disagree in this particular case. The anacron homepage, anacron.sourceforge.net, gives this exact situation as its primary example of what anacron is intended for. Sure, it's not good for handling more complex scheduling, but it seems to do what run-crons tries to do: run jobs that should have been executed while the computer was off, as soon as it comes back on. Am I missing something subtle? run-crons transparently gives all crons this behavior with very little overhead rather than making every user set up a dual system: a standard cron and anacron. run-crons is a default helper for crons that just works. if you want to not use it but opt for anacron instead, nothing is stopping you from doing exactly that. What is the additional overhead of using cron+anacron as compared to using cron+run-crons? The README in anacron's tarball indicates that the net difference is one bootscript. Otherwise, you (by which I mean the developers as opposed to the person using anacron) just take most of the existing /etc/crontab and put it (or its anacron equivalent) in /etc/anacrontab, and with the rest you have cron run anacron once a night. The user wouldn't have to do any more setup than currently; it would just work. -- Ryan Reich -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
Le Sun, 08 Jul 2007 09:06:09 -0400, Seemant Kulleen [EMAIL PROTECTED] a écrit : On Sun, 2007-07-08 at 13:50 +0200, Wulf C. Krueger wrote: On Sunday, 08. July 2007 13:04:24 Marijn Schouten (hkBst) wrote: What about moving Gentoo stuff to `GPLv3 or later'? I'm strongly opposed to the or later part for the simple reason that this implicates we will agree with stuff we don't even know yet. Hear hear. That's why we removed the or later rubbish from our licenses about 4 years ago. I haven't studied GPL-3 fully yet so I haven't formed an opinion about moving to it alone. I'm not certain what it buys us to move to v3, to be honest. Unless there are compelling reasons to do so, I don't think it's worth the effort to change it. Seemant The problem is when you want to move. If the original statement is GPL-2 or later, it is just to move to whatever gpl2 you want to move. With the original statement GPL-2 alone, you have to take contact and get an authorisation to move from each single programmer that contributed code into the project. I personally think at gpl-3 is better as gpl-2 because GPLv3 will block tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can't change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won't like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise. see http://www.gnu.org/licenses/rms-why-gplv3.html If you want to migrate to GPL-3, the most important question to solve will be: is it possible to get an agreement to do that migration from every single programmer involved in gentoo? My 2 c. contrib. Dominique -- N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me parvenir. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sun, 8 Jul 2007 16:46:57 +0200 Dominique Michel [EMAIL PROTECTED] wrote: With the original statement GPL-2 alone, you have to take contact and get an authorisation to move from each single programmer that contributed code into the project. No, you have to get permission of the copyright holders. Which, in this case, is the Foundation. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Script for easier stabilising of ebuilds
Lars Weiler [EMAIL PROTECTED]: * Christian Faulhammer [EMAIL PROTECTED] [07/07/08 12:31 +0200]: Lars Weiler [EMAIL PROTECTED]: Comments are welcome! Have a look at app-portage/gatt-svn and help improve it. :) It's C++ :-( No matter, you could even help with ideas...it seems that I am the only arch dev that uses it at the moment, input is highly appreciated by Matthias. Contact him...:) -- http://www.gentoo.org/ http://www.faulhammer.org/ http://www.gnupg.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Script for easier stabilising of ebuilds
On Sun, 2007-07-08 at 14:45 +0200, Lars Weiler wrote: * Christian Faulhammer [EMAIL PROTECTED] [07/07/08 12:31 +0200]: Lars Weiler [EMAIL PROTECTED]: Comments are welcome! Have a look at app-portage/gatt-svn and help improve it. :) It's C++ :-( well, helping doesn't necessarily mean coding... just tell me exactly what kind of feature you are missing and what i need to know to provide a proper implementation; should we have made it this far, all you need to do is to give me some feedback and help me with testing. you don't have to even look at a single line of c++ ;-) matthias -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Script for easier stabilising of ebuilds
* Christian Faulhammer [EMAIL PROTECTED] [07/07/08 17:25 +0200]: No matter, you could even help with ideas...it seems that I am the only arch dev that uses it at the moment, input is highly appreciated by Matthias. Contact him...:) I'm also a fan of gatt. It really helps a lot during testing. I will contact Matthias off-list and will work with him for including my ideas in gatt. Regards, Lars -- Lars Weiler [EMAIL PROTECTED] +49-171-1963258 Instant Messaging : [EMAIL PROTECTED] Gentoo Linux PowerPC : Developer Gentoo Infrastructure : CVS Administrator pgpc8jCz7v5u2.pgp Description: PGP signature
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sun, 2007-07-08 at 16:46 +0200, Dominique Michel wrote: I personally think at gpl-3 is better as gpl-2 because GPLv3 will block tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can't change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won't like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise. see http://www.gnu.org/licenses/rms-why-gplv3.html If you want to migrate to GPL-3, the most important question to solve will be: is it possible to get an agreement to do that migration from every single programmer involved in gentoo? Like Ciaran said, the foundation holds the copyright, so it can re-license if it needs/wants to. The tivoization clause is certainly one of those subjects that can rapidly spiral downwards on this list, because it is largely a religious issue. In Tivo's case, they made the software freely available, but locked down their hardware. So, software wise, they did not affect freedom; hardware wise, it's their design and specs, they're under no obligations. Either way, I'm not sure how Gentoo is affected by the tivoization clause. If you can really show some way that GPL3 provides a compelling case to move to it, then we can start talking about that. Thanks, Seemant signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sun, Jul 08, 2007 at 03:50:56PM +0100, Ciaran McCreesh wrote: On Sun, 8 Jul 2007 16:46:57 +0200 Dominique Michel [EMAIL PROTECTED] wrote: With the original statement GPL-2 alone, you have to take contact and get an authorisation to move from each single programmer that contributed code into the project. No, you have to get permission of the copyright holders. Which, in this case, is the Foundation. Could you back that up, please? I was looking for something to confirm or deny this myself, but didn't find anything. I did, however, find http://dev.gentoo.org/~swift/blog/articles/20050506-foundation/ Quoting: Note that the Foundation would never change the license used for the code or documentation, if that could be set in stone that would be even better. Is this still relevant? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: If you can really show some way that GPL3 provides a compelling case to move to it, then we can start talking about that. I wasn't aware that gentoo practiced copyright assignment. You might want to make the disclaimers clear - if somebody submits a patch on bugzilla and doesn't expressly assign copyright they would legally retain it unless it were a clear condition of using the site. Also, it would help avoid people submitting patches that aren't GPL-2-only-compatible from other projects. But then again, I'm not a lawyer... :) I guess one reason to move would be that it is the goal of the FSF for this to become the default GPL. So, if there was a compelling case for adopting the GPL at all (one presumes there was since we're GPL currently), then there is a case for migrating to GPL v3 by that virtue alone. Does that mean that we HAVE to? Certainly not. I'd ask the question why we're GPL at all? If the reason is because we generally agree with the principles of free software and copyleft, then the GPL v3 is only an improvement over the GPL. If we don't really like copyleft as an organization then it would make more sense to just adopt BSD, rather than stick with a copyleft license that just has a few loopholes in it. In terms of pros/cons with GPLv2 you'd have compatibility with GPL3 and GPL2+ licenses, as well as the the Affero GPL. There is of course the closing of the tivoization loophole, and that can be considered a pro or a con depending on your personal beliefs. However, if you really are pro-tivoization, then why use the GPL at all? Oh, there exists another option - we could also relicense as GPL2 or 3 - that gets rid of the what if it changes to something bad issue while allowing others to adopt the code under either license. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkSnKG4/rWKZmVWkRApvIAJ98Oj9+pNvRnHXYVeNAElNQ8dUeYwCfeQNN s0QRFW/n1ZNhZm1RabgNaQk= =w0HP -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sunday, 08. July 2007 20:15:31 Harald van Dijk wrote: No, you have to get permission of the copyright holders. Which, in this case, is the Foundation. Could you back that up, please? I was looking for something to confirm or deny this myself, but didn't find anything. It's in the copyright notice of every single ebuild: # Copyright 1999-2007 Gentoo Foundation Thus, the copyright owner/holder is the Gentoo Foundation. The Foundation can therefore decide to change the licence. Note that the Foundation would never change the license used for the code or documentation, if that could be set in stone that would be even better. Is this still relevant? Hopefully not as it is, stated as simple as that, not very wise. It's probably *meant* to say that the Foundation will never switch to a closed-source model but it shouldn't rule out switching to GPL-3 should that turn out to be desirable. Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sun, Jul 08, 2007 at 08:52:30PM +0200, Wulf C. Krueger wrote: On Sunday, 08. July 2007 20:15:31 Harald van Dijk wrote: No, you have to get permission of the copyright holders. Which, in this case, is the Foundation. Could you back that up, please? I was looking for something to confirm or deny this myself, but didn't find anything. It's in the copyright notice of every single ebuild: # Copyright 1999-2007 Gentoo Foundation Thus, the copyright owner/holder is the Gentoo Foundation. If I write an ebuild today, why does it not say Copyright 2007? It's because the copyright notice applies to skel.ebuild and/or the tree as a whole. Whether it also applies to the individual contributions is what I'm curious about. The Foundation can therefore decide to change the licence. If the Foundation is the copyright holder, then agreed, it can. Note that the Foundation would never change the license used for the code or documentation, if that could be set in stone that would be even better. Is this still relevant? Hopefully not as it is, stated as simple as that, not very wise. It's probably *meant* to say that the Foundation will never switch to a closed-source model but it shouldn't rule out switching to GPL-3 should that turn out to be desirable. If you can give a clear way to separate licenses which should be allowable, from those which should not, then please share. Would it mean that the Foundation might change to the CDDL, for example? If not, why not? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sunday, 08. July 2007 21:12:38 Harald van Dijk wrote: # Copyright 1999-2007 Gentoo Foundation Thus, the copyright owner/holder is the Gentoo Foundation. If I write an ebuild today, why does it not say Copyright 2007? Probably because different legal systems require different formats of the copyright notice. Over here, copyright 2007 would be fully sufficient. It's because the copyright notice applies to skel.ebuild and/or the tree as a whole. Whether it also applies to the individual contributions is what I'm curious about. TTBOMK, it applies to each and every individual ebuild. The tree itself doesn't seem to have a separate copyright notice and I see no need for it either. As for contributions without a clear copyright notice, it would, IMHO, be best to make sure (e. g. by adding some legal blah to Bugzilla) they're original works to be licenced under (currently) the GPL-2 or derived from a product with a compatible licence by the contributor. If you can give a clear way to separate licenses which should be allowable, from those which should not, then please share. Sorry, that's both beyond my legal knowledge and my sphere of interest. :) I think we all agree that ebuilds should be released under an open source licence. That's good enough for me. :-) Best regards, Wulf signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Sun, Jul 08, 2007 at 09:42:49PM +0200, Wulf C. Krueger wrote: On Sunday, 08. July 2007 21:12:38 Harald van Dijk wrote: # Copyright 1999-2007 Gentoo Foundation Thus, the copyright owner/holder is the Gentoo Foundation. If I write an ebuild today, why does it not say Copyright 2007? Probably because different legal systems require different formats of the copyright notice. Over here, copyright 2007 would be fully sufficient. If the copyright notice doesn't apply at least in part to skel.ebuild and/or the whole tree, it's not possible for Copyright 1999-2007 to be required anywhere. It's because the copyright notice applies to skel.ebuild and/or the tree as a whole. Whether it also applies to the individual contributions is what I'm curious about. TTBOMK, it applies to each and every individual ebuild. The tree itself doesn't seem to have a separate copyright notice and I see no need for it either. As I recall from previous discussions, the tree as a whole is copyrighted, essentially because it is not clear whether the majority of ebuilds are copyrightable by themselves. As for contributions without a clear copyright notice, it would, IMHO, be best to make sure (e. g. by adding some legal blah to Bugzilla) they're original works to be licenced under (currently) the GPL-2 or derived from a product with a compatible licence by the contributor. If the Foundation needs the right to relicense code, this should also be made clear (e.g. in the legal blah that would be added to Bugzilla). If you can give a clear way to separate licenses which should be allowable, from those which should not, then please share. Sorry, that's both beyond my legal knowledge and my sphere of interest. :) I think we all agree that ebuilds should be released under an open source licence. That's good enough for me. :-) I can agree with that. What I care about is the right to decide on the license for code that is entirely written by myself. I don't really care how the tree is licensed. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Watch out for license changes to GPL-3.
Richard Freeman [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 08 Jul 2007 14:15:43 -0400: Seemant Kulleen wrote: If you can really show some way that GPL3 provides a compelling case to move to it, then we can start talking about that. I wasn't aware that gentoo practiced copyright assignment. You might want to make the disclaimers clear - if somebody submits a patch on bugzilla and doesn't expressly assign copyright they would legally retain it unless it were a clear condition of using the site. Also, it would help avoid people submitting patches that aren't GPL-2-only-compatible from other projects. But then again, I'm not a lawyer... :) Choosing here to jump in, tho this could go elsewhere in the thread. I've done a bit of research on this for my own (scripted) code. Trivial isn't copyrightable. It has to express creativity and etc. There's a bit of a gray line as to what's trivial vs what's not, but the position the FSF takes is that if it's just a few lines, it's trivial. I've seen numbers thrown around as low as three lines or as high as 20, on the arguing on the low side end (so some saying as low as 20 may consider the norm higher but admit there might be a /few/ cases for as low as 20 lines). More specifically, in their licensing recommendations, the FSF suggests that it's /not/ appropriate to use the GPL/LGPL on works short enough that incorporating the whole of the license would make the license the bulk of the work in question. They strongly recommend that works incorporate the whole license in word, not just by reference as to a URL or the like, since those change over time. (This is in contrast to the CC licenses, which encourage incorporation by URL reference, and pledge to keep a more or less stable URL for each version.) The FSF says on such short works, it's better to release in the public domain or under some other less restrictive license. Thus the questions of whether many/most individual ebuilds /could/ be copyrighted or if so whether it's worth doing so. Certainly, it's the tree that contains the license, not the individual ebuilds, etc, which give the copyright statement but little more. Gentoo policy would seem to be, then, that it's the work of the tree as a whole that's copyrighted. Individual ebuilds may or may not be, and it's /implied/ (which isn't necessarily legally binding) that if they are, there'd be little attempt at enforcement unless a significant portion of the tree was copied/modified. Of course, there's also the question of whether an individual ebuild is all that useful in practice, without the rest of the supporting tree structure (not necessarily the individual applications including those developed by Gentoo such as portage, the tree). Certainly without the eclasses, many ebuilds would be in practice almost worthless. So the copyright is on the tree. Note that actual Gentoo apps such as portage, catalyst, etc, are copyrighted individually. The Gentoo policy /does/ state that apps are GPL2ed AFAIK, as is the tree. Then there's documentation, which is not GPLed but generally CC-AT-SA (Attribution Share-alike). I guess one reason to move would be that it is the goal of the FSF for this to become the default GPL. So, if there was a compelling case for adopting the GPL at all (one presumes there was since we're GPL currently), then there is a case for migrating to GPL v3 by that virtue alone. Does that mean that we HAVE to? Certainly not. I'd ask the question why we're GPL at all? If the reason is because we generally agree with the principles of free software and copyleft, then the GPL v3 is only an improvement over the GPL. If we don't really like copyleft as an organization then it would make more sense to just adopt BSD, rather than stick with a copyleft license that just has a few loopholes in it. That's a long and predictably controversial debate. See all the electrons spilled on it debating the Linux kernel, for instance. While I personally support the FSF and GPL3, there's a definitely valid position held by some that the code return requirements of GPL2 are sufficient, that Tivoization should be specifically allowed, because the code is returned, even if it doesn't work on their specific product without the signing keys and etc. Apart from the more specifically enumerated patent protections and wider compatibility of GPL3, which might be worthy shooting for, I don't think the anti-tivoization clauses are much that Gentoo needs to worry about for the tree (possibly for some of the apps) anyway. Of course, there's also the point that what's in the tree is scripted and therefore inherently in source form, and that changing it sufficiently to put it in compiled language form would be a rewrite and of questionable derived status. Certainly, the work to put it in compiled form would be significant. It's also not likely as the
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-07-08 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-07-08 23h59 UTC. Removals: games-action/raptor22007-07-03 20:42:00 nyhm games-fps/unreal-tournament-infiltration2007-07-06 18:49:50 mr_bones_ media-sound/pymp2007-07-07 18:28:26 drac net-libs/soup 2007-07-07 22:09:04 drac Additions: sys-fs/python-fuse 2007-07-02 04:17:58 jmglov dev-java/jflex 2007-07-02 05:51:09 ali_bush app-emacs/doxymacs 2007-07-02 06:44:23 opfer x11-plugins/pidgin-libnotify2007-07-03 00:25:50 tester dev-dotnet/mcatalog 2007-07-03 18:13:30 jurek dev-java/xml-writer 2007-07-03 23:31:59 betelgeuse app-emacs/autoconf-mode 2007-07-04 18:54:00 ulm dev-java/stax 2007-07-04 22:04:03 betelgeuse media-gfx/grub-splashes 2007-07-05 05:05:40 welp games-arcade/ultrastar-ng 2007-07-06 20:58:10 tupone app-emacs/po-mode 2007-07-06 23:05:25 ulm app-i18n/uim-tomoe-gtk 2007-07-07 05:52:33 matsuu x11-misc/superswitcher 2007-07-07 11:34:04 swegener sec-policy/selinux-munin2007-07-07 16:30:11 kaiowas sec-policy/selinux-lpd 2007-07-07 16:34:17 kaiowas sec-policy/selinux-cups 2007-07-07 16:37:11 kaiowas media-video/pymp2007-07-07 18:25:36 drac x11-themes/polyester2007-07-07 22:42:28 keytoaster sys-apps/mlocate2007-07-08 10:26:09 opfer dev-python/python-daap 2007-07-08 18:07:50 drac dev-haskell/filepath2007-07-08 18:12:01 dcoutts app-misc/pwsafe 2007-07-08 18:59:11 taviso -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: games-action/raptor2,removed,nyhm,2007-07-03 20:42:00 games-fps/unreal-tournament-infiltration,removed,mr_bones_,2007-07-06 18:49:50 media-sound/pymp,removed,drac,2007-07-07 18:28:26 net-libs/soup,removed,drac,2007-07-07 22:09:04 Added Packages: sys-fs/python-fuse,added,jmglov,2007-07-02 04:17:58 dev-java/jflex,added,ali_bush,2007-07-02 05:51:09 app-emacs/doxymacs,added,opfer,2007-07-02 06:44:23 x11-plugins/pidgin-libnotify,added,tester,2007-07-03 00:25:50 dev-dotnet/mcatalog,added,jurek,2007-07-03 18:13:30 dev-java/xml-writer,added,betelgeuse,2007-07-03 23:31:59 app-emacs/autoconf-mode,added,ulm,2007-07-04 18:54:00 dev-java/stax,added,betelgeuse,2007-07-04 22:04:03 media-gfx/grub-splashes,added,welp,2007-07-05 05:05:40 games-arcade/ultrastar-ng,added,tupone,2007-07-06 20:58:10 app-emacs/po-mode,added,ulm,2007-07-06 23:05:25 app-i18n/uim-tomoe-gtk,added,matsuu,2007-07-07 05:52:33 x11-misc/superswitcher,added,swegener,2007-07-07 11:34:04 sec-policy/selinux-munin,added,kaiowas,2007-07-07 16:30:11 sec-policy/selinux-lpd,added,kaiowas,2007-07-07 16:34:17 sec-policy/selinux-cups,added,kaiowas,2007-07-07 16:37:11 media-video/pymp,added,drac,2007-07-07 18:25:36 x11-themes/polyester,added,keytoaster,2007-07-07 22:42:28 sys-apps/mlocate,added,opfer,2007-07-08 10:26:09 dev-python/python-daap,added,drac,2007-07-08 18:07:50 dev-haskell/filepath,added,dcoutts,2007-07-08 18:12:01 app-misc/pwsafe,added,taviso,2007-07-08 18:59:11 Done.
