gmane.comp.mozilla.license

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-03-27T13:56:35

I have now updated the license policy and flowchart with the outcome of
this discussion:
http://www.mozilla.org/MPL/license-policy.html

I've also tried to simplify and shorten the policy by removing
redundancy and reorganizing for clarity. Please let me know if anything
in that document seems weird, or doesn't match what you think was agreed.

Gerv

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-03-25T16:45:04

Sorry for the delay in getting back to this. I've been trying to talk to
Mitchell, and she's very busy :-) I spoke to her this morning about it.


The bottom line is that up to now we have been "MPL 2.0 only", and this
proposal is already a significant liberalization of that policy. To put
it another way, official policy already enshrines a preference. Further
liberalizations would require community-wide support for them to be
demonstrated.

So if you want to get together a coalition of people to make the case
for a further change, you are welcome to do that. But for now, we are
going to stick with my original proposal with a modified sentence 5:

"New Mozilla-originated software projects may choose either the MPL 2.0
or the Apache License 2.0. No other license is acceptable. When
integrating with, building on or relating to an existing codebase, the
license of that codebase should be chosen. Otherwise, the licensing team
recommends MPL 2.0 for client-side code, and either for server-side
code. Please consu

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-26T10:15:39

Further to this: I have had questions about patent clauses and how they
work and why they are good, and also about whether a change of licence
requires asking all the developers for permission. I have written a pair
of blog posts on these two subjects, and they can be found here:

http://blog.gerv.net/2013/02/an-introduction-to-modern-open-source-licence-patent-clauses/

http://blog.gerv.net/2013/02/relicensing-when-do-you-have-to-ask/

As before, follow-ups to mozilla.legal, please.

Gerv

Re: Mozilla and Non-Copyleft Licensing

Asa Dotzler — 2013-02-19T19:56:32

Nope. I'm good.

- A

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-18T18:15:47

That was the driver, yes. Would you prefer a more nuanced expression?

Gerv

Re: Mozilla and Non-Copyleft Licensing

Asa Dotzler — 2013-02-17T05:00:03

I'm sorry. I was reading the wrong newsgroup. I'd missed the correct 
location for this discussion, where much more context lives. I have 
answered my own question.

- A

Re: Mozilla and Non-Copyleft Licensing

Asa Dotzler — 2013-02-17T04:49:55

Why this line "No other license is acceptable"? Or from your original 
post "We should clearly and by name forbid the use of other licenses for 
Mozilla-originated codebases, without specific permission and in 
exceptional circumstances"?

Is this solely about the requirement for the patent protection clause?

- A

Re: Mozilla and Non-Copyleft Licensing

Mike Connor — 2013-02-14T14:14:59

I thought about that, but do we really have a consensus that copyleft is 
preferred by the project as a whole?  In most of the discussions I've 
seen on the subject, there's been strong desire from many to not require 
copyleft, and very little desire to maintain copyleft.  In the absence 
of consensus, I am reluctant to enshrine any preference in an official 
policy.  I'd be okay with a link helping developers to understand the 
pros and cons of the two licenses, but I don't want to put anyone in the 
position having to defend their choice if they go against a 
recommendation enshrined in official policy.

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-14T12:03:15

I sympathise with those who would rather code than care about licensing.
Unfortunately, the world does not work the way many of us would like it
to work, and restrictive you-cant-do-anything copyright is the default.

(See
http://tieguy.org/blog/2013/01/27/taking-post-open-source-seriously-as-a-statement-about-copyright-law/
for an interesting comment on this.)


See Will's data. Things are more heterogeneous than you think.

I hope also that other BSD/MIT-tending communities will read the state
of the world the same way we do, and move towards Apache 2.0 as the best
non-copyleft license available.


Apache is a non-copyleft license; what you say above is part of the
reason we want to change the policy to allow it.

Gerv

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-14T11:50:10

I think Will's very interesting data shows that you won't be standing
out too much. :-) Perhaps it's the equivalent of wearing chinos instead
of jeans.


Hence the discussion on changing the licensing policy. The flipside of
your point above is that we, as a respected open source project, want to
be promoting responsible licensing practice. We need to read the signs
of the times, which indicate that the software patent wars are going to
get worse before they get better. Where Mozilla leads, others follow
(see e.g. LibreOffice's adoption of the MPL 2). Which is why the
licensing team feels strongly that we should, going forward, only use
licenses with explicit patent clauses - because it helps us, and
encourages others to do the same.

Allowing Apache 2.0 into the mix is an attempt to do that, and also do
our best to meet the requirements of some communities for non-copyleft
licensing. Mozilla's community license is the MPL 2, but we understand
that not all the work Mozilla does is solely part of our own com

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-14T11:41:36

Fair point. First four sentences? :-)

Gerv

Re: Mozilla and Non-Copyleft Licensing

Mike Connor — 2013-02-13T23:34:05


I don't think it should be necessary to consult with licensing< at > if a project is choosing one of the two acceptable licenses.  This strikes me as unnecessary overhead and friction, when the policy should strive for the minimum necessary work needed to comply.  Project owners should be free to choose either of the acceptable licenses based on their own circumstances.

