Re: Artistic License (license to steal?) - Open Source copyrights

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

raylopez99 <raylopez99@xxxxxxxxx> wrote:
Yeah but look at the terms of the artistic license--it's nearly as bad
as GPL (not that I've studied GPL but I can imagine).

How can you compare two things when you don't know anything about one
of them?

In my mind's eye.

Fortunately, the law doesn't consist of what you imagine. It consists
of what's actually in the licence you agree to by using the software.

Here's the part of the Wikipedia GPL entry which talks about the GPL's
"viral" nature:

<quote>
The GPL has been described as being "viral" by many of its critics
because the GPL only allows conveyance of whole programs, which means
that programmers are not allowed to convey programs that link to
libraries having GPL-incompatible licenses. The so-called "viral"
effect of this is that under such circumstances disparately licensed
software cannot be combined unless one of the licenses is changed.
Although theoretically either license could be changed, in the "viral"
scenario the GPL cannot be practically changed (because the software
may have so many contributors, some of whom will likely refuse),
whereas the license of the other software can be practically changed.
</quote>

Now, please show where that applies in the artistic licence, or
withdraw the suggestion that the artistic licence is viral.


No. Please withdraw your suggestion that it's not. Read the below.
Are you an EFL student too? Like Arne and I? You have no excuse,
since english is your first language. Read then:

<snip>

FYI, FUD-denier, here is the definition of package:
http://www.perlfoundation.org/artistic_license_1_0
"Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files created
through textual modification.

What part of "Package" don't you understand? Don't you see that
'derivatives' would encompass anything you do with the original code?

No, it wouldn't. If I create an online game which happens to use a
library for its HTTP communications, only changes to that library would
be included in "the package". The best way to achieve that in .NET
would be to keep the library itself in a separate assembly, and release
changes made in that assembly. At that point you're distributing a
modified version of the package, and a larger program which uses that
modified version.

So essentially your whole software project that incorporates this
poisonous 'artistic license' source code is toast, and virally
infected by the same.

Nope.

Perhaps if you don't believe me, you'll believe Larry Wall, who wrote
the artistic licence in the first place.

From http://www.linux.com/feature/14792

<quote>
"I was a little bothered when Microsoft, or one part of Microsoft
labels Perl's artistic license as potentially viral," said Wall,
explaining that he had written Perl's license as an antidote to the
GPL.
</quote>

Nonsense. You can use it without modification *very* easily, and even
with modification you can use it *quite* easily, without exposing the
rest of your source code. You have no evidence for the supposed
"viral" nature of the artistic licence.

B.S. Jon. You only can do the four things listed above, as options a)
through d).

Those options are only relevant if you actually want to *modify* the
package. Otherwise, clause 4 is relevant:

<quote>
4.You may distribute the programs of this Package in object code or
executable form, provided that you do at least ONE of the following:

a) distribute a Standard Version of the executables and library files,
together with instructions (in the manual page or equivalent) on where
to get the Standard Version.
b) accompany the distribution with the machine-readable source of the
Package with your modifications.
c) give non-standard executables non-standard names, and clearly
document the differences in manual pages (or equivalent), together with
instructions on where to get the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
</quote>

4a is the most commonly used option - you include an acknowledgement in
your user manual, or readme, or whatever, saying where you got the
code. Easy.

Quite trying to mollify everybody. That's as dangerous
as FUD--worse even--since you're leading readers into a false sense of
security. And somebody in your position should know better. I can
always say "I was just flaming" and nobody relies on what I say, but
you're in a different boat. You're leading gullible readers down a
primrose path of destruction, to mix my metaphors. Shame on you. Or
maybe you work for the "Artistic License Society of England", eh?
Good for business for this license to be adopted widely, eh? Then
after it's widely adopted you can swoop in and claim royalties from
everybody. Trojan horse tactic, I'm familiar with that thank you very
much.

LOL.

(I say if the in-house use is ultimately for commercial purposes, it
doesn't qualify as 'in-house' but you disagree--on this point we
agree to disagree).

