Comments and questions about MPL 2 alpha 1
Benoit Jacob
I have a few questions and comments about the MPL. Full disclosure: I am looking at it not only with my Mozilla hat but also from my perspective as a developer of an independent free software project (eigen.tuxfamily.org), currently LGPL-licensed and potentially interested in a better weak-copyleft license. However I believe that gaining traction beyond the Mozilla community is important for the MPL, even from Mozilla's perspective.
I'll divide this email in 2 parts: comments/questions about the MPL 2 alpha 1, and a hopefully useful explanation of my perspective.
===== Questions/comments about MPL v2 alpha 1 =====
1. What does the phrase 'file-level copyleft' mean (as used in your FAQ) and how is that different from the kind of copyleft offered by the LGPL v3?
2. If I have MPL v2-licensed code, and I now want to write documentation under Creative Commons license, is it legal for me to:
- copy code snippets into the documentation?
- generate some documentation automatically from the code with a tool like e.g. Doxygen?
I realize that there are many Creative Commons licenses, so let me ask more specifically about CC-BY and CC-BY-SA. Is there a reasonable legal way to distribute such documentation under a very-liberal license like CC-BY, saying that short enough code snippets needn't be protected by the copyleft, or should I just forget about CC-BY and focus on CC-BY-SA?
See this very interesting article on a related topic (see "Documentation licensing"):
http://lwn.net/Articles/394219/
Interesting quote: "the real problem is that we as a community lack a copyleft license that works well for both code and text."
3. In section 9, the MPL v2 is still saying stuff about legal disputes being resolved in California. Do you plan to keep that in the final version of the MPL v2? I know I asked a similar question at the Summit and the answer was (IIUC) that you were dropping that, but it is still written in the current alpha, so I feel the need to ask.
===== My perspective =====
In the hope that it may be useful to share, here's my perspective as an independent free software developer (not wearing my Mozilla hat for now).
I start a free software project. I have to pick a license for it. I realize that what I want is called 'weak copyleft' i.e. I want to get protection against proprietary forks, while still allowing use by proprietary software.
So I look at existing weak-copyleft licenses and I realize that there are essentially just two of them: the LGPL and the MPL. Since the MPL v1 seems very Mozilla specific (e.g. the clause about California) I go for the LGPL. All I wanted was the weak copyleft, but the LGPL also comes with a lot of complicated clauses, which are imposed onto my users without me really wanting it (I can elaborate if you want).
At some point my project flourishes and starts gaining wider adoption, including among proprietary software companies. Their friendly developers join my mailing list and start pointing out all the little inconveniences that the LGPL incurs for them, and how it would be more convenient for them if my project were BSD-licensed. Other companies just have a policy to stay away from LGPL-licensed software because of licensing complexity.
Also, at some point we need to address a lot of little licensing questions, e.g. choosing a license for the documentation (see above). The LGPL doesn't make any of that easy for non-lawyers to understand, and the FSF licensing engineers tend to take a long time to reply to e-mail.
So here's the problem: all I wanted was the weak copyleft, and the LGPL gave me that but it also comes with a truckload of complexity and is hard to read.
This is the reason why BSD-style licenses are so popular at the moment (and yes, they are, I can elaborate). I don't think that people are really that happy about allowing third parties to do proprietary forks of their free software projects. They just choose BSD-style licenses because they are short, simple, easy to read, without unexpected side effects (e.g. documentation licensing). If there existed a simple weak-copyleft license, it would be hugely popular, but the LGPL isn't that.
I hope that the MPL v2 will be that. I can already say that it feels much more readable and simple than the LGPL v3.
===== Coming back to Mozilla ======
Actually the above discussion is not disconnected from Mozilla's interests. Rationale: Mozilla's best interest is that there exists a large pool of free software projects (and people) with which it can share code in both directions. But in 2010, the trend is that many large corporations are embracing free software to some extent and favor BSD-style licenses. For example, the main companies behind WebKit. Independent developers are aligning to that because they want to get corporations to use their software (prestige, etc). Now the reason these companies favor BSD licenses is not necessarily because they have plans of making proprietary forks, it can simply be because of the little annoyances and the perceived complexity of the GNU licenses. If BSD-style licenses become prevalent (the dream scenario for these corporations), Mozilla could find itself isolated in the resulting free software landscape. The sad part is that, again, people aren't all that crazy about BSD licenses, they just tend to adopt them for lack of simple, reasonable copyleft licenses. The MPL v2 could be that!
Cheers,
Benoit
Mitchell Baker
Thanks for the message, and the rationae you included; it's very
helpful. Both Luis and I are out of the office, vacation for him;
partly vacation for me -- until next week. We'll turn to your message
next week, but unlikely in the next couple of days. Hope that timing is
OK.
mitchell
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update
Benoit Jacob
Happy vacation (or partial vacation) to both of you.
Benoit
Benjamin Smedberg
IANAL. Answers here are based on my personal understanding.
> ===== Questions/comments about MPL v2 alpha 1 =====
>
> 1. What does the phrase 'file-level copyleft' mean (as used in your FAQ)
> and how is that different from the kind of copyleft offered by the LGPL
> v3?
Under the MPL, if you make changes to a particular file, you are required to
publish those changes. If you add a *new* file to the build, that file may
be under any license (or proprietary with no license at all).
Under the LGPL, any file which is *linked* to the library in question must
be licensed under the LGPL.
> I start a free software project. I have to pick a license for it. I
> realize that what I want is called 'weak copyleft' i.e. I want to get
> protection against proprietary forks, while still allowing use by
> proprietary software.
The LGPL is pretty specific to binary libraries. It applies copyleft to any
modification of your library. If you use the MPL, somebody could combine
your library with proprietary code, and would only have to publish the
changes they made to your original code.
The whole question of whether and how the LGPL (and GPL for that matter)
capplies to scripting libraries or other non-sharedlibrary works isn't
clear: see the recent brouhaha about Wordpress themes.
> This is the reason why BSD-style licenses are so popular at the moment
> (and yes, they are, I can elaborate). I don't think that people are
> really that happy about allowing third parties to do proprietary forks of
> their free software projects. They just choose BSD-style licenses because
> they are short, simple, easy to read, without unexpected side effects
> (e.g. documentation licensing). If there existed a simple weak-copyleft
> license, it would be hugely popular, but the LGPL isn't that.
I think you are projecting your feelings onto others. I personally license
all the code I can under BSD-style licenses, because I think that is the
most-free way of doing things. The power in free software is overwhelmingly
in its community, I think, not in the license.
Unfortunately Mozilla cannot practically relicense all of its code to a
BSD-style license, so we are 'stuck' with our own unique license.
--BDS
Alexis Richardson
popular, but the LGPL isn't that."
+1
On Wed, Jul 28, 2010 at 7:00 PM, Benoit Jacob <bja...@mozilla.com> wrote:
> Dear MPL specialists,
>
> I have a few questions and comments about the MPL. Full disclosure: I am looking at it not only with my Mozilla hat but also from my perspective as a developer of an independent free software project (eigen.tuxfamily.org), currently LGPL-licensed and potentially interested in a better weak-copyleft license. However I believe that gaining traction beyond the Mozilla community is important for the MPL, even from Mozilla's perspective.
>
> I'll divide this email in 2 parts: comments/questions about the MPL 2 alpha 1, and a hopefully useful explanation of my perspective.
>
> ===== Questions/comments about MPL v2 alpha 1 =====
>
> 1. What does the phrase 'file-level copyleft' mean (as used in your FAQ) and how is that different from the kind of copyleft offered by the LGPL v3?
>
> 2. If I have MPL v2-licensed code, and I now want to write documentation under Creative Commons license, is it legal for me to:
> - copy code snippets into the documentation?
> - generate some documentation automatically from the code with a tool like e.g. Doxygen?
> I realize that there are many Creative Commons licenses, so let me ask more specifically about CC-BY and CC-BY-SA. Is there a reasonable legal way to distribute such documentation under a very-liberal license like CC-BY, saying that short enough code snippets needn't be protected by the copyleft, or should I just forget about CC-BY and focus on CC-BY-SA?
>
> See this very interesting article on a related topic (see "Documentation licensing"):
> http://lwn.net/Articles/394219/
> Interesting quote: "the real problem is that we as a community lack a copyleft license that works well for both code and text."
>
> 3. In section 9, the MPL v2 is still saying stuff about legal disputes being resolved in California. Do you plan to keep that in the final version of the MPL v2? I know I asked a similar question at the Summit and the answer was (IIUC) that you were dropping that, but it is still written in the current alpha, so I feel the need to ask.
>
> ===== My perspective =====
>
> In the hope that it may be useful to share, here's my perspective as an independent free software developer (not wearing my Mozilla hat for now).
>
> I start a free software project. I have to pick a license for it. I realize that what I want is called 'weak copyleft' i.e. I want to get protection against proprietary forks, while still allowing use by proprietary software.
>
> So I look at existing weak-copyleft licenses and I realize that there are essentially just two of them: the LGPL and the MPL. Since the MPL v1 seems very Mozilla specific (e.g. the clause about California) I go for the LGPL. All I wanted was the weak copyleft, but the LGPL also comes with a lot of complicated clauses, which are imposed onto my users without me really wanting it (I can elaborate if you want).
>
> At some point my project flourishes and starts gaining wider adoption, including among proprietary software companies. Their friendly developers join my mailing list and start pointing out all the little inconveniences that the LGPL incurs for them, and how it would be more convenient for them if my project were BSD-licensed. Other companies just have a policy to stay away from LGPL-licensed software because of licensing complexity.
>
> Also, at some point we need to address a lot of little licensing questions, e.g. choosing a license for the documentation (see above). The LGPL doesn't make any of that easy for non-lawyers to understand, and the FSF licensing engineers tend to take a long time to reply to e-mail.
>
> So here's the problem: all I wanted was the weak copyleft, and the LGPL gave me that but it also comes with a truckload of complexity and is hard to read.
>
> This is the reason why BSD-style licenses are so popular at the moment (and yes, they are, I can elaborate). I don't think that people are really that happy about allowing third parties to do proprietary forks of their free software projects. They just choose BSD-style licenses because they are short, simple, easy to read, without unexpected side effects (e.g. documentation licensing). If there existed a simple weak-copyleft license, it would be hugely popular, but the LGPL isn't that.
>
Benoit Jacob
> On 7/28/10 2:00 PM, Benoit Jacob wrote:
>
> IANAL. Answers here are based on my personal understanding.
>
> > ===== Questions/comments about MPL v2 alpha 1 =====
> >
> > 1. What does the phrase 'file-level copyleft' mean (as used in your
> > FAQ)
> > and how is that different from the kind of copyleft offered by the
> > LGPL
> > v3?
>
> Under the MPL, if you make changes to a particular file, you are
> required to
> publish those changes. If you add a *new* file to the build, that file
> may
> be under any license (or proprietary with no license at all).
I see, thanks for the explanation.
>
> Under the LGPL, any file which is *linked* to the library in question
> must
> be licensed under the LGPL.
I see (assuming here you mean 'linked' in a static sense, e.g. linked to the other object files to produce the library in question).
>
> > I start a free software project. I have to pick a license for it. I
> > realize that what I want is called 'weak copyleft' i.e. I want to
> > get
> > protection against proprietary forks, while still allowing use by
> > proprietary software.
>
> The LGPL is pretty specific to binary libraries. It applies copyleft
> to any
> modification of your library. If you use the MPL, somebody could
> combine
> your library with proprietary code, and would only have to publish the
> changes they made to your original code.
>
> The whole question of whether and how the LGPL (and GPL for that
> matter)
> capplies to scripting libraries or other non-sharedlibrary works isn't
> clear: see the recent brouhaha about Wordpress themes.
Just FYI, this has improved a lot in the LGPL v3 compared the the LGPL v2.1:
- the phrasing doesn't rely on the concept of 'linking' anymore, except in Section 4;
- the new Section 3 addresses the case of code included from headers.
However I certainly believe that Wordpress themes are still an annoyance.
>
> > This is the reason why BSD-style licenses are so popular at the
> > moment
> > (and yes, they are, I can elaborate). I don't think that people are
> > really that happy about allowing third parties to do proprietary
> > forks of
> > their free software projects. They just choose BSD-style licenses
> > because
> > they are short, simple, easy to read, without unexpected side
> > effects
> > (e.g. documentation licensing). If there existed a simple
> > weak-copyleft
> > license, it would be hugely popular, but the LGPL isn't that.
>
> I think you are projecting your feelings onto others.
My phrasing was overly general, I admit. While I certainly have seen many cases where what I say above happened, I understand that not everybody feels that way.
Cheers,
Benoit
Alexander Terekhov
Benoit Jacob wrote:
[... 'file-level copyleft' ... 'weak copyleft' ... free software ...]
<chuckles>
"Along those lines FSF created a special terminology (often called
"GNU-speak") that redefines the meaning of existing words like "free
software" (FSF provides a definition of the term), and introduces a new
word "copyleft" (also with the definition). Some pages demonstrate a
real artistry in playing with the term "copyleft": "real copyleft"
(GPL), "strong copyleft" (GPL), "not a strong copyleft" (whatever)
"non-copyleft" (a bad thing) and such pearls as "simple, permissive
non-copyleft free software license" or "a free software license,
partially copyleft but not really" [FSF1999b]. "
Source:
http://www.softpanorama.org/Copyright/License_classification/social_roots_of_GPL.shtml
regards,
alexander.
Luis Villa
> "If there existed a simple weak-copyleft license, it would be hugely
> popular, but the LGPL isn't that."
>
A number of people have made this observation to me throughout this
process, so you two aren't alone. That said, I'm not sure it changes our
strategy much: we're trying to produce the best license we can, and if
it replaces the LGPL as a standard weak-copyleft license because people
really think it is better, great; if not, I think we'd be satisfied with
that too, as long as it is helpful to the projects that are using it.
Luis (reading and responding to the rest of the email soon)
> On Wed, Jul 28, 2010 at 7:00 PM, Benoit Jacob<bja...@mozilla.com> wrote:
>> Dear MPL specialists,
>>
>> I have a few questions and comments about the MPL. Full disclosure: I am looking at it not only with my Mozilla hat but also from my perspective as a developer of an independent free software project (eigen.tuxfamily.org), currently LGPL-licensed and potentially interested in a better weak-copyleft license. However I believe that gaining traction beyond the Mozilla community is important for the MPL, even from Mozilla's perspective.
>>
>> I'll divide this email in 2 parts: comments/questions about the MPL 2 alpha 1, and a hopefully useful explanation of my perspective.
>>
>> ===== Questions/comments about MPL v2 alpha 1 =====
>>
>> 1. What does the phrase 'file-level copyleft' mean (as used in your FAQ) and how is that different from the kind of copyleft offered by the LGPL v3?
>>
>> 2. If I have MPL v2-licensed code, and I now want to write documentation under Creative Commons license, is it legal for me to:
>> - copy code snippets into the documentation?
>> - generate some documentation automatically from the code with a tool like e.g. Doxygen?
>> I realize that there are many Creative Commons licenses, so let me ask more specifically about CC-BY and CC-BY-SA. Is there a reasonable legal way to distribute such documentation under a very-liberal license like CC-BY, saying that short enough code snippets needn't be protected by the copyleft, or should I just forget about CC-BY and focus on CC-BY-SA?
>>
>> See this very interesting article on a related topic (see "Documentation licensing"):
>> http://lwn.net/Articles/394219/
>> Interesting quote: "the real problem is that we as a community lack a copyleft license that works well for both code and text."
>>
>> 3. In section 9, the MPL v2 is still saying stuff about legal disputes being resolved in California. Do you plan to keep that in the final version of the MPL v2? I know I asked a similar question at the Summit and the answer was (IIUC) that you were dropping that, but it is still written in the current alpha, so I feel the need to ask.
>>
>> ===== My perspective =====
>>
>> In the hope that it may be useful to share, here's my perspective as an independent free software developer (not wearing my Mozilla hat for now).
>>
>> I start a free software project. I have to pick a license for it. I realize that what I want is called 'weak copyleft' i.e. I want to get protection against proprietary forks, while still allowing use by proprietary software.
>>
>> So I look at existing weak-copyleft licenses and I realize that there are essentially just two of them: the LGPL and the MPL. Since the MPL v1 seems very Mozilla specific (e.g. the clause about California) I go for the LGPL. All I wanted was the weak copyleft, but the LGPL also comes with a lot of complicated clauses, which are imposed onto my users without me really wanting it (I can elaborate if you want).
>>
>> At some point my project flourishes and starts gaining wider adoption, including among proprietary software companies. Their friendly developers join my mailing list and start pointing out all the little inconveniences that the LGPL incurs for them, and how it would be more convenient for them if my project were BSD-licensed. Other companies just have a policy to stay away from LGPL-licensed software because of licensing complexity.
>>
>> Also, at some point we need to address a lot of little licensing questions, e.g. choosing a license for the documentation (see above). The LGPL doesn't make any of that easy for non-lawyers to understand, and the FSF licensing engineers tend to take a long time to reply to e-mail.
>>
>> So here's the problem: all I wanted was the weak copyleft, and the LGPL gave me that but it also comes with a truckload of complexity and is hard to read.
>>
>> This is the reason why BSD-style licenses are so popular at the moment (and yes, they are, I can elaborate). I don't think that people are really that happy about allowing third parties to do proprietary forks of their free software projects. They just choose BSD-style licenses because they are short, simple, easy to read, without unexpected side effects (e.g. documentation licensing). If there existed a simple weak-copyleft license, it would be hugely popular, but the LGPL isn't that.
>>
>> I hope that the MPL v2 will be that. I can already say that it feels much more readable and simple than the LGPL v3.
>>
>> ===== Coming back to Mozilla ======
>>
>> Actually the above discussion is not disconnected from Mozilla's interests. Rationale: Mozilla's best interest is that there exists a large pool of free software projects (and people) with which it can share code in both directions. But in 2010, the trend is that many large corporations are embracing free software to some extent and favor BSD-style licenses. For example, the main companies behind WebKit. Independent developers are aligning to that because they want to get corporations to use their software (prestige, etc). Now the reason these companies favor BSD licenses is not necessarily because they have plans of making proprietary forks, it can simply be because of the little annoyances and the perceived complexity of the GNU licenses. If BSD-style licenses become prevalent (the dream scenario for these corporations), Mozilla could find itself isolated in the resulting free software landscape. The sad part is that, again, people aren't all that crazy about BSD licenses,
>> they just tend to adopt them for lack of simple, reasonable copyleft licenses. The MPL v2 could be that!
>>
>> Cheers,
>> Benoit
>> _______________________________________________
>> governance-mpl-update mailing list
>> governance...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/governance-mpl-update
>>
> _______________________________________________
> governance-mpl-update mailing list
> governance...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance-mpl-update
--
Luis Villa, Mozilla Legal
work email: lvi...@mozilla.com (preferred)
work phone: 650-903-0800 x327
personal: http://tieguy.org/about/
Luis Villa
> Dear MPL specialists,
>
> I have a few questions and comments about the MPL. Full disclosure: I am looking at it not only with my Mozilla hat but also from my perspective as a developer of an independent free software project (eigen.tuxfamily.org), currently LGPL-licensed and potentially interested in a better weak-copyleft license. However I believe that gaining traction beyond the Mozilla community is important for the MPL, even from Mozilla's perspective.
> I'll divide this email in 2 parts: comments/questions about the MPL 2 alpha 1, and a hopefully useful explanation of my perspective.
>
> ===== Questions/comments about MPL v2 alpha 1 =====
>
> 1. What does the phrase 'file-level copyleft' mean (as used in your FAQ) and how is that different from the kind of copyleft offered by the LGPL v3?
> 2. If I have MPL v2-licensed code, and I now want to write documentation under Creative Commons license, is it legal for me to:
> - copy code snippets into the documentation?
> - generate some documentation automatically from the code with a tool like e.g. Doxygen?
> I realize that there are many Creative Commons licenses, so let me ask more specifically about CC-BY and CC-BY-SA. Is there a reasonable legal way to distribute such documentation under a very-liberal license like CC-BY, saying that short enough code snippets needn't be protected by the copyleft, or should I just forget about CC-BY and focus on CC-BY-SA?
copyleft licenses, including MPL. If you can keep the file separate,
then MPL would not be a problem (unlike GPL), but it sounds like you
want to mix within a single file, in which case you'd have to look at
alternatives like the one you suggested (deciding that short snippets
are not copyrighted.)
That said, we'll look at what we can do about minimizing this problem;
we've talked with the CC people and one of them was in our office recently.
> See this very interesting article on a related topic (see "Documentation licensing"):
> http://lwn.net/Articles/394219/
> Interesting quote: "the real problem is that we as a community lack a copyleft license that works well for both code and text."
Mozilla resolves that problem by just using MPL for documentation. If
you have specific reasons or features that prevent you from using MPL
for documentation, let us know and we can look at resolving it.
> 3. In section 9, the MPL v2 is still saying stuff about legal disputes being resolved in California. Do you plan to keep that in the final version of the MPL v2? I know I asked a similar question at the Summit and the answer was (IIUC) that you were dropping that, but it is still written in the current alpha, so I feel the need to ask.
I believe that I mentioned in the rationale document that we're still
planning on resolving this issue; the only question is how.
Unfortunately, we haven't figured that out yet, so the language was left
in. Sorry if leaving it in made that unclear.
> ===== My perspective =====
...
> So here's the problem: all I wanted was the weak copyleft, and the LGPL gave me that but it also comes with a truckload of complexity and is hard to read.
>
> This is the reason why BSD-style licenses are so popular at the moment (and yes, they are, I can elaborate). I don't think that people are really that happy about allowing third parties to do proprietary forks of their free software projects. They just choose BSD-style licenses because they are short, simple, easy to read, without unexpected side effects (e.g. documentation licensing). If there existed a simple weak-copyleft license, it would be hugely popular, but the LGPL isn't that.
>
> I hope that the MPL v2 will be that. I can already say that it feels much more readable and simple than the LGPL v3.
Terrific to hear. We certainly hope people will like it and adopt it.
For what it is worth, we already can and do use BSD code; in fact, we've
been able to borrow quite a bit of BSD'd code from Chrome/WebKit. But I
agree that increased license compatibility is a good thing (for example,
it is hard for us to use LGPL code), so we'll be looking to extend that
if we can.
Thanks for your feedback, Benoit- much appreciated-
Luis
Alexis Richardson
Is LGPL compatibility a current goal of MPL2?
alexis
Benoit Jacob
OK, thanks for the explanation.
>
> That said, we'll look at what we can do about minimizing this problem;
> we've talked with the CC people and one of them was in our office
> recently.
Great to hear!
> > See this very interesting article on a related topic (see
> > "Documentation licensing"):
> > http://lwn.net/Articles/394219/
> > Interesting quote: "the real problem is that we as a community lack
> > a copyleft license that works well for both code and text."
> Mozilla resolves that problem by just using MPL for documentation. If
> you have specific reasons or features that prevent you from using MPL
> for documentation, let us know and we can look at resolving it.
Nothing specific except that we'd at least need to wait for the MPL v2 for other reasons (California clause, etc).
> > 3. In section 9, the MPL v2 is still saying stuff about legal
> > disputes being resolved in California. Do you plan to keep that in
> > the final version of the MPL v2? I know I asked a similar question
> > at the Summit and the answer was (IIUC) that you were dropping that,
> > but it is still written in the current alpha, so I feel the need to
> > ask.
> I believe that I mentioned in the rationale document that we're still
> planning on resolving this issue; the only question is how.
> Unfortunately, we haven't figured that out yet, so the language was
> left
> in. Sorry if leaving it in made that unclear.
OK, thanks for the clarification.
> For what it is worth, we already can and do use BSD code; in fact,
> we've
> been able to borrow quite a bit of BSD'd code from Chrome/WebKit.
I know... I'm working with Google people and we're sharing some code ;-)
> But I
> agree that increased license compatibility is a good thing (for
> example,
> it is hard for us to use LGPL code), so we'll be looking to extend
> that
> if we can.
Many thanks again for your answers,
Benoit
Luis Villa
>
>> 3. In section 9, the MPL v2 is still saying stuff about legal
>> disputes being resolved in California. Do you plan to keep that in
>> the final version of the MPL v2? I know I asked a similar question at
>> the Summit and the answer was (IIUC) that you were dropping that, but
>> it is still written in the current alpha, so I feel the need to ask.
> I believe that I mentioned in the rationale document that we're still
> planning on resolving this issue; the only question is how.
> Unfortunately, we haven't figured that out yet, so the language was
> left in. Sorry if leaving it in made that unclear.
stumbling in the dark :) Among them is complete removal, but we've also
had a few suggestions from a variety of people on how we could increase
certainty without causing problems for the international user community,
and we're evaluating those options.
Luis Villa
> Luis
>
> Is LGPL compatibility a current goal of MPL2?
We're looking at it, yes, but (L)GPL compatibility is very hard, so it
isn't clear if we'll be able to achieve it.
Note here that compatibility means something like 'anyone distributing a
combination of MPL and LGPL code while meeting all the requirements of
the LGPL would also meet all the requirements of the MPL' rather than
something more broad like 'projects using the MPL would give all the
same grants as LGPL.'
Does that clarify? Let me know if not; this is obviously a tricky and
complicated issue and we're trying to do it the right way.
Thanks-
Luis
> alexis
>> That said, we'll look at what we can do about minimizing this problem; we've
>> talked with the CC people and one of them was in our office recently.
>>> See this very interesting article on a related topic (see "Documentation
>>> licensing"):
>>> http://lwn.net/Articles/394219/
>>> Interesting quote: "the real problem is that we as a community lack a
>>> copyleft license that works well for both code and text."
>> Mozilla resolves that problem by just using MPL for documentation. If you
>> have specific reasons or features that prevent you from using MPL for
>> documentation, let us know and we can look at resolving it.
>>> 3. In section 9, the MPL v2 is still saying stuff about legal disputes
>>> being resolved in California. Do you plan to keep that in the final version
>>> of the MPL v2? I know I asked a similar question at the Summit and the
>>> answer was (IIUC) that you were dropping that, but it is still written in
>>> the current alpha, so I feel the need to ask.
>> I believe that I mentioned in the rationale document that we're still
>> planning on resolving this issue; the only question is how. Unfortunately,
>> we haven't figured that out yet, so the language was left in. Sorry if
>> leaving it in made that unclear.
>>
>>> ===== My perspective =====
>> ...
>>> So here's the problem: all I wanted was the weak copyleft, and the LGPL
>>> gave me that but it also comes with a truckload of complexity and is hard to
>>> read.
>>>
>>> This is the reason why BSD-style licenses are so popular at the moment
>>> (and yes, they are, I can elaborate). I don't think that people are really
>>> that happy about allowing third parties to do proprietary forks of their
>>> free software projects. They just choose BSD-style licenses because they are
>>> short, simple, easy to read, without unexpected side effects (e.g.
>>> documentation licensing). If there existed a simple weak-copyleft license,
>>> it would be hugely popular, but the LGPL isn't that.
>>>
>>> I hope that the MPL v2 will be that. I can already say that it feels much
>>> more readable and simple than the LGPL v3.
>> Terrific to hear. We certainly hope people will like it and adopt it.
>>
>> For what it is worth, we already can and do use BSD code; in fact, we've
>> been able to borrow quite a bit of BSD'd code from Chrome/WebKit. But I
>> agree that increased license compatibility is a good thing (for example, it
>> is hard for us to use LGPL code), so we'll be looking to extend that if we
>> can.
>>
>> Thanks for your feedback, Benoit- much appreciated-
>> Luis
>>
>> --
>> Luis Villa, Mozilla Legal
>> work email:lvi...@mozilla.com (preferred)
>> work phone: 650-903-0800 x327
>> personal:http://tieguy.org/about/
>>
>> _______________________________________________
>> governance-mpl-update mailing list
>> governance...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/governance-mpl-update
>>
Alexis Richardson
Alexis
--
Sent from my mobile device
Alexander Terekhov
Luis Villa wrote:
[... obviously a tricky and complicated issue and we're trying to do it
the right way ...]
<chuckles>
http://wiki.answers.com/Q/What_is_the_salary_for_a_circus_performer
http://www.simplyhired.com/a/salary/search/q-circus
http://www.simplyhired.com/a/salary/home
You, "Mozilla Legal", do get more than $35,000 for such a wonderful job
you do, from Mozilla sponsors, right?
No?
Well, what a waste of dollars...
regards,
alexander.
Alexander Terekhov
what do you make of
<chuckles>
Don't you feel abused?
regards,
alexander.
Dr. Ernie
> Hey Luis,
>
> Don't you feel abused?
>
> regards,
> alexander.
Luis, I feel abused. I would like to formally request that Alexander's
posts to the list be moderated, as they appear to be increasingly off-
topic and offensive.
-- Ernie P.
Luis Villa
list-members for not having dealt with it earlier.
Alexander Terekhov
"Dr. Ernie" wrote:
[snip]
Theirs not to make reply,
Theirs not to reason why,
Theirs but to do and die,
Into the valley of Death
Rode the six hundred.
<chuckles>
regards,
alexander.
Luis Villa
could overlook, but obviously mocking other contributors to the list is
unacceptable. I'm in the middle of a family emergency but will handle
this when I return.
Luis
Alexander Terekhov
> I'm in the middle of a family emergency...
I wish your family member a speedy recovery.
May I just note that "mocking" is in the eye of the beholder just like
"beauty"...
regards,
alexander.
Gervase Markham
> Theirs not to make reply,
> Theirs not to reason why,
> Theirs but to do and die,
> Into the valley of Death
> Rode the six hundred.
Alexander,
Do you get up in the morning and actively set out to have people who
encounter you online feel sorry that you ever crossed their path? How
does it feel that the owners of mailing lists issue a collective
depressed sigh whenever your name is mentioned? That you bring a black
cloud to people's days and make their lives miserable? What motivates
you to do these things?
We don't want to have to start taking technical measures to boot you off
this list. We'd much rather you continued contributing constructively.
But make no mistake, we will.
Gerv
Alexander Terekhov
Gervase Markham wrote:
[...]
> Do you get up in the morning and actively set out to have people who
> encounter you online feel sorry that you ever crossed their path?
No.
> How does it feel that the owners of mailing lists issue a collective
> depressed sigh whenever your name is mentioned?
I don't know.
> That you bring a black cloud to people's days and make their lives
> miserable?
Eh?
> What motivates you to do these things?
What things?
> We don't want to have to start taking technical measures to boot you off
> this list. We'd much rather you continued contributing constructively.
> But make no mistake, we will.
Feel free.
regards,
alexander.