I restored the attribution you accidentally removed.
Verily I say unto thee, that Miguel de Icaza spake thusly:
> On Jan 25, 6:07 am, Homer <usenet@xxxxxxxxxx> wrote:
>> 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
Translation: There is something inherently wrong with not supporting and
agreeing with Microsoft.
Well, I expected as much from you.
>> I didn't see anything relevant on that site.
> It is on the INSTALL file, the very first thing listed there.
cat INSTALL | grep -i rpm
cat INSTALL | grep -i spec
Still waiting for you to provide me with "RPM spec files that exist for
>> A quick Google for "MoonlightRPM spec" produces this:
>> 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.
Well I was hoping that /you/ could help, but then I forgot you thought
Moonlight's home page was listed at the No1 position on Google for the
search "Silverlight Linux", when in fact it doesn't even appear within
the first ten pages (or possibly more, since I gave up at that point).
> 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
>> Why don't you read it now, it should only take you a couple of
> Reading it does not mean understanding it.
Have someone with reading experience explain it to you.
> It took me years to understand the GPLv2 even if the first reading
> was done in a couple of minutes.
At just 674 words, over a 730 day period, that's a reading comprehension
rate of less than one word per day.
You could probably study to become a qualified lawyer quicker than that.
Have you met Hadron?
>> So what exactly are your concerns and questions about this license?
> I do not know
Although actually, I think you do.
>> 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.
Some of it, yes - the lies mostly.
>> That's an evasive and misleading response, since
>> obtainingMoonlightvia the medium is not the issue, it's the ability
You should really consider using a real Usenet client instead of Google.
You can't wait forever for Microsoft to release Outlook Express for GNU/
Linux, you know. Then again, maybe you're waiting for someone to release
a Usenet client written in Mono, before deeming it worthy enough to use.
>> 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.
No they can't, unless they specifically configure the system to allow a
persistent overlay to be written to a HDD, which they may not have. And
the fact is that licenses pertain to /distribution/, so by distributing
an immutable media containing Moonlight /without/ a commercial license,
that distributor is violating your modified version of the GPL. Clearly
that is /not/ Free Software, and the fact you are claiming Moonlight is
licensed under the GPL is nothing but a sham. At best, this odd license
should be described as "LGPL2.1 with *further restrictions*", but since
the LGPL explicitly prohibits such "further restrictions" it would seem
your license is actually null and void, and Moonlight is essentially an
unlicensed piece of software (thus undistributable). Of course, we have
long known it was undistributable anyway, at least to anyone but Novell
> But in addition to the userfs sample
That's *unionfs*, Miguel.
Here's the project page:
> 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.
Well I could take Moonlight and turn it into Swiss cheese, but then it'd
no longer be the product you shipped, nor subject to the same license. A
LiveCD is "the product", is immutable, and therefore if it's distributed
with Moonlight it violates your license, since the distributor can *not*
guarantee the recipients will necessarily have the additional provisions
required to turn something immutable into something mutable. A recipient
who /changes/ the shipped product into something else, is not using that
original product to which the license applies. /Distributors/ are liable
for the conditions of your license, /not/ the recipients, and the LiveCD
they ship does not fulfil the requirements of your license, therefore no
LiveCD can ever contain Moonlight without a commercial license.
> So clearly, the LiveCD case is perfectly fine.
Certainly ... if you're Novell or their business parters Microsoft.
>> 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:
Finally, a straight answer.
Here's what I want:
Now I'm on home turf.
rpmbuild --rebuild moonlight-1.0_beta1-0.pm.1.src.rpm
warning: InstallSourcePackage: Header V3 DSA signature: NOKEY, key ID
error: Failed build dependencies:
libffmpeg-devel is needed by moonlight-1.0_beta1-0.pm.1.x86_64
alsa-devel is needed by moonlight-1.0_beta1-0.pm.1.x86_64
mozilla-xulrunner181-devel is needed by
Hmm, looks like this needs to be un-SUSE-ed for Fedora.
Fedora has no separate "libffmpeg-devel", it's part of "ffmpeg-devel".
Conversely, on Fedora "alsa-devel" is actually "alsa-lib-devel".
XULRunner is a problem though, since it's not packaged for Fedora 8, and
I haven't yet determined if the F9 package will even build here, or even
if I can meet the dependencies for building it ... without /essentially/
upgrading my system to F9 or 10. I could (and will) do that, but not any
time soon (like I said, I have better things to do).
OK, so let's have a look inside:
rpm -ivh moonlight-1.0_beta1-0.pm.1.src.rpm
warning: moonlight-1.0_beta1-0.pm.1.src.rpm: Header V3 DSA signature:
NOKEY, key ID 9a795806
1:moonlight ########################################### [100%]
If this works, I'll sign it locally, so I don't care about keys ATM.
A /copyright notice/ ... for a /spec/ file?
Here's the license for the package proper:
License: LGPL v2.0 only
There's no such canonical group on RH/FC systems.
According to /usr/share/doc/rpm-22.214.171.124/GROUPS the nearest equivalent is
Perhaps you should also put a warning in the comments, about the need to
%define pkg_version 1.0b1
Please try to use numerical-only major and minor version descriptors.
Again ... eugh!
Can we have meaningful patch names, please?
And why the *.txt extension? This ain't MS DOS, you know. Try *.patch or
Well I've got to the end of the build opts, and there's nothing suggests
any way to disable the buildrequires for XULRunner at all, beyond simply
removing all references to it. Bad, bad, bad.
This made me laugh:
# Fedora options
Next up, we have the %description...
O h M y G o d!
A /credits/ list ... in an RPM spec %description!
Get over yourselves, Novell, and keep it concise. This field is supposed
to describe the package's /function/, it's not a PR exercise.
At least you got the first bit right:
"Moonlight is an open source implementation of Microsoft Silverlight for
I notice you didn't say "Free Software", because it certainly isn't.
%files -n libmoon0
%defattr(-, root, root)
Generally, the more explicit %defattr(-,root,root,-) is preferable. Rule
No1: Never make assumptions.
Overall the spec's layout is a bit of a mess. Currently you have all the
manifests dotted all over the place. My preference, and that of RH/FC is
to have a single manifest at the end of the spec, just before the change
Talking of which:
* Tue Nov 11 2008 rhowell@xxxxxxxxxx
This is who needs to see the above comments, assuming he cares.
> Or if you want a larger collection try:
Google home page. For all I know it might be a phishing scam, so I think
love about Free Software ... it works /for/ me, not against me.
>> I suppose I should /also/ ask, will such a release
Urgh! Please, please, please just get a proper Usenet client. Please.
>> 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
No, the restrictions come from Novell, or whoever provides the software
for which I am licensed to use.
I don't recall ever downloading anything from anyone called "MPEG-LA".
I use ffmpeg, and I don't see any similar restrictions in /its/ license,
nor any mention of anyone called "MPEG-LA".
What kind of software does "MPEG-LA" develop?
> an organization that relicenses the portfolio of patents
Portfolio of what, now?
I don't use software patents ... I use software, so I really don't know,
much less care anything about such things, beyond the fact that software
patents seem to be a profoundly immoral protection racket run by equally
immoral racketeers. Apparently the ffmpeg developers think so too:
So, you were about to explain why you have this strange "anti-embedded"
clause in your license...
| "Necessity is the plea for every infringement of human freedom. It
| is the argument of tyrants; it is the creed of slaves." ~ William
| Pitt the Younger
Fedora release 8 (Werewolf) on sky, running kernel 126.96.36.199-60.fc8
04:06:10 up 81 days, 11:49, 5 users, load average: 3.79, 3.93, 3.98