I like the future version... why get rid of it?
electroreactive
about releasing a provisional license... MPL2.0-draft that allows
updating to the MPL2.0... not a lot of people would use it but it's
only meant for those who are gamblers or want to be actively involved
in the future of the license... and use of a license would give people
more of a vested interest.
(I agree that it may polarize people... but it's better to hear
peoples opinion in the end, especially when it will affect the future
of the Mozilla license).
Your original goal was modernizing and updating the license... so why
are you changing it so much?
As for the removed parts in the 'termination' section... I worry that
a user under the old MPL could update and then terminate... if an
author selected 'or later' (which might work legally and may also
permit companies to update and then sue... losing their license but
being able to sue without financial mitigations.) Why not preserve
those clauses by reference for those who selected or later... if I
were writing it, I'd so include a 'contingencies' section.
Additionally, some users benefited from the selection of California
jurisdiction. For example, in the U.K. legal action against an
infringing party is, quite honestly, a pain. I know of one software
user who gave up rather than pursuing legal action because he simply
couldn't afford to. But using the MPL with california as the selected
jurisdiction would have allowed him recourse and defense against the
misappropriation of his code.
Note: You both requested this relevant feedback and I can tell you
that it is very relevant to a recent piece of misappropriated GPL
software. It's over and done with... the author gave in and gave him
a license and permission to link, on the condition that he give out
the source code to his modifications... which he's mostly done. XD
I like where the changes are headed but I do not believe every single
ramification of these updates should be considered. That is why I
recommend an iterative update. Sure, it would result in 3 or 4
additional MPL's, but the interim licenses would become quickly
depracated UNLESS a major error is made in the selection of the
license.
Additionally, AND THIS IS IMPORTANT TO SOME AUTHORS WHO WISH TO USE
THE CLAUSE, that the 'or later' be optional. EG, include the GPL
v2.0, and the GPLv2.0 or later. Linus Torvaldis, author of the linux
kernel, specifically did not agree to the 'OR LATER' portion. Though,
again, I don't advise it be the default. I still advise that 'or
later' be the default. EG: GPL v2.0 compatible MPL would imply 'OR
LATER'. GPLv2.0 ONLY or GPLv2.0-3.0 would exclude version... 4.0 for
instance, should one exist. The linux kernel is GPLv2.0... not or
later.
This post was edited from a previous version, if anything doesn't make
any sense at all, let me know and I'll correct it. I've tried to
resolve all error's.
Honestly, I like the California Jurisdiction. Make sure to allow this
as an option.
Luis Villa
On 12/2/10 8:37 PM, electroreactive wrote:
> I like the 'or any future version' clause in some licenses...
This is Section 10.2 of Alpha 3.
> how
> about releasing a provisional license... MPL2.0-draft that allows
> updating to the MPL2.0... not a lot of people would use it but it's
> only meant for those who are gamblers or want to be actively involved
> in the future of the license... and use of a license would give people
> more of a vested interest.
Using alpha/beta software code makes sense, because that creates more
testing than just reading the code. That outweighs the risk that people
will accidentally use alpha/beta software longer than they should.
Using alpha/beta *licenses* doesn't create more testing, unless you've
got a plan to release software under the alpha, get sued, and have a
court give you the result before we release the final version. :) And if
there is a mistake, there is a lot of risk there- you may have
accidentally given away the farm.
> Your original goal was modernizing and updating the license... so why
> are you changing it so much?
We've changed the language a lot, but we've done it primarily by
simplifying while keeping the same meaning. There are some exceptions,
of course, but those are primarily in areas we said we were going to
look closely at from the beginning, like the patent peace clause,
compatibility, etc.
> As for the removed parts in the 'termination' section... I worry that
> a user under the old MPL could update and then terminate... if an
> author selected 'or later' (which might work legally and may also
> permit companies to update and then sue... losing their license but
> being able to sue without financial mitigations.)
We believe that the new termination clause is still quite enforceable
against bad actors. If you have a specific concern about the clause that
you think makes it a loophole, please let us know so that we can
understand and fix it.
> Additionally, some users benefited from the selection of California
> jurisdiction. For example, in the U.K. legal action against an
> infringing party is, quite honestly, a pain. I know of one software
> user who gave up rather than pursuing legal action because he simply
> couldn't afford to. But using the MPL with california as the selected
> jurisdiction would have allowed him recourse and defense against the
> misappropriation of his code.
> Note: You both requested this relevant feedback and I can tell you
> that it is very relevant to a recent piece of misappropriated GPL
> software. It's over and done with... the author gave in and gave him
> a license and permission to link, on the condition that he give out
> the source code to his modifications... which he's mostly done. XD
We appreciate the feedback; we'll take it into consideration, but note
that most non-American users of the license have been very clear that
they do not appreciate the fixed California jurisdiction.
> Additionally, AND THIS IS IMPORTANT TO SOME AUTHORS WHO WISH TO USE
> THE CLAUSE, that the 'or later' be optional. EG, include the GPL
> v2.0, and the GPLv2.0 or later. Linus Torvaldis, author of the linux
> kernel, specifically did not agree to the 'OR LATER' portion. Though,
> again, I don't advise it be the default. I still advise that 'or
> later' be the default. EG: GPL v2.0 compatible MPL would imply 'OR
> LATER'. GPLv2.0 ONLY or GPLv2.0-3.0 would exclude version... 4.0 for
> instance, should one exist. The linux kernel is GPLv2.0... not or
> later.
This clause has caused some issues for the GPL community as well, by
causing compatibility issues between different codebases that did not
previously exist. We would prefer to address this by taking whatever
measures we can to build trust in our process and organization.
Thanks again for the feedback; if others have thoughts on these issues,
we'd be happy to discuss them further on the list.
Luis
--
Luis Villa, Mozilla Legal
work email: lvi...@mozilla.com (preferred)
work phone: 650-903-0800 x327
personal: http://tieguy.org/about/