What's the diff from the last version?
- Tweaked the wording of the "Original License" definition in the
Artistic License to make it clearer that it's talking about the copy of
the license shipped with the Package (i.e. the license isn't
auto-updating) and added an entry to the FAQ to explain this.
- Clarified the Artistic FAQ on the patent clause.
- Added some language about future patents to the CLA.
I think the following questions need to be clearly answered and put into the
Can I re-license a modified version under the GPL v2? Why?
Yes. Because GPL v2 satisfies the requirements of clause 4(c)(ii).
- If I can, then OpenBSD will likely do so, and offer perl under those terms.
Since Perl is currently dual-licensed under the GPLv2, he wouldn't be
doing anything particularly exciting there.
Can I re-license a modified version under the Artistic v1 license? Why?
No. In practical terms, Artistic 2.0 is a "bug fix" version of the
Artistic License, and we don't really want people to keep using Artistic
1.0, any more than we want people using Perl 5.6.0. In legal terms,
Artistic 1.0 is a less restrictive license than Artistic 2.0 (see the
answer to the next question), so only the original author (the
"Copyright Holder") can relicense Artistic 2.0 code under Artistic 1.0.
Can I include code from a GPL v2 project? Why?
No, you can't include code from a GPL (1 or 2 or 3) project in an
Artistic licensed package. Because the Artistic License (1.0 or 2.0) is
a less restrictive license than GPL (1 or 2 or 3). That is, if you
distributed GPL'd code under the Artistic License, you would be giving
away rights that the original author never gave you. The most obvious
example of this is the fact that the Artistic License allows proprietary
versions, but the GPL does not.
- This sucks if provision 13 prevents me from linking to GPL v2 libraries
as there are many of them that are very useful, and unlikely to change
It doesn't prevent you from linking to GPL libraries (in any version).
It only prevents you from absorbing GPL code into a package and
distributing that GPL code under an Artistic License. (You couldn't do
this under Artistic 1.0 either.)
It would be nice if the FSF could answer this question, as they
are pretty much the authoritative source of info on what is
compatible with the GPL.
We got the FSF/SFLC involved early in the process. (You may not know,
but Bradley Kuhn, who was Executive Director of the FSF for many years,
was largely responsible for the first draft of Artistic 2.0 during the
Perl 6 RFC process.)
The FSF's definition of compatibility is all about upstream
compatibility: what licenses can be included in GPL'd code. Artistic 2.0
meets this measure of GPL compatibility through clause 4(c)(ii).
The FSF doesn't care about downstream compatibility: whether you can
include GPL'd code in a package under some license other than the GPL.
The only license that is downstream compatible with the GPL is the GPL.
This is an intentional choice by the FSF. (Potentially, someone could
invent a license with exactly the same terms as the GPL but different
wording, and it would be possible to distribute GPL code under that
license. But there wouldn't be much point.)
Can I include code from an Artistic v1 licensed project? Why?
Yes. Because the terms of Artistic 2.0 are the same as Artistic 1.0,
aside from the added patent clause. That means Artistic 2.0 is a more
restrictive license than Artistic 1.0 (it gives away fewer rights), so
any Artistic 1.0 code can be distributed as Artistic 2.0.
- Obviously if I can't do this makes using old perl bits harder unless the
author can be tracked down and convinced to relicense. I'm pretty sure this
is obviously yes, but it would be good to have that stated in the faq, so I
can point lawyers/bosses/clients to it.
We'll work on an addition to the FAQ.
What is the status of code that was distributed by someone who has lost their
license under provision 13? Example: If I received a modified perl from SCO
under the Artistic v2 license, am I allowed to distribute that code if SCO
later files patent litigation, losing their license (assuming that I am
otherwise in compliance myself)? Why?
You would have to cease distribution. Or, more practically, you would
have to go download a legal version of Perl from your nearest CPAN
mirror and use it instead.
(If the company you're getting your open source packages from has such
poor judgment that it starts attacking open source projects or attacking
people for using open source code, it's probably a good idea to distance
yourself from the company anyway.)
- This has the potential to taint the work of people down the chain of
distribution, causing all sorts of mess.
So does the GPL, by requiring downstream users to distribute their
modified source code. But, they do it for a very specific purpose: to
promote the freedom of the code and the freedom of their users.
Revoking someone's license to use the software is an inconvenience. But
then, that someone would have already caused a pretty huge inconvenience
by filing patent litigation against one of our users for using our
software. The point is to make it inconvenient for the someone who
started the mess too, and so encourage them to respect the freedom of