On that principle, I would propose that we simply adopt the first three sentences of the above text, and cut the rest.

Re: [webdev] Mozilla and Non-Copyleft Licensing

Mike Connor — 2013-02-13T23:15:30

The original email proposed either of MPL2 or APL2 for server code, so I'm assuming that's fine.

Re: [webdev] Mozilla and Non-Copyleft Licensing

Peter Bengtsson — 2013-02-13T23:08:50

I would be happy to use Apache2 instead of BSD if Gerv thinks that's 
better.

As Will pointed out, the Python open source peeps won't scream and laugh 
at me for not using BSD on my non-MPL2 projects.

And if some someone thinks BSD is a million dollar better than Apache2, 
then that's just tough. Time to progress!

Peter

On 13/02/2013 13:10, Wraithan (Chris McDonald) wrote:

Re: Mozilla and Non-Copyleft Licensing

David Ascher — 2013-02-13T22:04:17

On 2013-02-13, at 1:40 PM, Gervase Markham <gerv< at >mozilla.org> wrote:


Indeed, it may just be a matter of education.  Maybe reaching out to someone who speaks with authority in the Django world would elucidate the question.

--da

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-13T21:40:14

It would be great if you could help us understand why Apache (which is,
in legal effect, BSD with a patent clause) is unacceptable to that
community.


My understanding was that the web dev team were keen on non-copyleft
licensing, which the licensing policy didn't allow; formally enabling
that was what this discussion was all about. If that's not the point you
were making, then there's been some miscommunication.


I did my best to get people involved in the discussion, including a
specific email written to the webdev list to come and get involved. If
webdevs aren't reading the webdev list, then could I politely suggest
their community engagement needs a little polishing?

Gerv

Re: [webdev] Mozilla and Non-Copyleft Licensing

Michael Kelly — 2013-02-13T21:23:00

I agree with Wraithan. django-browserid, for example, would be a great 
case for using a common Python/Django license like BSD, as it would 
help encourage adoption of Persona-based authentication in Django sites 
by making it easier for developers to figure out if they can use the 
library or not.

Granted, no one has come to me and said "I can't use django-browserid 
becasue it's MPLv2", so I have no hard evidence for this. Doh!

-Mike Kelly

On Wed Feb 13 16:10:37 2013, Wraithan (Chris McDonald) wrote:

Re: Mozilla and Non-Copyleft Licensing

Wraithan (Chris McDonald — 2013-02-13T21:10:37

Gerv,

Can't say I am keen on this. we are taking away the ability for us to 
license things to fit into the community they are being built for? BSD 
being the way of the vast majority of python/django projects. One of the 
coolest things about Mozilla when I joined was this ability. The 
knowledge that my hands wouldn't be tied if I made something neat.

It appears none of the discussion made any difference because you've 
gone right back to what you were originally arguing for. I feel like the 
discussion may have trailed off, but is still important and an agreement 
was never come to.

I've CC'd webdev as there are a lot of us who feel strongly on this and 
the email didn't go out to all of them.

To distil my disagreements:
1) This takes away our ability to blend into communities we are a part of.
2) Requires the extra work of consulting legal if when releasing 
something we feel strongly should be more permissive or at least, 
differently permissive.
3) The discussion wasn't finished, it just happened t

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-02-13T16:46:35

Having taken in the various viewpoints, I suggest the next step is a
concrete proposal. Here is one.

We should update the Mozilla License Policy[0]. On the particular topic
of which license to choose for a new project, it should say:

"New Mozilla-originated software projects may choose either the MPL 2.0
or the Apache License 2.0. No other license is acceptable. When
integrating with, building on or relating to an existing codebase, the
license of that codebase should be chosen. Otherwise, the licensing team
recommends MPL 2.0 for client-side code, and either for server-side
code. However, the decision should be taken on a case-by-case basis in
consultation with the licensing team."

Gerv

[0] http://www.mozilla.org/MPL/license-policy.html

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-01-23T14:06:18

I'm not sure one could say the MPL was the tipping factor one way or the
other for a particular contribution. I can try and answer the related
question, "why is the MPL's particular brand of copyleft strength a good
choice for Mozilla?"

I think the answer to that is that the file-level copyleft sets up a
community expectation of sharing more than permissive licenses do, while
not prohibiting proprietary derivatives in the way stronger copyleft
licenses do. Some, of course, may not agree with the first half of that.


I've not seen an explicit post-mortem. I did not carefully study Flock's
licensing, but my understanding from others is that they took
tri-licensed code and made it GPL-only to prevent Mozilla from
reincorporating their changes. (Of course, there's still the question of
whether we'd have wanted to take their changes.) This is unfriendly, but
then the MPL itself is designed to allow proprietary derivative works
like e.g. Netscape 6+. It could be argued that the only difference with
Flock is tha

Re: Mozilla and Non-Copyleft Licensing

Gervase Markham — 2013-01-23T13:31:52

Sorry, this is all wrong. Ignore this message.

Gerv