> So now I'm right back where I started.
You win.
Let me correct my statement then: Moonlight will not be easy to use if
you insist in building things your way. But for regular users (those
that do not mind accepting the EULA, or those that do not mind getting
the RPM packages), standard packagers and someone with some minimum of
C experience it will be a breeze.
> I didn't see anything relevant on that site.
It is on the INSTALL file, the very first thing listed there.
> A quick Google for "MoonlightRPM spec" produces this:
>
> http://dries.ulyssis.org/apt/packages/moonlight/info.html
>
> But that just turns out to be "a free software modeller and renderer for
> 3D scenes".
Have someone with Google experience track this down for you.
> I could spend the rest of my evening hunting for this spec file but I've
> better things to do, and I'm not sure it would actually resolve this bug
> anyway, unless there's some patch required to makeMoonlightwork (under
> Fedora). If you're aware of such a patch, perhaps you could just tell me
> about it, and save me some time.
I am not aware of us having any patches specially for Fedora, but I
saw that Jeff checked in a patch for a missing include, maybe it is
related.
> Why don't you read it now, it should only take you a couple of minutes:
>
> http://www.gnu.org/licenses/gpl.html
Reading it does not mean understanding it.
It took me years to understand the GPLv2 even if the first reading was
done in a couple of minutes.
> So what exactly are your concerns and questions about this license?
I do not know, I just do not have enough of an incentive to spend the
time to understand the side effects of it. You could try making a
case as to why I should adopt the GPLv3 instead of the LGPLv2.
> So you've chosen to ignore something you don't yet understand, because
> someone else holds a negative opinion of it.
English seems to confuse you. I am not ignoring it, I have chosen to
not adopt it until the point where I fully understand what it means to
adopt it.
The same applies to any contract you sign. Before you sign it, you
must understand it, not just "skim through it".
> That's an evasive and misleading response, since obtainingMoonlightvia
> the medium is not the issue, it's the ability to upgrade the distributed
> software /in place/, which on an immutable medium, like a LiveCD distro,
> is not possible, and thus contravenes this "anti-embedded" clause you've
> added to the (otherwise) GPL license forMoonlight.
I am pretty sure someone with a LiveCD can upgrade their Mono/
Moonlight if they choose to. In fact, you just gave an example of
how they can do it.
But in addition to the userfs sample, it seems that any user can take
a LiveCD ISO, mount it, upgrade any software they want, and reburn the
ISO, and redistribute the result at will.
So clearly, the LiveCD case is perfectly fine.
> And again, mainly for the benefit of those who lack either the capacity
> or patience to try to build software from sources, I ask you to give me
> some idea of when a pre-compiled binary ofMoonlight, linked to ffmpeg,
> will become available?
A google search turns:
http://packman.links2linux.org/package/moonlight
Or if you want a larger collection try:
http://tinyurl.com/awz75g
> I suppose I should /also/ ask, will such a release violateMoonlight's
> license, or be subjugated by the hidden pitfalls of any supplemental
> restrictions imposed by either Novell or Microsoft?
The restrictions actually come from MPEG-LA, an organization that
relicenses the portfolio of patents required to implement VC-1, H264
and a handful of other media codecs.
The actual list of companies that own the patents shipped in the Media
Pack that you refused to install is:
http://www.mpegla.com/vc1/vc1-licensors.cfm
WIth upcoming Moonlight releases, when we integrate support for H.264,
the list will be augmented to contain:
http://www.mpegla.com/avc/avc-licensors.cfm
Miguel.
|
|