You're claiming this with *no* evidence. Please point out which part of
the licence says this.

The english language, as defined by Bill Shakespeare and William "Ben"
Jonson.

Have you noticed how everyone else in this thread, reading the same
licence, has agreed with my reading rather than yours? The artistic
licence is well-known to be a permissive one. You're the only person
I've ever heard trying to claim it's viral and akin to the GPL.

Can you reed? Read this: "b) use the modified Package only
within your corporation or
organization. ". Do you think artistic license code that is used to
build stuff that ships commercially, even if that code is for
prototyping, is "only within your corporation"? Methinks not.

Absolutely it is.

"Only within" means the code never is used, even as helper code, for
anything that ships or is used outside the four walls of your
corporation. Nuff said.

No it doesn't. It means that the code is never distributed beyond your
organisation. If you run a server which executes the code (e.g. for
database access) and then provides the results to the user, that is in
no way distributing the code. You are only *using* it within your
organisation.

Without being able to refer to anything explicitly in the licence, all
your scaremongering is just FUD.

Like I said, the most liberal or catholic part of the license is
option "c)", and you've not refuted me on that.

It's an *option*. One of four options, and only even necessary if you
modify the package, which most people won't.

You wanna be writing
a man page for every artistic license block of code that you modify,
"[the] separate manual page for each non-standard executable that
clearly documents how it differs from the Standard Version. "? How it
differs. Now, if you want to be too clever by half, you can say that
your man page will simply state "my derivatives *DO NOT* differ at
all--they are copied verbatim from the artistic license code!" #

No, because at that point I wouldn't be taking up option c. I would use
option 4a.

But this schoolboy trick will not work, since you run afoul of the
first part of that paragraph: "You may otherwise modify your copy of
this Package in any way, provided that you insert a prominent notice
in each changed file stating how and when you changed that file, and
provided that you do at least ONE of the following:"

Thus, you cannot modify (and you infringe the copyright) unless you
can do at least ONE (emphasis in the original) of the following four
options a) through d).

Um, that means the "schoolboy trick" *would* work, if it were actually
necessary - but it isn't.

Nuff said. Use artistic licenses at your peril. Unless you are a
penniless hobbiest like me. Or you?

No, I work in a multinational corporation which uses open source
extensively. Every company I've previously worked at has used open
source extensively too. At each company there have been lawyers poring
over the licences of code we've used. They haven't been happy with the
idea of distributing code linking to GPL code (understandably); they've
just about allowed (sometimes after a struggle) distributing code
linking to LGPL code. They've not had any problem with Apache, BSD,
artistic etc licences.

--
Jon Skeet - <skeet@xxxxxxxxx>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com
.

Relevant Pages

  • Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
    ... You have _read_ the licence, ... themselves, then this License, and its terms, do not apply to those ... This is why kernel modules can have their own, ... by the GPL. ...
    (Linux-Kernel)
  • RE: GPL weasels and the atheros stink
    ... under the ISC licence, OR the GPL licence. ... GPLv2 into code that is licensed under the dual license and distribute the ...
    (Linux-Kernel)
  • Re: From the LuxAsm list.
    ... > No. I'm not asking anything about GPL. ... >> have no other License but the one choosen by the Programmer. ... see clause 5 of the RosAsm licence. ...
    (alt.lang.asm)
  • Re: ANN: WSS4R was released
    ... Strictly speaking, once an open source package has been released> under *any* licence, that version is perpetually available under that> licence. ... The GNU GPL is more related to an "I'll show you mine if you> show me yours" sort of relationship. ... If I were working on commercial free software, for instance, I would want to preserve my business assets by ensuring that no one could lock them away under their own facade and then distribute non-free applications derived from it. ... There is no better license for ensuring this than the GPL, and to me, offers protection without the burden of a proprietary licensing scheme. ...
    (comp.lang.ruby)
  • [PATCH] change libata license from OSL+GPL to GPL
    ... - changes license of all code from OSL+GPL to plain ole GPL ... indicate your decision by deleting the provisions above and ...
    (Linux-Kernel)