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.

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.

Just to reiterate … this is the problem:

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 your product (Section 6 and 7) [of the LPGLv2.0]

And this is what the relevant part of the LGPLv2.0 actually states:

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.

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).

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

(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.

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.

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]

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.

Essentially you guys are upset because you have to pay Novell in order to take away your user’s freedoms. For shame.

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.

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.

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.

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.

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?

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.

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.

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”.

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.

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

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.

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).

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.