public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Bret Towe <magnade@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] mac/xmms-mac licence issue
Date: Sat, 24 Dec 2005 19:22:50 -0800	[thread overview]
Message-ID: <dda83e780512241922k788688f8h6ed1ac1bcaeb67d7@mail.gmail.com> (raw)
In-Reply-To: <20051225025114.GJ5796@nightcrawler.e-centre.net>

On 12/24/05, Brian Harring <ferringb@gentoo.org> wrote:
> License in question...
>
> http://bugs.gentoo.org/attachment.cgi?id=35862&action=view
>
> On Sat, Dec 24, 2005 at 06:11:53PM -0800, Bret Towe wrote:
> > earily today i updated the ebuilds for mac and xmms-mac,
> > for those that dont know their applications for monkey's audio (.ape files),
> > and got them submited to bug 94477[1] which was closed
> > due to the way the licence was done
>
> Original license really sucks... doesn't matter if someone has grabbed
> the code and labeled it lgpl2, it still is under the monkey license.
>
>
> > my issue is i think the ebuilds should be commited to portage
> > as i dont see how the licence or issues that app has anything todo
> > with a gentoo ebuild as all the ebuild does is fetch and install
> > and its only told todo so upon the user requesting it to be so
> > hence its the users choice to deal with the licence rather than
> > the developers desiding for that user
>
> We're not deciding what licenses users should use (despite pushes from
> both extremes looking to enforce their license view on others).
>
> That said, it's not actually the issue at hand.  Issue at hand is
> violating someone else's license (clarified below).
>
> > i can understand putting proper warning in the ebuild if the dev
> > thinks that its worth the user really noting the issues surrounding
> > it, not forcing their ideals onto the user
> > if i wanted that i would run debian
>
> See above, and drop the rhetoric please.

im sorry for attempting to get my idea across

> >
> > for those that havent figured it out yet from reading the above
> > i dont care the politics of the issue with the licence all i want
> > is the functionality of the ebuild concerned
>
> Politics do suck.
>
> That said, lawyers crawling up your ass sucks worse.
>
> Bluntly, you're asking a collection of devs, who have their own
> contributions protected by licenses, to ignore a source base's
> license.  That's going to be one hard sell. ;)
>

i thought i was asking how commiting this can even affect the devs
or gentoo in general

> > if it is the case that the devs believe the user is totally incapable
> > of making choices for themselfs then i suggest putting up
> > somewhere noting it as such
>
> Again, ixnay rhetoric; if we violate the license (which we would be
> doing), we're responsible (along with user who uses it).

how does that work? an ebuild is a script or do you mean by the dev
testing it they also perform the same action as the user would?

> It doesn't matter if someone else has picked up the source and labeled
> it as lgpl, unless the new project has *express* permission from the
> original author, they're not even allowed to screw with the source-
> the new project could be viewed as a new program.
>
> Barring the new program angle, there still is the requirement all
> fixes/changes be contributed back to the original upstream.
>
> Original upsream being dead means it's effectively impossible to
> improve the source.

orignal doesnt matter as long as someone is

> This is why the original license is a major issue.  Effectively,
> the codebase cannot be improved/fixed without the original author, due
> to restrictions keeping the code bound to him/her. If he/she goes
> mia, the project is dead developmentally due to the restrictions,
> which makes putting the package into portage an even harder sell.
>
> Jakub responded in this thread about shipping a crap license... imo,
> that's not the issue.
>
> The issue is that we would be knowingly violating a license (however
> horrid the license is).
>
> Two routes out of this- clean room reimplementation of the codec, or
> someone manages to track down the original author and gets the code
> converted to a different license.  Latter still is tricky, since any
> contributions to the project, you would need all authors to sign off
> on the new license- this is assuming the project doesn't do
> centralized copyright, and assuming people have actually contributed
> to it beyond original author.
> ~harring

i think that is beyond the scope of this list :)

and again i am sorry if i seem to repeat myself a bit but i find
people i talk to ether dont get what im talking about or dont listen
so i end up going in circles trying to beat what im saying into their head

-- 
gentoo-dev@gentoo.org mailing list



  parent reply	other threads:[~2005-12-25  3:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-25  2:11 [gentoo-dev] mac/xmms-mac licence issue Bret Towe
2005-12-25  2:37 ` Jakub Moc
2005-12-25  2:51 ` Brian Harring
2005-12-25  3:10   ` Re[2]: " Jakub Moc
2005-12-25  3:22   ` Bret Towe [this message]
2005-12-25  3:34     ` Brian Harring
2005-12-25  3:43       ` Bret Towe
2005-12-25  3:02 ` Carsten Lohrke
2005-12-25  3:17   ` Bret Towe
2005-12-25  3:25     ` Ciaran McCreesh
2005-12-25  3:35       ` Bret Towe
2005-12-25  3:42         ` Daniel Ostrow
2005-12-25  3:47           ` Bret Towe
2005-12-25 14:17         ` Luis F. Araujo
2005-12-25 16:04       ` Curtis Napier
2005-12-25  3:28     ` Brian Harring
2005-12-25  3:32     ` Daniel Ostrow
2005-12-25  3:38       ` Bret Towe
2005-12-25  3:49       ` Ciaran McCreesh
2005-12-25  3:32     ` Re[2]: " Jakub Moc
2005-12-25  3:41     ` Dale

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dda83e780512241922k788688f8h6ed1ac1bcaeb67d7@mail.gmail.com \
    --to=magnade@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox