Moonlight is ostensibly 'licensed under the terms of the GNU LGPL 2 license only (no "later versions")'.
Here's part of LGPLv2.0:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
But Novell have indeed "imposed a further restriction" to the license for Moonlight:
We consider non-LGPL use instances where you use this on an embedded system where the end user is not able to upgrade the Moonlight installation or distribution that is part of you product (Section 6 and 7), you would have to obtain a commercial license from Novell
This "further restriction" is explicitly prohibited under the LGPL, therefore Moonlight is non-Free.
“Since I am not a Novell customer, I therefore cannot use this software.”This would, for example, prohibit Moonlight from being distributed on immutable systems such as a LiveCD, since the software on such a medium cannot be updated in place by the recipient. LiveCDs can sometimes be installed of course, but that doesn't alter the fact that "the product" is immutable, and therefore in violation of Moonlight's license if it distributes that software. LiveCD's can also be "remastered", but then that essentially changes "the product" to something else, created by someone else. In any event, the above clause is a "further restriction" which violates the LGPL, and hence the software is not Free, regardless of the semantics of this clause, and regardless of Novell's false claim that immutable systems are inherently in violation of the LGPL.
Of course there are other even more insidious things which make this software non-Free, such as the fact that only direct "Downstream Recipients" of Novell are indemnified against the use of Microsoft's patented technology in this software. Since I am not a Novell customer, I therefore cannot use this software. Again, this is not an attribute of Free Software.
Could you make it explicit about what Microsoft is doing to get people addicted.
Let me begin my answer to that question by quoting Bill Gates himself:
Gates shed some light on his own hard-nosed business philosophy. "Although about 3 million computers get sold every year in China, but people don't pay for the software," he said. "Someday they will, though. As long as they are going to steal it, we want them to steal ours. They'll get sort of addicted, and then we'll somehow figure out how to collect sometime in the next decade."
Microsoft have three main mechanisms by which they "addict" users to their products:
Examples:
"I'm thinking of hitting the OEMs harder than in the past with anti-Linux. ... they should do a delicate dance," Kempin wrote to Ballmer, in what is sure to be a memorable addition to the phrases ("knife the baby", "cut off the air supply") with which Microsoft enriched the English language in the first trial. Unlike those two, this is not contested.' ~ The Register
There are two reasons for this: First, only Microsoft and its "partners" have the necessary grant of authority to utilise their patented technology (either fully or at all), and second, Microsoft has the habit of deliberately introducing undocumented features into their software in order to make it work differently to the published standard, and thus make the end results (e.g. documents) non-interoperable with other software which follows those standards properly. This then induces a dependence on Microsoft's proprietary implementation (and thus - their software). A perfect example of this is OOXML, which Microsoft has already admitted they will arbitrarily change to suit their own purposes:
Microsoft won't commit to the open document standard it's pushing so hard
...
Now consider this from Brian Jones, a Microsoft manager who has worked on OOXML for six years. In July, Jones was asked on his blog whether Microsoft would actually commit to conform to an officially standardised OOXML. His response:
“It’s hard for Microsoft to commit to what comes out of Ecma [the European standards group that has already OK’d OOXML] in the coming years, because we don’t know what direction they will take the formats. We’ll of course stay active and propose changes based on where we want to go with Office 14. At the end of the day, though, the other Ecma members could decide to take the spec in a completely different direction. ... Since it’s not guaranteed, it would be hard for us to make any sort of official statement.”
Now that’s cynical. After all this work to make OOXML a formal, independent standard — a standard created and promoted by Microsoft, remember — Microsoft won’t agree to follow it.
There are many, many such examples, indeed it's difficult to find any software technology which Microsoft has not at least tried to pervert to their own ends.
Why do you suppose Microsoft battled with Netscape so ferociously? Netscape didn't sell a competing OS, and Microsoft didn't sell a browser, so why the need to "cut off Netscape's air supply"? That battle was not about products, it was about standards. Microsoft needs to control those standards, in order to maintain its monopoly. Exactly the same thing goes for OOXML vs ODF, and .Net (Mono/DotGNU) vs Java. This is why DotGNU is wrong, because it only serves to further Microsoft's "standards dominance", and lest we forget, Microsoft operates it's business like gangsters. This is not the kind of company anyone should be supporting, in any way at all, much less supporting them by giving them the very weapon they need to win.
Microsoft accomplishes this primarily using bribery, which sometimes takes the form of cash or commodity gifts (e.g. laptops), is sometimes masked as "marketing assistance" (in at least two documented cases), and often takes the form of lobbying (a.k.a. legalised bribery).
Another means by which Microsoft spreads its propaganda is via "Industry Analysts", which it hires legitimately, although in a clandestine fashion, to produce illegitimate "studies", which are either outright lies or gross misrepresentations of the truth.
And finally there's Microsoft's chief goon, Steve Ballmer, who claims "Linux violates 235 Microsoft patents", "Linux is a cancer", "Google reads your E-mail", "Red Hat's customer's owe Microsoft money", and many other examples of FUD to dissuade people from using Free Software like Linux, and thus "addict" them to Microsoft's products.
Comments
Dan O'Brian
2009-02-09 13:27:14
Also, the restriction you pointed out is to prevent "Tivoization". Tivoization is something that Richard Stallman is against and so I'd bet anything he'd side with Miguel on this particular restriction because Tivoization restricts user's freedoms.
Dan O'Brian
2009-02-09 13:36:09
Stop being disingenuous.
The Moonlight developers purposely added the feature to Moonlight to allow it to download the codecs directly from Novell/Microsoft so that you could easily redistribute Moonlight itself without making it difficult for recipients to get Moonlight fully working with codecs.
Roy Schestowitz
2009-02-09 14:46:02
saulgoode
2009-02-09 14:46:21
It is not the LGPL which is forcing project contributors to permit commercial re-licensing here, it is Novell. Isn't this basically what Michael Meaks criticized Sun for with the OO.o project's licensing a while back? Is there a reason this criticism should apply for one project and not the other?
Dan O'Brian
2009-02-09 14:48:56
How many times does this have to be explained to you?
Roy Schestowitz
2009-02-09 14:52:28
Dan O'Brian
2009-02-09 14:56:03
Miguel has explicitly stated that Moonlight can be redistributed on a LiveCD. There's no point in further discussing that because it is Miguel's product. If he says it can be redistributed on a LiveCD, then it can be redistributed on a LiveCD.
Perhaps their restriction wording is poor, but you could ask them to clarify that. Attacking them for something that you already know is false (Miguel already told Roy and Homer that there is no problem with redistributing Moonlight on a LiveCD a few weeks ago on comp.os.linux.advocacy, which is where this the first half of this article comes from).
Nothing Roy says can be trusted because he purposely attempts to mislead his readership by not posting all of the facts. Miguel responded to this very accusation already on COLA, but did Roy bother to post his reply here? No, he did not.
And why did Roy not post Miguel's reply? Because it would have destroyed Slated's (aka Homer's) argument.
Dan O'Brian
2009-02-09 14:56:54
How many times must we go over this?
Your concerns have been addressed.
Roy Schestowitz
2009-02-09 14:59:18
Dan O'Brian
2009-02-09 15:08:36
Roy Schestowitz
2009-02-09 15:24:26
Dan O'Brian
2009-02-09 15:37:08
You hide your real concerns among a pile of your own lies - no wonder no one can figure out your real concerns.
As far as control - that's about Microsoft and content providers who want to DRM their content, not about Moonlight. Moonlight does not convince content providers to use Silverlight over Flash or any other player, nor does it convince content providers to use DRM.
Stop with your ridiculously false insinuations and perhaps people will actually start to take you seriously.
Roy Schestowitz
2009-02-09 15:39:28
Jose_X
2009-02-09 18:06:37
If it isn't, then various customers won't need a commercial license from them since they can go by the terms of the lgpl[*]. If they are correct, then there is no problem; however, the livecd case has always been considered a safe case. No matter the medium, the lgpl says that you can try to reverse engineer and that you can copy/modify for you own use (meaning since you can read the CD, you can copy it).
[*]If they are incorrect, do note that this means their licensing scheme as per that linked page would be inconsistent. I don't know what a judge would rule; however, it is important, if people think that licensing scheme is inconsistent, that Novell be called on it since otherwise the actual license might not be lgpl as many would believe. But a judge may allow lgpl since that appears to be the intention, and the source tarball might even say that.
Dan, I would like to know what Miguel says (actually, I can guess the gist from what you said); however, that won't ever win out in court over what Novell publishes. As I just said, if Novell's license is inconsistent, and it may be, then Miguel's intentions won't go very far.
My guess is that the lgpl would rule in court and Novell's interpretation of the use they mentioned that might violate the lgpl would be adjusted/limited to be consistent with the lgpl.
In short, if you disagree with Novell's interpretation, then you may want to worry some and seek clarification from them or assume the lgpl was not the license. Keep in mind what I (a nonlawyer) said above. If you want to play by odds, I would guess that lgpl would rule the day (including livecd use). Some users intending to embed as per that page might assume the lgpl will rule in court and mean they don't need a commercial license [then Novell might sue, etc, etc.]
Roy's, other running theme in the blog entry and in his comments have to do with the foolishness (IMO) of helping to spread moonlight/silverlight. If you want freedoms and maybe even $0 software for all lgpl uses, I would avoid all Microsoft designed standards/protocols. The ball is in their court to hurt you: http://boycottnovell.com/2009/02/04/the-api-trap-part-1/ . I also would not want to help support the huge investments and control Microsoft has when we go play in their court: http://boycottnovell.com/2008/11/25/jose-on-mono/ and http://www.linuxtoday.com/it_management/2009020901035NWMS . Why market to help them? Why volunteer code for them? Complain if websites use proprietary silverlight. It's simple to do, and so long as silverlight remains low volume, it will be effective, which is a good thing -- to avoid any further Microsoft proprietary monopolizations.
seller_liar
2009-02-09 21:44:36
Dan O'Brian
2009-02-10 00:47:28
The second part of your post is irrelevant to Roy's lies claiming that Moonlight is not Free Software (which is the title of this article, btw).
I want to know what reality you trolls live in where spreading lies about a project is acceptable behavior.
Slated
2009-02-10 01:00:02
Oh looky ... the Microsoft/Novell apologist is still frantically astroturfing. What a surprise.
According to Miguel, "OOXML is a superb standard" too, so you'll have to forgive me if I tend to find de Icaza's opinions rather less than compelling.
Really? I don't see the word "Tivoization" mentioned anywhere in the license. What I do see is the statement "embedded system where the end user is not able to upgrade the Moonlight installation or distribution that is part of your product", and that is an accurate description of a LiveCD, as well as other examples of perfectly legitimate immutable systems which do not violate the GPL.
If Novell (yes, Moonlight is owned and licensed by Novell, not Miguel de Icaza) really wanted to prevent "Tivoization", then they should have used GPLv3, since that is one of the main reasons it was created in the first place, after all. But ... they chose not to.
Why is that, Danny?
Stop lying.
Again, the word "codecs" does not appear anywhere in Moonlight's license, but it clearly states this further restriction applies to Moonlight itself:
No mention of "codecs" there. This license is a legally binding document, which explicitly prohibits non-commercially licensed use of Moonlight on immutable systems. This further restriction violates the GPL, therefore Moonlight is non-Free.
Oh, and thanks for agreeing with me that this clause is indeed a "further restriction".
And you know this how, exactly, because (again) it doesn't say anything about any of that in the license, which is after all the only legally binding statement WRT actually using the software.
Also, do you think it's appropriate to mandate that people who use one piece of softwaremust have access to another specific piece of software (codec) ... by stipulating that as a condition of usage in a license for what is supposed to be Free Software, especially when that "other" software is proprietary and patent encumbered.
I don't, and I think you'll find Stallman wouldn't either.
Why don't you ask him, since his opinion is so important to you.
Jose_X
2009-02-10 01:14:57
Well, he doesn't have to say that lgpl allows livecd. That is known.
Miguel is not the owner of moonlight or is he? If he isn't, then his opinion is nice (is he a lawyer?), but doesn't legally clarify anything. Only the owner can do that.
So what was you point of bringing up Miguel's discussion except as an added opinion to this conversation?
Or was Miguel speaking on behalf of Novell? If so, I think Novell should clarify what they put in writing or hopefully put out a written statement on their website that matches what Miguel said on some forum. I don't think a comment by "Miguel" is good enough (if that is what happened).
And note, I am not saying Miguel is wrong. If Novell intended for lgpl, then the livecd is not a questionable point. Miguel doesn't even have to say that.
However, did Novell use the lgpl license.....? [see next part]
>> The second part of your post is irrelevant to Roy’s lies claiming that Moonlight is not Free Software (which is the title of this article, btw).
The second part of what I said is relevant to the second half of his blog posting (go back and read it if you don't remember) and is also relevant to almost all of his comments to you above.
Moonlight is free software **if** it is lgpl, but if Novell says it's lgpl and then adds a restriction inconsistent with the lgpl, then Novell did not really license it lgpl. Novell would have made an inconsistent mistake in that case.
Roy thinks or thought Novell's comment wrt embedded is inconsistent with the lgpl.
Roy has a legitimate concern. If he is correct about the inconsistency (interpretation of lgplv2), then Novell made a mistake and the license of moonlight is unclear.
I don't see the problem with this blog posting (there may be a different mistake.. I didn't use a fine comb) and don't see where you get "trolls" and "lies" from (except that maybe you misunderstood).
I don't know if Roy agrees with what I just said, but that is what I got from reading Novell's statement and the beginning of section 6 lgpl2. And I think this view is consistent with what Roy wrote at the top.
[I initially thought you were correct Dan, so if I also thought along the lines of what I think you said but then changed my mind, surely there is room for misunderstanding.]
Jose_X
2009-02-10 01:24:00
If Novell has done that (and they are a big corp with lots of professional lawyers to look this over and provide a clearer statement), then they should be called on it even if one thinks a judge may rule for lgpl licensing.
As concerns the second half of the blog posting, let's not encourage tiny marketshare silverlight to grow, especially among the FOSS world: http://boycottnovell.com/2009/02/04/the-api-trap-part-1/ http://boycottnovell.com/2008/11/25/jose-on-mono/ and http://www.linuxtoday.com/it_management/2009020901035NWMS
NotZed
2009-02-10 01:35:58
And livecd's? No no no.
You can take a livecd, copy it, and change whatever you like on it before you burn it again. Anyone can do it, it isn't hard. It might be worded a bit clumsily, but the intent is clear, that this is not a problem. Otherwise it would be a problem for the GPL in general, and clearly it isn't.
This is NOT the same as having a ROM on an embedded device which cannot be updated by the user.
It isn't really about tivo-isation either, you can update the firmware on a tivo, it just wont run your changed image - if i understand correctly (to be honest, I haven't followed the story closely since I don't intend to ever buy a tivo).
I reckon they're just clarifying conditions which are already present in the license, section 6.
"6. As an exception to the Sections above, you may also compile or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications."
I would say a rom or non-user-updatable firmware mechanism already falls foul of this part, and 6(a). The clarification just says if you want to use this library in this situation, you can get a license from Novell directly - since you simply cannot use the software based on the terms of the LGPL.
In my opinion there are other areas of question with mono (mostly for me it is merely a political issue), but this nonsense about them breaking their own LGPL is clearly incorrect.
PS unrelated, I wonder if they noticed this little gem:
3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices.
So someone could take a 'LGPL 2.0' library and release it as GPL 3 or newer?
Roy Schestowitz
2009-02-10 01:38:05
Slated
2009-02-10 01:42:28
No he didn't make it "very clear" at all, what he wrote was "You can upgrade Moonlight if you obtain it from a LiveCD", which has nothing to do with upgrading Moonlight in place, on that LiveCD (i.e. the "product" as it pertains to the license).
Consider the following three scenarios:
A LiveCD which does not come with a built-in installer An end-user with a system that lacks any writable media, but who uses a LiveCD instead, with or without an installer (he can't use the installer in either case) An end-user who takes the LiveCD from (1) above, and remasters it from sources to include Microsoft's proprietary codecs
In (1), that LiveCD is immutable, cannot be installed, and therefore Moonlight cannot be upgraded/changed/extended by installing it onto the HDD first, nor in place on the medium itself (the "product"). In this case, the product is clearly in violation of Moonlight's license, unless it utilities a commercial license from Novell.
In (2), that LiveCD is still immutable, can theoretically be installed, but cannot in practice, since the end-user lacks the means to do so. IOW Moonlight's license in presumptive about what the end-user is able to do, and puts the onus of legal responsibility for the end-user's capabilities onto the distributor. But in any case, this still ignores the fact that the license pertains to "the product" ... not what might theoretically be accomplished with that product under the right circumstances (the law does not make such presumptions). "The product" is still immutable, and therefore cannot distribute Moonlight without a commercial license.
In (3), "the product" is changed by the end-user into something which was not originally distributed by the distributor, thus changing it into something which is not "the product" as it pertains to the license, and not created by the distributor, but someone else. Also, please note that this new "product" is itself non-distributable, since it now contains proprietary software (Microsoft's codecs). The license clearly pertains to the actual product that is distributed (this is the legal interpretation of "licensing"), and the "product" in question is immutable, and therefore cannot distribute Moonlight without a commercial license.
Therefore ... Moonlight is non-Free.
QED.
Dan O'Brian
2009-02-10 01:51:02
What NotZed said is correct.
Moonlight is licensed under the LGPL v2. The Microsoft codecs are distributed separately (Moonlight will download it directly from Microsoft so that the end-user is legally covered by Microsoft's covenant).
Get over it already. It's Free Software.
Dan O'Brian
2009-02-10 01:52:40
(Btw, in a previous interview that Roy did with RMS, RMS stated that Moonlight was in fact Free Software).
Roy Schestowitz
2009-02-10 01:54:00
Dan O'Brian
2009-02-10 02:03:19
Roy Schestowitz
2009-02-10 02:29:00
Slated
2009-02-10 02:39:01
Correct. The LGPL is merely a template which may be used as the basis for a license, but if that license is not a verbatim copy of the LGPL (i.e. has further restrictions), then it is misleading to describe the software as being licensed under the "LGPL" ... because it isn't. At best, the license should be described as "LGPL2.0 with modifications".
But there is an even more important point ... see my next statement:
Actually ... yes they can, if that license is self-contradictory.
Consider this extremely simple license:
"You may use this software, provided you do not use this software".
That license contradicts (and therefore violates) itself.
Now consider Moonlight's license:
"[LGPL 2.0] You may not impose any further restrictions on the recipients’ exercise of the rights granted herein ... [CLAUSE] [you may not distribute Moonlight] on an embedded system where the end user is not able to upgrade the Moonlight installation or distribution that is part of you[sic] product"
That is a self-contradicting license, which violates itself, regardless of whether it is called "the LGPL" or "the Mickey Mouse License".
Consider network routers which come with Linux and busybox embedded into a PROM chip. That accounts for nearly every router on the market. Does Novell "consider" all of those products to be "non-LGPL use instances" too?
Obviously Novell are wrong.
No, they've added a further restriction to the LGPL, but continue to falsely claim the software is licensed under the LGPL, which due to this self-contradiction - it isn't. IOW they're lying, and misleading people into believing this is Free Software when it isn't.
But then it isn't "the product" as it pertains to the license. FYI "the product" is that which is distributed, since licensing pertains to distribution, not what might theoretically be accomplished with that product under the right circumstances by the recipient.
Rubbish.
I dare you to go onto the Ubuntu forums, and find more than a handful of users, out of the thousands there, who could modify any LiveCD, and still have a working LiveCD afterwards.
If that's the case, then this "clarification" is redundant, and should be removed.
But let's have a look at this "Section 6" to see what it really says:
Read that again.
Note the subject of that phrase is "terms" ... "provided that the terms permit" ... not the "hardware", but the "terms".
Section 6. of LGPL 2.0 says nothing about embedded or otherwise immutable systems, it refers only to licensing conditions which permit modification. IOW if the distributors of a LiveCD (or a router with embedded Linux) also provide the sources to that immutable medium, then they are not in violation of the (L)GPL.
But they would be in violation of Moonlight's modified LGPL, since that license explicitly prohibits embedded/immutable systems.
Case closed.
No. Only the copyright owner can ever change the license, unless that original licensor specifies "GPL vX.X or (at your discretion) any later version" in the license terms he provides for that software.
Dan O'Brian
2009-02-10 02:49:44
Miguel states that it is acceptable for anyone to distribute Moonlight on a LiveCD. The LGPL makes it acceptable for anyone to distribute the software on a LiveCD.
Accept the fact that you guys are wrong.
Roy Schestowitz
2009-02-10 02:58:28
Dan O'Brian
2009-02-10 03:00:43
I just confirmed with the Moonlight developers.
Dan O'Brian
2009-02-10 03:01:52
Unlike you, I'm actually correct.
Roy Schestowitz
2009-02-10 03:02:14
Roy Schestowitz
2009-02-10 03:03:32
I could say the exact same thing, but then we'd have an argument of 5-year-olds.
Dan O'Brian
2009-02-10 03:07:45
Dan O'Brian
2009-02-10 03:08:59
Well, seeing as how all of the facts are on my side and none of the facts are on yours, it would just make you a liar.
Roy Schestowitz
2009-02-10 03:16:36
Dan O'Brian
2009-02-10 03:26:09
The end result is that what the openSUSE guys said was meant is really what was meant. They changed the EULA to make it more clear, but they were never wrong.
Just like I'm not wrong here.
If you wanted clarification about something, don't you think that the appropriate way of getting clarification might be to, oh, I don't know, ...ask?
Instead you attacked and spread false information (which is very typical of what you do).
If, after getting clarification, you still disagreed with the license (or whatever), then write an article about that - but don't spread lies about Moonlight not being Free Software without a statement from a lawyer (or, better yet, RMS) stating that Moonlight is not Free Software.
Jose_X
2009-02-10 03:39:07
Dan, the official is what is found in the product not on boycottnovell.
Regardless, read Slated's argument here http://boycottnovell.com/2009/02/09/moonlight-is-not-free/#comment-59498
Alternatively, I wrote the following up before reading his.
***
>> If Novell own the copyright, they can do whatever the hell they like with the license - they cannot ‘violate’ their own copyright license.
Short answer: the lgpl is copyrighted by the fsf I believe. It is not Novell's license.
I'm not sure if adding a restriction would make for an inconsistent license (as I stated earlier) if they state that the restriction supersedes the lgpl license text (they should be more clear so as not to leave confusion and state what part of the lgpl would be amended).
However, they seem only to be adding their interpretation of a part of the lgpl, but that might be inconsistent with existing practice and/or fsf views. Novell should be called on this if that were not the established meaning of the lgpl since then they would otherwise be extending the meaning of the lgpl and thus possibly be weakening the lgpl interpretations for everyone else.
Consider instead that in effect they are creating their own license. Let's say they add things that would not be a part of the lgpl, then they would have created a new license that was not the lgpl, but was the lgpl+something ("Novell's lgpl+something" license). In this case, they would be creating a derivative work of the lgpl work. The fsf may give them permission or else Novell would have to rewrite this license from scratch to get the effect they want.
Remember, people could add their own interpretations and clauses. That is fine so long as they don't claim it is something else. The lgpl is a very precisely defined work owned by the fsf who permit others to use it to license their own products. You can't claim something is lgpl but then give license terms that would be inconsistent with the lgpl.
I'm not sure. IANAL.
***
>> Moonlight is licensed under the LGPL v2.
Repeating that doesn't change the fact that Novell may have added a restriction inconsistent with the lgpl. If there is an inconsistency, then the license of moonlight is something besides lgpl even if Novell "references" the lgpl within that license.
>> If you want to continue claiming that Miguel and everyone else are wrong about Moonlight being Free Software, please provide documentation from a lawyer or Richard Stallman saying otherwise.
Roy, as Dan said, consider bringing this up with a lawyer or with the fsf. We are not lawyers. [I don't even play one on tv.]
I mostly agree with the argument/interpretation Slated just provided, but I am not sure.
[Eg, "Section 6. of LGPL 2.0 says nothing about embedded or otherwise immutable systems, it refers only to licensing conditions which permit modification. IOW if the distributors of a LiveCD (or a router with embedded Linux) also provide the sources to that immutable medium, then they are not in violation of the (L)GPL."]
The key issue for me is what defines "work" as used in section 6.. does it include the physical media or not? Copyright law says something about this (work, distribution, derivative, copying..), but the lgpl has its own definitions as used within the context of that license. I do tend to think Novell is wrong, but I'm not sure.
>> Unlike you, I’m actually correct.
Given we are talking about legal interpretations and none of us are lawyers, I think this is bordering on "an argument of 5-year-olds."
>> Well, seeing as how all of the facts are on my side and none of the facts are on yours, it would just make you a liar.
Not sure if you are reading the arguments carefully, Dan.
The argument is that Novell's license is not the lgpl even though they reference the lgpl as part of their license of moonlight.
>> If, after getting clarification, you still disagreed with the license (or whatever), then write an article about that - but don’t spread lies about Moonlight not being Free Software without a statement from a lawyer (or, better yet, RMS) stating that Moonlight is not Free Software.
I'm not sure what wording should be used in the blog, but there have been arguments provided to show why there is doubt that Novell has not licensed moonlight as per the lgplv2.
>> And they changed the EULA to be more clear that it was exactly what the openSUSE guys insisted, did they not?
Novell can have their own interpretation of what the lgpl means, but if they go writing that up in their license and others disagree, then, naturally, others will disagree whether Novell actually licensed as per the lgpl.
Novell should let the lgpl speak for itself or otherwise add elsewhere that they have X interpretation of what the lgpl means but that the actual license is plain vanilla lgpl (whose meaning was defined by its authors, the fsf).
This is a minor point.. unless you completely disagree with the embedded clause being an interpretation of the lgpl and wanted to exploit that without getting a commercial license.
Jose_X
2009-02-10 03:48:39
Right now, each side thinks they have a point, but we aren't lawyers.
I think the arguments of Slated+friends have merit. Worst case, there is a misunderstanding and not an attempt to smear or anything like that. I have yet to read any real rebuttal to the claim that Novell did not license according to the FSF's lgplv2. Novell's license was (presumably) what was linked at the top. It speaks for itself. The license is not what X or Y told someone who blogged about it and then had his sister tell someone else through a reply on a newsgroup which you read.
NotZed
2009-02-10 03:57:51
Consider network routers which come with Linux and busybox embedded into a PROM chip. That accounts for nearly every router on the market. Does Novell “consider” all of those products to be “non-LGPL use instances” too?
Nobody uses prom's anymore, they use flash which is rewritable. If they used true roms, and there was no way to replace the rom (e.g. physically), then yes, it would be a non-(l)gpl use. And regarding network routers, haven't you noticed all the lawsuits about them, and the fact the busybox guys ALWAYS win in the end?
I dare you to go onto the Ubuntu forums, and find more than a handful of users, out of the thousands there, who could modify any LiveCD, and still have a working LiveCD afterwards.
Well ubuntu users must be pretty thick in general then (not far off from my impressions of them to be honest). Anyway just because a given user can't write C code, doesn't mean writing C code is impossible, now does it? If you can't do it, you can ask or hire someone who can, or just learn how yourself - the knowledge is free, and the hardware required is cheap and readily available.
Section 6. of LGPL 2.0 says nothing about embedded or otherwise immutable systems, it refers only to licensing conditions which permit modification. IOW if the distributors of a LiveCD (or a router with embedded Linux) also provide the sources to that immutable medium, then they are not in violation of the (L)GPL.
The intent of section 6 is that you are still able to modify the lgpl part of the code in the distributed application. e.g. if an lgpl library is used, you can replace it with your modified copy *in the distributed executable in question*. This is clearly stated in the preamble. And yes, there is nothing about 'immutable systems', but a simple bit of reasoning can extend what the implications are in that case. You are the one adding different requirements for immutable systems, e.g. that merely distributing source in parallel is ok.
For the slow to think, it means that if the given executable is on a rom then you must provide instructions/a script to burn a new rom (and have a removable rom chip) or use a re-writeable memory and provide a mechanism to access it. Providing source that you can use in your own applications is not sufficient, you must be able to replace the library in the associated application.
It is absolutely clear from the license file that this is just a clarification of what the license actually MEANS - even just from the formatting used. People do this ALL THE TIME since legalese isn't all that straightforward as a rule (just look at how much trouble you're having - and the GPL's are simply the easiest to read licenses there are). It is not an 'additional clause', and there's nothing stopping them adding new clauses or modifying any others if they wanted to anyway (e.g. removing the 'any future version' statement). They have obviously placed it there to let embedded vendors know that if they want to use the code themselves, then although they normally wouldnt' be allowed to because of the LGPL requirements, they can re-license it directly from Novell. This is an absolutely standard GPL/LGPL/free licensing business model. e.g. ghostscript, berkeley db, etc.
No. Only the copyright owner can ever change the license, unless that original licensor specifies “GPL vX.X or (at your discretion) any later version” in the license terms he provides for that software.
Normally, but not if they use the LGPL. The license explicitly says you can change LGPL to *any* version of GPL - my `question' was rhetorical, and expressing surprise that I hadn't noticed that clause before.
Please, go read the GPL and LGPL licenses carefully, calmly, then spend a day to think about it. You're not doing yourself any favours by spouting such nonsense.
Dan O'Brian
2009-02-10 04:04:25
That makes this not so much a battle of 5-year-olds. My stance has legal backing. Roy's and Slated's does not.
NotZed
2009-02-10 04:05:00
> Short answer: the lgpl is copyrighted by the fsf I believe. It is not Novell’s license.
I hope this was an honest mistake. I was talking about the copyright on the code they own. And I was talking about whichever license they wish to use for that same code.
Dan O'Brian
2009-02-10 04:11:26
saulgoode
2009-02-10 07:35:50
The Busybox controversies have been about failure to provide the source code and AFAIK had nothing to do with the programmability of the devices.
I would agree that PROMs are not particularly prevalent nowadays, but they may still be a factor and I particularly disagree with the idea that putting GPLed code in ROM would be a violation of the license. The FSF has even recommended (covered during GPLv3 draft discussions) that such "ROMing" of code might be employed when, for example, device manufacturers must guarantee compliance with broadcast regulations.
saulgoode
2009-02-10 07:39:39
The Busybox controversies have been about failure to provide the source code and AFAIK had nothing to do with the programmability of the devices.
I would agree that PROMs are not particularly prevalent nowadays, but they may still be a factor and I particularly disagree with the idea that putting GPLed code in ROM would be a violation of the license. The FSF has even recommended (covered during GPLv3 draft discussions) that such “ROMing” of code might be employed when, for example, device manufacturers must guarantee compliance with broadcast regulations.
Roy Schestowitz
2009-02-10 09:44:07
saulgoode, I've fixed that markup.
NotZed
2009-02-10 12:05:52
Are you sure? To be honest I don't know the detail, so I defer to your knowledge. From what I can tell in the HAVA case (monsoon media), they do not allow custom firmware at all, and only distribute any (l)gpl source code (in rar of all formats), so at least in that case it appears so.
From first-hand experience with the FSF and a GPL firmware violation, they told me to ask the vendor for enough source/scripts or instructions to form a firmware image (it was not in a standard format), so that's what I thought it entailed. Maybe they've changed their stance since, or maybe the busybox guys were just interested in some cash, and the sflc not interested in opening hardware. But their own compliance guide states that build scripts are required - http://www.softwarefreedom.org/resources/2008/compliance-guide.html section 4.2.2.
As for the LGPL, Apart from section 6(a), there is also this part of 0:
As for the ROM issue, it appears I stand corrected - I guess if nobody can modify it, what's the point - but that would be commercial suicide in the current world of quick-to-market and patch-later devices. The GPL3 addresses this specifically at least.
The GPL3 also makes the installation issue quite clear as it talks about installation onto the physical device, even when signed, etc.
Dan O'Brian
2009-02-10 12:18:59
Slated and Roy are, as usual, wrong. The more you guys lie about this stuff, the less people are able to believe anything you guys say - I hope your intended goal is to destroy your own credibility, because that's all you are accomplishing with articles like this one.
Roy Schestowitz
2009-02-10 12:32:58
Keep spinning, Dan. You seem to be very proud of this.
Jose_X
2009-02-10 14:20:56
>> I hope this was an honest mistake. I was talking about the copyright on the code they own. And I was talking about whichever license they wish to use for that same code.
I'm not sure what you mean, but let me explain what I meant here and elsewhere (not quoted).
The LGPL is not a license that belongs to Novell but is one that Novell can use because the FSF gives permission; however, I don't know if the FSF allows people to use the license into their own license but then add and remove clauses from it. In any case, even if they allowed this, the actual license of the product would not be LGPL if there was any modification to those terms.
>> And regarding network routers, haven’t you noticed all the lawsuits about them, and the fact the busybox guys ALWAYS win in the end?
I don't know if they always win, but that need not be for the reasons you stated. It would help if you provided a link to an explanation of why they win. Source must be provided.
Tivoization http://en.wikipedia.org/wiki/Tivoization was an issue because I don't think L/GPLv2 required the product to be modifiable.
>> The intent of section 6 is that you are still able to modify the lgpl part of the code in the distributed application. e.g. if an lgpl library is used, you can replace it with your modified copy *in the distributed executable in question*. This is clearly stated in the preamble.
I searched for that phrase you emphasized above and did not find it, neither in the preamble nor in the license terms.
Software is something that you generally can run on many systems; hence, it makes some amount of sense not to force modifications of the software to be runnable on the actual hardware product of delivery.
NotZed, everything else you said in that comment is supposed to follow from this last statement I quoted, but I was not able to find that phrasing in the LGPLv2.
I think from a later reply you provided to sualgoode that perhaps you now agree that the gplv3 tried to solve the problem of requiring modifications to be easy to do as opposed to potentially virtually impossible. [Continuing in next section]
>> For the slow to think, it means that if the given executable is on a rom then you must provide instructions/a script to burn a new rom (and have a removable rom chip) or use a re-writeable memory and provide a mechanism to access it. Providing source that you can use in your own applications is not sufficient, you must be able to replace the library in the associated application.
I read over the preamble and various other bits. I disagree with you.
Read the Tivo link above. >> According to Eben Moglen, "the licence should prohibit technical means of evasion of its rules, with the same clarity that it prohibits legal evasion of its rules."
If you read the LGPL section 6, as Slated said, it states that the "terms" of the new proprietary license cannot prevent you from attempting to modify the work, but nothing in the license, I don't think, prevents you from building a product that is difficult to hack. [I read over section 2 some and didn't see anything about prohibiting technical means to try and frustrate modifications.]
Moglen I think would recognize that v2 of L/GPL do not force the vendor to provide a technical way to modify the work.. only to legally allow it should the user figure out a way for him/herself.
Jose_X
2009-02-10 14:23:42
What does it say? Do you have a link?
Did they change the license file? Will they include a copy of that website with the software?
If they want pure LGPLv2, then they should just state that clearly instead of the requirement about a commercial license when in fact such a license would not be needed.
I now am more confident that the interpretation given by Novell is incorrect for version 2 of the LGPL.
Please quote from the LGPLv2 license what you think justifies your, NotZed's, and Novell's interpretation because I haven't found such a section, and it appears Moglen also does not think it exists (that's how I read the Moglen quote on the Tivoization wikipedia page).
[Update: I see you quoted from the website.. I'll address that in upcoming comment.]
>> My stance has legal backing. Roy’s and Slated’s does not.
I don't see what new evidence you provided to make you think that you now have legal backing. The issue isn't over what the developers intended but over what they defined as the license of the product as per the license file in the tarball. If I have a copy of the product and its license file and this doesn't mention anything about any website what backing do I have?
If I were to download the product today, would there be a statement that that says to look at the website and quotes that text (the website might change)?
Finally, I do want to see a link, because as things stand their license is not vanilla LGPL best I can tell. It is some derivative of it and which has contradictions (see Slated's longer discussion on that).
[Update: I see you quoted from the website.. I'll address that in upcoming comment.]
>> And yet here you are getting schooled on the meaning of the LGPL. Clearly you never noticed that the LGPL states what NotZed has brought to our attention
I don't agree with NotZed's explanation as I so stated recently, so I don't think Slated has been schooled. In any case, these licenses aren't easy to understand, in their precise detail, by laypeople IMO. They might be much easier to read and mostly figure out relative to other licenses, however.
Jose_X
2009-02-10 14:24:33
Being legally allowed to create the working modified images and put them into the product is one thing. Being physically able to actually carry out those steps is another and something dealt with in the L/GPLv3 not v2.
Dan O'Brian
2009-02-10 14:33:09
There is no Mono problem either, that's all in your head - same as your "Moonlight isn't Free Software" illusion.
As far as codecs, seeing as how Moonlight most definitely *is* Free Software, you can build with FFMpeg if you don't like the Microsoft codecs... or you can contribute a patch to make it build with GStreamer or any other codec library of your choice.
Copyrights in the hands of a Microsoft ally? Puh-lease. They wrote the code for god's sake! Of *course* they own the copyright. But what difference does that make if they license it under the LGPL? It makes no difference at all. You own the copyrights to code you've written, but I don't see you giving that up. Hypocritical, don't you think?
The truth of the matter is that you guys are so desperate to prove foul when it comes to Mono that you continuously make up and try to spread lies to trick people who aren't willing to 5 minutes of research into believing your bullshit.
I don't spin, I point to the truth. Anyone can easily verify my rebuttals, no one can easily defend your tripe (because they aren't based on facts).
Dan O'Brian
2009-02-10 14:35:17
Moonlight is under the plain LGPL, they were just stating that if you wanted to use Moonlight in a proprietary device or in a proprietary application, that they offer a commercial license as well.
Dan O'Brian
2009-02-10 14:41:02
I agree that it takes a lawyer to fully understand the implications of legal documents, including the [L]GPL licenses.
My point was that Slated attacked Miguel on COLA a few weeks ago when Miguel stated that he had not had a chance to fully understand the LGPLv3 (which is why he didn't license Moonlight under LGPLv3). Slated replied that it only takes a few minutes to read over the LGPL and fully understand it.
Clearly he just ate his own words ;-)
Jose_X
2009-02-10 16:53:28
Dan, that is a fine intention, but the way it was written says embeds require commercial licenses. Best I can tell, that is conflicting with the LGPLv2.
From the "Moonlight developers" as quoted here on BN:
>> Embedded systems are essentially a statically linked executable...
I disagree. I can see why they might say that, but the embed might work just like a PC with dynamic linking, except for the fact you may find it terribly difficult to change the bits that correspond to the LGPL software, in the embed case.
I don't know if the context around the use and meaning of static/dynamic linking includes embedded. See if you people find anything about that here http://en.wikipedia.org/wiki/Library_(computing)#Dynamic_linking .
See section 6 of lgpl "work that uses the Library" vs. the a derivative as defined by copyright law (see section 0 definition of "Library").
I don't think these are 100% precise notions. There can be room for disagreement.
>> Clearly you can’t replace the moonlight in that system from source (unless you have some wonderful devkit - but in that case, you aren’t everyone.) So the additional license terms are available from novell for these instances.
See the earlier remarks I made concerning legally being allowed to do something vs actually finding a physical way of achieving it. Version 2 of the L/GPL does not require that a physical way be made easily accessable.
Moglen is quoted on that tivoization wikipage. Take a look.
As Slater mentioned, why didn't they just use the LGPLv3?
But we still haven't gotten to the root of the problem...
>> LiveCD’s are not considered embedded systems, even by the FSF, for reasons that are pretty easy to see. It *is* possible for anyone to take a livecd, replace moonlight, and build another livecd. It doesn’t have to be a comfortable process, or even necessarily easy. It just has to be technically possible.
No problems with this except for the last sentence.
>> I don’t understand why this is being brought up in just the moonlight case. Clearly it’s okay enough for gcc and rest of the GNU toolchain. Suddenly it’s not ok for moonlight? I don’t get it.
I hope the moonlight devs can provide some sort of evidence to back this comment. In any case, I found the case to be otherwise...
I downloaded gcc-4.3.0 and extracted the COPYING file. Guess what I found? It was the text of the license "GNU GENERAL PUBLIC LICENSE Version 2, June 1991", nothing more, nothing less. [Should I have looked in any other place for the license?]
Guess what I didn't find? All the discussion about commercial licenses being needed for embeds. Either that is Novel's interpretation of what the FSF's LGPL license says or it is Novell actually providing a license different from the LGPL (but leveraging the LGPL).
If the embed statement is consistent with the LGPL, then all appears to be alright, and Novell's comment is superfluous.
I don't think it is consistent with the LGPL though, which would mean that Novell is providing a new license that is not LGPL and is also not a free license because of the extra use restriction. And because of the inconsistency, it's not clear what the actual license terms are.
The fix to this problem (if Novell intends for LGPLv2) can be as simple as doing similar to what gcc does, have a COPYING file which is a copy of the LGPLv2. [Is there a different file I should be looking at?], and don't add anything else to that license file.
Remember IANAL, so wrt legal opinions, if it appears I said X is Y, I probably meant "I think X is Y".
saulgoode
2009-02-10 17:05:22
From the Moonlight developers:
The LGPL permits distribution of object code linked into other, non-LGPL (or GPL) object code, under one condition only: The person who downloads the object code from *you* must be able to edit the source and replace the LGPL’ed portions with their own version.
This is entirely incorrect. Such is not a condition of the LGPL and certainly not the only condition.
If the Mono/Moonlight project wishes to "require that the author grants Novell the right to relicense his/her contribution under other licensing terms", fine; but don't blame it on some mythical scenario where distributors "are unable to fulfill the obligations of the GNU LGPL". Such inability only exists owing to unwillingness, not anything inherent to the terms of LGPL.
Jose_X
2009-02-10 17:09:40
By getting into more specifics over what is and is not covered under the LGPLv2 (according to their interpretation), they risk contradicting what the LGPLv2 already says.
Jose_X
2009-02-10 17:12:28
Basically that is it, but that they must have a legal right to do this.. not a technical means.
[See also the Moglen quote from earlier comment.]
Novell should just let the LGPLv2 license do the talking. It's complete. Why risk contradicting it?
saulgoode
2009-02-10 17:16:33
I do not believe that Novell is actually attempting to add further restrictions to the LGPL, but recognize that such might be inferred from their wording in the FAQ.
I do think that they are misleading people as to the reasoning for the alleged "copyright assignment" requirement being placed on contributions.
Jose_X
2009-02-10 18:46:33
I looked at http://anonsvn.mono-project.com/viewvc/trunk/moon/LICENSE?view=markup which was a link at the very top.
Looking at that again, I think the wording is confusing. If Novell says that you require a commercial license under X condition... If Novell says that the license is LGPLv2.. if lgplv2 is inconsistent with the requirement that lgplv2 is insufficient for embed use (ie, lgplv2 is sufficient.. unlike what Novell states), then did Novell actually license as lgplv2?
I think Novell should clarify. My guess is that Novell did license as lgplv2, but that they are confused in stating that X use case is not allowed by lgplv2.
As an aside, I want to repeat that I don't think people should support the dotnet ecosystem or build foss apps on it, regardless of the licensing. Links as to reasons for this view were given in my first set of replies near the top of this page.
>> I do not believe that Novell is actually attempting to add further restrictions to the LGPL
Yeah, that appears to be the case as I read this again.
Dan, if you are reading, perhaps Novell should clarify, but I doubt they will. As is, my best guess is that lgplv2 is the license and as to whether that gives the user sufficient rights to do X is up to the user to figure out regardless of the other Novell comments on that page.
It is tough to have inconsistencies (and that is a matter of opinion). A court may not rule that the lgplv2 was granted, even though it's the simplest way out of the confusion, I think.
Dan O'Brian
2009-02-11 00:37:04
You'd be wrong. LGPL does not allow statically linking libraries into proprietary software. Software running on an embedded device that does not have a means of allowing the user to change the software cannot satisfy the terms of the LGPL.
Dan O'Brian
2009-02-11 00:42:54
Essentially you guys are upset because you have to pay Novell in order to take away your user's freedoms. For shame.
Jose_X
2009-02-11 02:07:57
Dan O'Brian
2009-02-11 02:26:04
I did not equate embedding with statically linking.
I specifically said embedded devices where it is not possible for the user to modify/update the moonlight code.
Jose_X
2009-02-11 02:27:00
Misrepresenting the LGPL (v.2) is not a very clever thing to do. Short-term this may sound fine as you said, but why breed long-term confusion? There is a license that comes closer to what Novell appears to want; it's v.3. They can be straight with everyone and use that. If people want the benefits Novell appears to be pushing as a business model, people should use v.3 and not v.2 since v.2 does not achieve those things as Novell appears to be misrepresenting.
[IANAL]
Jose_X
2009-02-11 02:33:49
In that case, you other comment sounds odd to me, but here you cleared up what you meant.
>> I specifically said embedded devices where it is not possible for the user to modify/update the moonlight code.
However, you must have skipped many of the comments above if you still think that the LGPL v2 requires that the distributor provide you with easy access to modifying the product.
Consider going back and reading some of the comments you missed.
Slated
2009-02-12 17:55:09
Just to reiterate ... this is the problem:
And this is what the relevant part of the LGPLv2.0 actually states:
IOW LGPLv2.0 is referring to what users are permitted to do with the software, whereas Moonlight's non-Free clause is referring to what users are able to do with the hardware. Novell are then falsely claiming that this clause is an example of non-LGPL use, but LGPL2.0 makes no mention of hardware whatsoever, and hardware limitations were never part of the mandate for that license.
Indeed, even (L)GPLv3 does not discriminate against embedded/immutable systems, since its purpose is to safeguard against restrictions deliberately implemented to prevent modified versions of the software from functioning (properly or at all). This is an anti-DRM measure, and makes no case against systems which are inherently immutable (i.e. Read Only).
(L)GPLv3.0 does not mandate that the hardware must be mutable, it only mandates that if it is, then those modifications must not be prevented from functioning using software restrictions. This has nothing to do with hardware.
Think about it ... if the (L)GPL was designed to preclude embedded systems, then the FSF would be deliberately cutting off Free Software from what is currently its biggest market. This would make absolutely no sense whatsoever. The fact that (L)GPL software is currently used in embedded systems (e.g. Linux kernel, BusyBox, etc.) proves this point conclusively.
No version of the GPL or LGPL precludes use on embedded systems. Novell are spreading FUD, and perverting the meaning of the (L)GPL by making this false claim. The anti-embedded clause in Moonlight's license contradicts LGPLv2.0, and thus Moonlight is not Free Software.
Miguel de Icaza, or any other Novell employee, can post anything they like to mailing lists, but until that clause is removed from the actual license, Moonlight will not be Free.
Of course, that's only the beginning of Moonlight's problems.
Roy Schestowitz
2009-02-12 17:59:39
Jose_X
2009-02-17 18:57:02
Since some of the comments I posted were rejected apparently. Let me post some of them here (those that are currently on the website and one that was rejected) for the record, so to speak.
I note that the rejected posts came after I had already stated most of what I wanted to say. It's possible the website has something like a quota on replies from the same source. I do repeat myself some, but part of the reason is because it seems some people aren't reading what I wrote (not a prob.. if I am allowed to repeat).
********** That's really nice "Miguel". Why don't you start providing a list of problems.
Boycottnovell has some problems, but not nearly as many as Microsoft advocates tend to think.
In the meantime, I wrote this not long ago: http://www.linuxtoday.com/news_story.php3?ltsn=2009-02-11-019-35-NW-OO-0001 . The second half of that comment is more specific to Novell.
[Make sure this isn't missed, at least not if you care about automatic patent threats or about not supporting monopolies to the detriment of developers and users everywhere: http://www.linuxtoday.com/news_story.php3?ltsn=2009-02-09-022-35-OS-MS-LL-0000 ]
********** The link I most wanted to give was this one http://boycottnovell.com/2009/02/04/the-api-trap-part-1/ (you can reach it from the other links above if you follow the links embedded in those comments).
[Miguel de Icaza] >> Distribution of Moonlight on a LiveCD is perfectly fine, this was discussed on comp.os.linux.advocacy.
If you would care to visit the Boycottnovell.com site, read, comment, and read replies, you might be convinced (in this particular case) that Novell tried to stretch the meaning of the LGPLv2 and in the process created a confusing situation by stating an opinion that something that is covered under the LGPL is not.
http://boycottnovell.com/2009/02/09/moonlight-is-not-free/#comment-59572
Also from that thread:
>> If you read the LGPL section 6, as Slated said, it states that the “terms” of the new proprietary license cannot prevent you from attempting to modify the work, but nothing in the license, I don’t think, prevents you from building a product that is difficult to hack. [I read over section 2 some and didn’t see anything about prohibiting technical means to try and frustrate modifications.]
>> Moglen I think would recognize that v2 of L/GPL do not force the vendor to provide a technical way to modify the work.. only to legally allow it should the user figure out a way for him/herself.
>> http://en.wikipedia.org/wiki/Tivoization
The mono devs apparently put something up that also has some problems http://boycottnovell.com/2009/02/09/moonlight-is-not-free/#comment-59572 .
Feel free to join the conversation. I don't believe you participated in the discussion.
And I invite and *strongly* urge you to comment on the link at the top of this response (the link about api trap), repeated here for clarity: http://boycottnovell.com/2009/02/04/the-api-trap-part-1/
********** >> but I'm still betting that this is a step forward for Linux compatibility with a lot of online content.
What do you mean by "a lot"?
What sorts of percentages are we talking about?
Does this webpage use silverlight? Does it use flash? Does it use graphic images? Does it embed videos?
>> There are two benefits for Linux users here. One is that a whole lot of video and audio content on the web is in Windows Media Video
If I am not mistaken that problem is already solved.
>> tools for developers to write Rich Internet Applications.
I think that problem is solved as well.
[Jose_X] >> http://boycottnovell.com/2009/02/04/the-api-trap-part-1/
Please also keep in mind http://boycottnovell.com/2008/11/25/jose-on-mono/ .
********** toshok, you understand that groups like Tivo and Linus (?) and many others would probably consider that LGPL gives them the rights to embed and distribute all they want.
They might reason as such: the LGPLv2 gives full distribution rights (?) so long as certain conditions are met, and these conditions don't specifically include the requirement to make modifications physically possible or easy.
Maybe a court would side with Novell and not Tivo; however, Novell's interpretation does not seem to be supported by the LGPLv2 text; it appears to be a contradiction, making it a bit unclear what the actual license of moonlight is: LGPLv2 or some bifurcation of that license with Novell's new requirement?
>> We're the copyright holders, we can apply whatever license terms we *want*.
That is correct. The allegation was in part that Novell had not licensed as LGPLv2. I haven't seen anyone challenge their ability to pick their license. The confusion is in not knowing what license Novell actually did pick.
Novell can remove the confusion by picking LGPLv3, I think, or by clearly writing out a new license (see http://www.fsf.org/licensing/licenses/gpl-faq.html#ModifyGPL ), or by sticking with LGPLv2 but putting their interpretation and any other advice elsewhere from the project license file or clearly marked as "nonnormative".
Moonlight is meant to be distributed and used. This way patent infringement kicks in. This way Microsoft's huge investments can be leveraged by them and are not wasted. Developers, developers, developers, developers. Let's all be good chaps and chip in to help preserve the monopoly lock-ins.
Slated
2009-02-25 01:06:13
If certain people are so eager to be enslaved by restrictive licensing, like Moonlight's proprietary license for example, then why don't those people just go and use Microsoft's Slaveware like Windows full time, and stop poisoning Free Software with their proprietary/encumbered toxin?
As I've said before (elsewhere), I use GNU/Linux to get away from bloated, insecure, unstable, proprietary, encumbered, Windows Slopware, I didn't expect it to follow me into the sanctity of the Free Software community, courtesy of Microsoft cheerleaders like de Icaza.
If de Icaza and friends are so in love with Microsoft, then why don't they drop the pretence, go work for Microsoft full time (assuming they aren't already), use Windows full time (likewise), and leave the Free Software community alone.
I simply don't understand this agenda that certain GNU/Linux developers have of crapping all over their own house.