[gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
Zac Medico posted on Fri, 04 Sep 2009 18:06:09 -0700 as excerpted: That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. When a new version of GPL license comes out, we simple add it to that group, and none of the corresponding ebuilds have to be updated. That sounds like a very good EAPI-4 candidate. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
Nikos Chantziaras posted on Sat, 05 Sep 2009 02:19:12 +0300 as excerpted: On 09/05/2009 01:24 AM, Robert Bradbury wrote: Is gnash still under development (as an open source alternative to Adobe flash)? TTBOMK [1], gnash is now a GNU sponsored project, one I believe they are actually paying someone to spend some time on, now, after a free flash alternative came up near the top of the priority list on a user poll they did about three years ago. a quick ggl:gnash later Yes, gnash is a GNU project, at least, tho I'm not sure on the paid developer status. The latest release was 0.8.5_beta4, on March 3, this year: http://www.gnu.org/software/gnash/ If so, then it would seem to make sense to keep the plugin alive. Where does this all go with the evolution towards more open media formats (HTML 3.x?). It is my impression currently that a consensus could not be agreed upon for a standard open non-proprietary format for audio/video files. HTML 5.0, and you're impression is reasonably correct. Based on what I've read, they settled on audio and video tags, but could not come to agreement on specific codecs, because the FLOSS folks couldn't accept a proprietary (patented) codec, and some of the others couldn't/wouldn't accept the current state of open codecs, at least for video (audio I believe they agreed on ogg-vorbis, but check before you rely on that). I believe Nokia was on the proprietary side as they already had a license for whatever, and theora wasn't in a state that would work well on their cellphones and the like. But that's changing, and a further HTML 5.1 version may well have a free video codec as well. Combine that with some of the stuff that's already possible in draft-5.0, and Flash may have a tough fight on its hands. Of course, there's Microsoft Silverlight to worry about too... Flash *is* an open format; Adobe opened up its specs a while ago. It's just that the only full implementation of it isn't open (Adobe Flash). AFAIK, the issue isn't the openness of the format, you're absolutely correct on that, but the fact that some of the most effective and popular flash related codecs have serious software patent issues, at least in areas of the world where such things unfortunately exist. The other factor is that while it's open, Adobe controls the spec I believe, and thus can continue to develop their closed version and not release the updated spec until they release their updated player at the same time (if they choose to update the spec at all, they can just let it fall behind if the chose, too), so open implementations will by definition remain 1-2 versions behind, because by the time they get to a particular spot, Adobe will have likely released a new version and a new spec to go with it. . [1] TTBOMK: To the best of my knowledge. emerge wtf and query it on the command line as wtf ttbomk, if you need a cheat sheet for this sort of thing, or look it up on onelook.com, FWIW, I have onelook setup as the ol: kde web shortcut here, plus wtf. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
On Fri, 04 Sep 2009, Zac Medico wrote: I propose support for license groups in ebuilds then, I guess. That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. So @GPL-2+ would (currently) expand to GPL-2 GPL-3. But that would be wrong, since what you want is || ( GPL-2 GPL-3 ). Ulrich
Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: www-plugins/gnash
Le 05/09/2009 11:25, Duncan a écrit : [...] This is off-topic for gentoo-dev. Please continue this discussion in private. Thanks Rémi
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Ulrich Mueller wrote: On Fri, 04 Sep 2009, Zac Medico wrote: I propose support for license groups in ebuilds then, I guess. That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. So @GPL-2+ would (currently) expand to GPL-2 GPL-3. But that would be wrong, since what you want is || ( GPL-2 GPL-3 ). Right, so naturally, license groups inside LICENSE should expand to || ( licenses in group ). -- Thanks, Zac
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Friday 04 of September 2009 22:08:02 Ciaran McCreesh wrote: On Fri, 04 Sep 2009 22:04:46 +0200 Rémi Cardona r...@gentoo.org wrote: Having tools to manipulate those variables is very misleading since users will (rightfully) assume that we've done our homework and that upstream did too. Why not use EAPI 4 to make sure people have done that homework then? Because it won't make *upstream* do their homework. I suppose you volunteer to make this homework for Gentoo to fulfill new EAPI requirements as I assume your lawyer skills equals the will to propose yet another EAPI. Therefore I fully support this idea. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Sat, 5 Sep 2009 16:03:25 +0200 Maciej Mrozowski reave...@poczta.fm wrote: Why not use EAPI 4 to make sure people have done that homework then? Because it won't make *upstream* do their homework. If upstream won't tell you the licence under which something is distributed, how does Gentoo know whether it's allowed to mirror source tarballs or include the package on binary CDs? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Zac Medico wrote: Sebastian Pipping wrote: I propose support for license groups in ebuilds then, I guess. That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. When a new version of GPL license comes out, we simple add it to that group, and none of the corresponding ebuilds have to be updated. I suppose adding group license support in ebuilds will fix the problem too. But I see a few disadvantages like: - new behavior for @ operator: it will not only expand a group but also adding a || operator (only for LICENSE) - devs will have to maintain new groups - group support in LICENSE has no other need that managing versioned licenses In an other hand, it will prevent us adding a new operator. And Sébastian, I don't understand you when you said GPL-2+ will be confusing for the user as it's a term commonly used in the FOSS world. But if everybody think groups are better, that will be fine. For those who think this feature is useless because we are not lawyers and ebuilds don't care about licenses, I just want to add it will not be a new _requirement_ but a new _possibility_. As Ciaran's said, you already have to check for licenses at the moment. So even if some devs do mistake (or do not update the info) as said Jeremy, we have at least this information. If you know a package is GPL-2 licensed, you can set LICENSE=GPL-2, it's valid, IMO. If you want to go far than that and check if it's GPL-2+, it's better but not _needed_. It's a small feature and it can help. Thanks, Mounir
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
On Sat, 05 Sep 2009, Mounir Lamouri wrote: I suppose adding group license support in ebuilds will fix the problem too. But I see a few disadvantages like: - new behavior for @ operator: it will not only expand a group but also adding a || operator (only for LICENSE) - devs will have to maintain new groups - group support in LICENSE has no other need that managing versioned licenses IMHO the main disadvantage is that ebuilds would have to be converted to EAPI-4 for this, which is quite an effort for a very small improvement. And I guess that there are quite a few packages currently labelled as GPL-2 that are really GPL 2 or later. But if everybody think groups are better, that will be fine. I would prefer a pragmatic solution, like adding new licence files as suggested in [1]. Ulrich [1] http://archives.gentoo.org/gentoo-dev/msg_6c004fd342c57062d71455109fa52ac0.xml
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Mounir Lamouri wrote: Zac Medico wrote: Sebastian Pipping wrote: I propose support for license groups in ebuilds then, I guess. That seems like a reasonable solution. So, an ebuild can do something like LICENSE=@GPL-2+ and that will expand to whatever the definition of the GPL-2+ license group happens to be. When a new version of GPL license comes out, we simple add it to that group, and none of the corresponding ebuilds have to be updated. I suppose adding group license support in ebuilds will fix the problem too. But I see a few disadvantages like: - new behavior for @ operator: it will not only expand a group but also adding a || operator (only for LICENSE) It's just a natural thing to do, given the use case, so I'm not sure that I'd consider it a disadvantage. - devs will have to maintain new groups It actually has potential ease maintenance because of the code sharing aspect. You only have to update the group definition in order to update all consumers of the group. - group support in LICENSE has no other need that managing versioned licenses Not necessarily. I can imagine other cases where the code sharing aspect might be useful. Also, imagine a case such as a version range. Doing that with operators could get messy, but it's quite simple using groups. Considering that licenses tend to have relatively few versions (compared to packages, for example), operators might introduce unnecessary complexity while not having the flexibility that groups have. -- Thanks, Zac
Re: [gentoo-dev] [RFC] Add operator + for licenses (EAPI-4 ?)
Ulrich Mueller wrote: IMHO the main disadvantage is that ebuilds would have to be converted to EAPI-4 for this, Why do they _have_ to? I understand that it's optional and that we can take time with it until a new license (e.g. GPL-4) arrives. Also, scripts/tools can help with the transition. which is quite an effort for a very small improvement. - It's reducing future maintenance costs on new license arrival - It's adding clarity and allows us to express the actual license of GPL 2 or later packages much better. - It increases chances of correct labeling of future ebuilds Sebastian
Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)
On Sat, Sep 05, 2009 at 04:03:25PM +0200, Maciej Mrozowski wrote: On Friday 04 of September 2009 22:08:02 Ciaran McCreesh wrote: On Fri, 04 Sep 2009 22:04:46 +0200 R?mi Cardona r...@gentoo.org wrote: Having tools to manipulate those variables is very misleading since users will (rightfully) assume that we've done our homework and that upstream did too. Why not use EAPI 4 to make sure people have done that homework then? Because it won't make *upstream* do their homework. I suppose you volunteer to make this homework for Gentoo to fulfill new EAPI requirements as I assume your lawyer skills equals the will to propose yet another EAPI. Therefore I fully support this idea. -- regards MM What is your point? If your goal is to come across as a bitter person with a lot of hate then you've succeeded. Tone it down please as you're not contributing anything useful to the discussion like that. Ciaran's really not making homework up for gentoo. Why, remi stated himself that we have homework to do(and we sometimes don't do that homework) so unless you're just trying to pick a fight I don't see what you're trying to say. Please don't do that. Regards, Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpJDFjjFKKHd.pgp Description: PGP signature
