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

[Ken Foskey]

On Thu, 14 Aug 2008 10:09:01 -0700, raylopez99 wrote:

Be afraid, if you code for money, with this recent ruling on Artistic
Licenses.

The facts of the case above are that the person took a whole application
and distributed it after some minor modifications, ie they did not do
much at all to the whole thing. It was outright theft. How would you
feel if someone stole your application that you were selling and then
distributed it. What is the difference?

Artistic, GPL and LGPL are licenses, Public Domain is a totally
different thing. You need to read and understand copyright or else you
will fall foul of things.

I am entitled to dictate how my work is used, ie copyright. I use Open
Source licenses to protect my work from unauthorised use. For me,
unauthorised use is taking my work and using it in a way that is no
longer free, as in open to others to use. I do paid work and it is
copyright to my employer and it is closed source, I would never steal
that code and use it because of copyright as well.

Note that most open source software is fine to use and modify in in house
applications because it is never distributed. Google does not release
all their code changes to the public, a fair number of their changes make
their way back because it is a smart business model.

Ken

[raylopez99]

On Aug 14, 2:58*pm, Ken Foskey <[e-mail]:

Note that most open source software is fine to use and modify in in house
applications because it is never distributed. *Google does not release
all their code changes to the public, a fair number of their changes make
their way back because it is a smart business model.

And when they make it back into the commercial world, if that code is
'closed' you run afoul of the artistic license, no?

Bottom line for most of the people reading this thread: trust the
public obfuscator is doing a good job hiding your code, else the
copyright owner of the code you cribbed is likely to sue your
employer! (long after you, the programmer, have moved onto another
job).

RL

[Jon Skeet [C# MVP]]

On Aug 15, 10:30*am, raylopez99 <[e-mail]:

On Aug 14, 2:58*pm, Ken Foskey <[e-mail]:

Note that most open source software is fine to use and modify in in house
applications because it is never distributed. *Google does not release
all their code changes to the public, a fair number of their changes make
their way back because it is a smart business model.

And when they make it back into the commercial world, if that code is
'closed' you run afoul of the artistic license, no?

I think you've missed Ken's point. A lot of code in the commercial
world is never distributed outside the company - it's in-house
applications, or running on a server. At that point you don't need to
worry about the distribution clauses, because you're not distributing
your code. Yes, there's more to do if you're distributing your code -
but often it still only means giving credit where it's due.

Bottom line for most of the people reading this thread: *trust the
public obfuscator is doing a good job hiding your code, else the
copyright owner of the code you cribbed is likely to sue your
employer! (long after you, the programmer, have moved onto another
job).

That really shouldn't be the bottom line. That's like saying that the
bottom line of murder laws is "be careful to hide the body when you
kill people otherwise you'll get arrested."
The bottom line should be: understand the licence of any code you want
to use, and abide by that licence. Consult legal counsel when in any
doubt. Play nicely by open source projects - they have a lot to offer,
and the demands of the licence are usually very reasonable.

Jon

[raylopez99]

On Aug 15, 3:03*am, "Jon Skeet [C# MVP]" <[e-mail]:

And when they make it back into the commercial world, if that code is
'closed' you run afoul of the artistic license, no?

I think you've missed Ken's point. A lot of code in the commercial
world is never distributed outside the company - it's in-house
applications, or running on a server. At that point you don't need to
worry about the distribution clauses, because you're not distributing
your code. Yes, there's more to do if you're distributing your code -
but often it still only means giving credit where it's due.

Code that only runs inhouse is rare. Even code running on a server
will be deemed "commercial", because if you read the option (B)
carefully, you'll see it does in fact cover a "one copy used in-house
but interacting with the public", if that copy is commercial: "b) use
the modified Package only within your corporation or organization. ".
Do you think "only within" will cover an application that runs a
server that interacts with the public? No way Jose. That is not
covered, I'm almost 100% sure. A clever plaintiff's lawyer will
skewer you with that one. "only within" means code that only is for
benchmarking, only for prototypes, etc, that will never be
commercialized, will never interact with the public. And since a lot
of these licenses are "viral", meaning if prototype code is
commercialized it will run afoul of the copyright license, it's best
to stay away from this kind of code. At least that's what big
corporations who know better do.

But don't take my word for it...not my field.

RL

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Jon Skeet [C# MVP] wrote:

On Aug 15, 2:53 pm, raylopez99 <[e-mail]:

>Code that only runs inhouse is rare.

Actually it's extremely common in my experience.

Yep.

Business app type code developed for and only used in one company
is the bread and butter of the entire IT industry. From Cobol to
ASP.NET !

Arne

[J. Clarke]

raylopez99 wrote:

On Aug 15, 3:03 am, "Jon Skeet [C# MVP]" <[e-mail]:

>>And when they make it back into the commercial world, if that code
is 'closed' you run afoul of the artistic license, no?

I think you've missed Ken's point. A lot of code in the commercial
world is never distributed outside the company - it's in-house
applications, or running on a server. At that point you don't need
to
worry about the distribution clauses, because you're not
distributing
your code. Yes, there's more to do if you're distributing your
code -
but often it still only means giving credit where it's due.

Code that only runs inhouse is rare. Even code running on a server
will be deemed "commercial", because if you read the option (B)
carefully, you'll see it does in fact cover a "one copy used
in-house
but interacting with the public", if that copy is commercial: "b)
use
the modified Package only within your corporation or organization.
".
Do you think "only within" will cover an application that runs a
server that interacts with the public? No way Jose. That is not
covered, I'm almost 100% sure. A clever plaintiff's lawyer will
skewer you with that one. "only within" means code that only is for
benchmarking, only for prototypes, etc, that will never be
commercialized, will never interact with the public. And since a
lot
of these licenses are "viral", meaning if prototype code is
commercialized it will run afoul of the copyright license, it's best
to stay away from this kind of code. At least that's what big
corporations who know better do.

But don't take my word for it...not my field.

I don't understand what your problem with all this is. If you use
copyrighted code you have to abide by whatever terms the copyright
holder sets. If instead of the specific restrictions in the "artistic
license" the copyright holder just wanted you to send him a check for
ten billion dollars would you be equally upset, or would you just
decide that that particular code was too pricey for your budget and
use something else instead?

--
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net)

[MC]

"J. Clarke" <jc************@cox.netwrote in message
news:Oa****************@TK2MSFTNGP05.phx.gbl...

I don't understand what your problem with all this is. If you use
copyrighted code you have to abide by whatever terms the copyright
holder sets. If instead of the specific restrictions in the "artistic
license" the copyright holder just wanted you to send him a check for
ten billion dollars would you be equally upset, or would you just
decide that that particular code was too pricey for your budget and
use something else instead?

Well said.

This reminds me of arguments I had with shareware authors in the mid-1980s.
They couldn't understand why not everybody who downloaded their software
would register it and pay for it. The answer, which they didn't want to
face, is that often, it was mediocre software with a high price (relative to
hobbyist budgets), and after testing it on a free-trial basis, people
decided not to buy it.

Today -- if the license on "open source" software is too quirky, just don't
use the software.

[Jon Skeet [C# MVP]]

MC <fo**************@www.ai.uga.edu.slash.mcwrote:

Well said.

This reminds me of arguments I had with shareware authors in the mid-1980s.
They couldn't understand why not everybody who downloaded their software
would register it and pay for it. The answer, which they didn't want to
face, is that often, it was mediocre software with a high price (relative to
hobbyist budgets), and after testing it on a free-trial basis, people
decided not to buy it.

Today -- if the license on "open source" software is too quirky, just don't
use the software.

Which is exactly right - although when it comes to just *using*
software (as opposed to modifying it and/or redistributing it) it's
pretty rare for there to be anything worrying in an open source
licence. Commercial licences are usually significantly stricter!

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

[raylopez99]

Jon Skeet [ C# MVP ] wrote:

Today -- if the license on "open source" software is too quirky, just don't
use the software.

Which is exactly right - although when it comes to just *using*
software (as opposed to modifying it and/or redistributing it) it's
pretty rare for there to be anything worrying in an open source
licence. Commercial licences are usually significantly stricter!

Jon, you have not thought through the problem, because if you did, you
would realize 'viral software' infects all your code. Thus only
option 'B' that I pointed out is feasible--you have to rework the
code, make it yours, and thus escape this particular license. That
said, some licenses are even more unreasonble, namely common copyright
law, which basically says once you the programmer look at somebody
else's code, then put it in your own form, you may be violating the
copyright anyway, if it 'looks and feels' like the original author's
code. Actual problem: the BIOS writers in the early or was it late
1980s had to 'clean room' reconstruct the BIOS done by IBM and others
because if they did not, it would be a copyright violation. So they
got engineers who had never even seen the BIOS of the original
author(s), and made them solve the problems that BIOS addresses,
independently. This worked (they were sued but won).

A more concrete example: if you can independently, without looking at
J. K. Rowling's "Harry Potter", come up with "Harry Potter", then you
don't infringe her copyright--but, if you read her works, then come up
with "Harry Potter", you do.

You have a lot to learn grasshopper...

Google and read 'viral licenses' and the problems with GNU.

Like I said, not my field so this is my last post in this thread.

RL

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yahoo.comwrote:

Today -- if the license on "open source" software is too quirky, just don't
use the software.

Which is exactly right - although when it comes to just *using*
software (as opposed to modifying it and/or redistributing it) it's
pretty rare for there to be anything worrying in an open source
licence. Commercial licences are usually significantly stricter!

Jon, you have not thought through the problem, because if you did, you
would realize 'viral software' infects all your code.

Not with the artistic licence. With the GPL there would be more of an
issue, but that's a different licence - and one which *tends* to be
avoided by companies for precisely that reason.

Here's the definition of Package:

<quote>
"Package" refers to the collection of files distributed by the
Copyright Holder, and derivatives of that collection of files created
through textual modification.
</quote>

In fact, there's another clause I hadn't seen before which makes the
whole thing even simpler for most cases:

<quote>
8. Aggregation of this Package with a commercial distribution is always
permitted provided that the use of this Package is embedded; that is,
when no overt attempt is made to make this Package's interfaces visible
to the end user of the commercial distribution. Such use shall not be
construed as a distribution of this Package.
</quote>

Thus only option 'B' that I pointed out is feasible--you have to
rework the code, make it yours, and thus escape this particular
license. That said, some licenses are even more unreasonble, namely
common copyright law, which basically says once you the programmer
look at somebody else's code, then put it in your own form, you may
be violating the copyright anyway, if it 'looks and feels' like the
original author's code. Actual problem: the BIOS writers in the early
or was it late 1980s had to 'clean room' reconstruct the BIOS done by
IBM and others because if they did not, it would be a copyright
violation. So they got engineers who had never even seen the BIOS of
the original author(s), and made them solve the problems that BIOS
addresses, independently. This worked (they were sued but won).

That's a completely different issue, and also inapplicable to the
artistic licence as IBM didn't release the BIOS under the artistic
licence.

A more concrete example: if you can independently, without looking at
J. K. Rowling's "Harry Potter", come up with "Harry Potter", then you
don't infringe her copyright--but, if you read her works, then come up
with "Harry Potter", you do.

And again, this isn't about coming up with a similar package, it's
about redistributing the existing package or openly modifying it. Also
again, Harry Potter wasn't released under the artistic licence, so it's
not relevant to this discussion.

You have a lot to learn grasshopper...

Funny how often you keep claiming that on all kinds of issues where you
appear to know very little.

Google and read 'viral licenses' and the problems with GNU.

And then realise that the GPL and the artistic licence are *different
things*. Yes, using GPL'd code in distributed software is a bit of a
minefield. (It's fine for software you don't distribute, however - such
as web application code that you only run inside the company.) That
doesn't mean the same is true for the artistic licence, or Apache, or
BSD, etc.

Like I said, not my field so this is my last post in this thread.

It doesn't have to be your field to realise that the GPL and the
artistic licence are completely different.

It also doesn't have to be your field for you to avoid encouraging
people to break the law.

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

[raylopez99]

Jon Skeet [ C# MVP ] wrote:

And then realise that the GPL and the artistic licence are *different
things*. Yes, using GPL'd code in distributed software is a bit of a
minefield. (It's fine for software you don't distribute, however - such
as web application code that you only run inside the company.)

AHA! "a bit of a minefield". Precisely my original point. Admission
acknowledged.

That
doesn't mean the same is true for the artistic licence, or Apache, or
BSD, etc.

Etc. Right. I will repeat what you said about my "Harry Potter"
analogy and simply say this was not part of the original thread. Your
admission is again noted however.

RL

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yahoo.comwrote:

Jon Skeet [ C# MVP ] wrote:

And then realise that the GPL and the artistic licence are *different
things*. Yes, using GPL'd code in distributed software is a bit of a
minefield. (It's fine for software you don't distribute, however - such
as web application code that you only run inside the company.)

AHA! "a bit of a minefield". Precisely my original point. Admission
acknowledged.

Please read carefully. I wrote that using *GPL'd* code can be a
minefield. That's *not the same as the artistic licence*.

If this whole thread had been about the GPL, it would have been very
different. But no, your original point was about the artistic licence.
From the very start of your very first post:

<quote>
Be afraid, if you code for money, with this recent ruling on Artistic
Licenses.
</quote>

That doesn't mean the same is true for the artistic licence, or
Apache, or BSD, etc.

Etc. Right. I will repeat what you said about my "Harry Potter"
analogy and simply say this was not part of the original thread. Your
admission is again noted however.

My "admission" about the GPL, which in no way affects what I've written
about the GPL? Feel free to note it however you wish, but don't try to
make out that it applies to the artistic licence.

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

[raylopez99]

Jon Skeet [ C# MVP ] wrote:

If this whole thread had been about the GPL, it would have been very
different. But no, your original point was about the artistic licence.
From the very start of your very first post:

<quote>
Be afraid, if you code for money, with this recent ruling on Artistic
Licenses.
</quote>

That doesn't mean the same is true for the artistic licence, or
Apache, or BSD, etc.

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). As I pointed
out to you, there's not much you can do with works covered by artistic
license except modify it (and documenting all changes with tedious man
pages), negotiate with the owner, or, on a point we dispute, use it in-
house (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).

RL

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yahoo.comwrote:

If this whole thread had been about the GPL, it would have been very
different. But no, your original point was about the artistic licence.
From the very start of your very first post:

<quote>
Be afraid, if you code for money, with this recent ruling on Artistic
Licenses.
</quote>

That doesn't mean the same is true for the artistic licence, or
Apache, or BSD, etc.

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?

What would you think of someone who saw a painting and said, "That's
nearly as good as a Van Gogh. I haven't seen a Van Gogh, but I can
imagine." ?

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.

As I pointed out to you, there's not much you can do with works
covered by artistic license except modify it (and documenting all
changes with tedious man pages), negotiate with the owner, or, on a
point we dispute, use it in- house

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.

(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.

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

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

[raylopez99]

Jon Skeet [ C# MVP ] 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.

>
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:

/*

http://en.wikipedia.org/wiki/Artistic_License

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:

a) place your modifications in the Public Domain or otherwise make
them Freely Available, such as by posting said modifications to
Usenet
or an equivalent medium, or placing the modifications on a major
archive site such as uunet.uu.net, or by allowing the Copyright
Holder
to include your modifications in the Standard Version of the Package.
b) use the modified Package only within your corporation or
organization.
c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and provide a
separate manual page for each non-standard executable that clearly
documents how it differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.

*/

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?
So essentially your whole software project that incorporates this
poisonous 'artistic license' source code is toast, and virally
infected by the same.

As I pointed out to you, there's not much you can do with works
covered by artistic license except modify it (and documenting all
changes with tedious man pages), negotiate with the owner, or, on a
point we dispute, use it in- house

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). 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.

>

(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. 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. "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.

>
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. 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!" 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).

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

RL

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

raylopez99 wrote:

Jon Skeet [ C# MVP ] wrote:

>If this whole thread had been about the GPL, it would have been very
different. But no, your original point was about the artistic licence.
From the very start of your very first post:

<quote>
Be afraid, if you code for money, with this recent ruling on Artistic
Licenses.
</quote>

>>>That doesn't mean the same is true for the artistic licence, or
Apache, or BSD, etc.

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). As I pointed
out to you, there's not much you can do with works covered by artistic
license except modify it (and documenting all changes with tedious man
pages), negotiate with the owner, or, on a point we dispute, use it in-
house (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).

The terms distribution is rather well-defined in relation to
open source licenses.

And Jon is right and you are wrong.

http://www.gnu.org/licenses/gpl-faq.html#UnreleasedMods
http://www.gnu.org/licenses/gpl-faq....alDistribution
etc.

BTW, you should have been able to figure it out, because an
open source license can not prevent commercial usage.

http://www.opensource.org/docs/osd (item #6)

And your hole tirade is completely meaningless. The
artistic license is rather permissive. The only way
you can come in conflict with that is if you
deliberately want to steal.

Arne

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yahoo.comwrote:

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 - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Ken Foskey]

On Fri, 15 Aug 2008 06:53:29 -0700, raylopez99 wrote:

But don't take my word for it...not my field.

Of all your posts. This is the one point I have to agree with. I
suggest reading groklaw for a while to get the feel of copyright law
instead of showing your ignorance of the subject.

Using your definition of 'distribution' via HTTP use then Googles Linux
farm is subject to code release because it is exposed to HTTP. I have
never seen this argued ever, and I don't expect it ever to be.

Ken

[raylopez99]

On Aug 16, 11:41*pm, Jon Skeet [C# MVP] <[e-mail]:

>

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

Nope.

Yep. See the link you cited: http://www.linux.com/feature/14792 if
this wasn't an issue, why would MSFT even mention it? Clearly it's
not unambiguous.

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

Fromhttp://www.linux.com/feature/14792

Proves my point. Read between the lines and ignore the usual FUD
about Microsoft (MSFT).

>
<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>

Well, a critic of MSFT can't be trusted, can he?

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:

OK, I concede this, but you then, by your own logic, concede these
four options a) - d) *are* relevant and *are* viral for *modified*
code.

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.

You are correct--but changing the goal posts. Yes, if you do nothing
to the artistic license code, and distribute as is, then yes, option
4a (a different option than what we've discussed to date) applies.
But, the minute you make the most minute change to the artistic
license code, you run afoul of the other four options I've discussed--
and at this point your entire project is contaminated, unless you
comply with one of the onerous options we've discussed.

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.

Because they hate Microsoft.

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

Yes, you got me on that. Indeed, as you pointed out in your last
thread, the one I'm replying to, if you do nothing to the artistic
license code then you only have to acknowledge it--which is not
onerous at all and quite generous to the non-author user. But,
contrary to what you assert, how many people 'do nothing' to such
artistic license code? I doubt very many, though you could be
right.

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.

Yeah, and if it's Google it explains your anti-MSFT stance. But let's
not get personal over this, as you cannot dump on your employer, and I
don't want you to (BTW I am a MSFT shareholder, just to show my bias).

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.

Admission noted. They've not had problems with certain specific well
tailored licenses. But this artistic license was 'bizarre' if I
recall the news story--that's why it was litigated--not at all like
the tamer Apache, BSD etc licenses.

Thanks for your time. I originally was trying to do a bit of trolling
with this story but in the process actually learned a few things.
Namely, if you don't touch the artistic license code we've discussed
and as was recently litigated, it's not viral, otherwise, it is, and
you have to comply with one of the onerous four options we originally
discussed early on in this thread.

Goodbye

RL

[raylopez99]

On Aug 17, 1:48*am, Ken Foskey <[e-mail]:

Using your definition of 'distribution' via HTTP use then Googles Linux
farm is subject to code release because it is exposed to HTTP. *I have
never seen this argued ever, and I don't expect it ever to be.

I vaguely recall in fact such as argument was made. It was in some
minor litigation, and it was just a lawyer's 'talking point', nothing
serious. I think and I agree it's a weak argument, but one that could
and I believe has been made.

RL

[Jon Skeet [C# MVP]]

raylopez99 <ra********@yahoo.comwrote:

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

Nope.

Yep. See the link you cited: http://www.linux.com/feature/14792 if
this wasn't an issue, why would MSFT even mention it? Clearly it's
not unambiguous.

Or Microsoft was perhaps being a little ungenerous to open source? It
would hardly be the first time.

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

Fromhttp://www.linux.com/feature/14792

Proves my point. Read between the lines and ignore the usual FUD
about Microsoft (MSFT).

I believe the person who *wrote* the licence rather than Microsoft's
interpretation of it.

<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>

Well, a critic of MSFT can't be trusted, can he?

Wow. That statement just amazes me. It shows you can't be objective
about anything.

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

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

OK, I concede this, but you then, by your own logic, concede these
four options a) - d) *are* relevant and *are* viral for *modified*
code.

Relevant, yes. Viral, no.

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.

You are correct--but changing the goal posts.

Not at all. I'm just taking in the whole of the licence, as opposed to
just part of it. You were choosing to ignore the most common case,
where you don't need to modify the library you're using. That's been
the case for probably 90% of the libraries I've used, beyond bug fixes
(which are covered separately in the licence).

Yes, if you do nothing to the artistic license code, and distribute
as is, then yes, option 4a (a different option than what we've
discussed to date) applies. But, the minute you make the most minute
change to the artistic license code, you run afoul of the other four
options I've discussed-- and at this point your entire project is
contaminated, unless you comply with one of the onerous options we've
discussed.

Not your entire project - just the piece which relates directly to the
package. You effectively create a modified package, distribute that and
make those modifications available, and then use the modified package
in the rest of your program.

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.

Because they hate Microsoft.

Oh you are a card. I certainly don't hate Microsoft. However, some
elements of Microsoft (not all) are very unfriendly towards open source
- which historically has included making some overly critical comments
about some licences, in my view.

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

Yes, you got me on that. Indeed, as you pointed out in your last
thread, the one I'm replying to, if you do nothing to the artistic
license code then you only have to acknowledge it--which is not
onerous at all and quite generous to the non-author user. But,
contrary to what you assert, how many people 'do nothing' to such
artistic license code? I doubt very many, though you could be
right.

Most, actually, in my experience. How much time have you spent working
in industry, experiencing how people use 3rd party libraries? I can
only remember making changes to a couple of the dozens of open source
libraries I've used.

Note that with the artistic licence:

o If these are bug fixes or portability fixes, they don't count as
modifications
o If the interface to the 3rd party code isn't made overtly available,
a separate clause applies and you don't need to worry anyway.

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.

Yeah, and if it's Google it explains your anti-MSFT stance.

Disagreeing with one thing that Microsoft has said doesn't make me
"anti-MSFT". If I'm so anti-Microsoft, why do I spend so much time
writing about C#?

But let's not get personal over this, as you cannot dump on your
employer, and I don't want you to (BTW I am a MSFT shareholder, just
to show my bias).

Your bias was pretty obvious from the moment you said that any critic
of Microsoft can't be trusted. Of course, that was *perhaps* tongue in
cheek - it can be hard to tell.

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.

Admission noted. They've not had problems with certain specific well
tailored licenses. But this artistic license was 'bizarre' if I
recall the news story--that's why it was litigated--not at all like
the tamer Apache, BSD etc licenses.

The problem wasn't with the licence at all - it was with the use of the
licenced code. IIRC, the violator was using the code without
acknowledgement - and that would have violated the Apache licence too.

Thanks for your time. I originally was trying to do a bit of trolling
with this story

Nice to hear you admit that. Please don't troll. It's a waste of
everyone's time. There are better ways to learn.

but in the process actually learned a few things. Namely, if you
don't touch the artistic license code we've discussed and as was
recently litigated, it's not viral, otherwise, it is, and you have to
comply with one of the onerous four options we originally discussed
early on in this thread.

It's not viral anyway.

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

[Ken Foskey]

On Sun, 17 Aug 2008 09:27:05 -0700, raylopez99 wrote:

Yep. See the link you cited: http://www.linux.com/feature/14792 if
this wasn't an issue, why would MSFT even mention it? Clearly it's not
unambiguous.

Today Microsoft accept that there is a license that is there for a
purpose and have released some of their code under a similar license. If
it was as bad as you say then why would Microsoft accept and support the
concept now.

Microsoft has grown up in the last 7 years. In 2001 they were trying to
spread the "Viral" marketing phrase that you are talking about, you
obviously swallowed it. They were, and are, rightly concerned about the
threat that Open Source in general represents to their business model.

You are right to be concerned about licensing and I encourage you to
actually study Copyright and Licensing. http://www.groklaw.net/ is a
great resource to help you in your search for understanding.

Ken

[raylopez99]

On Aug 17, 10:15*am, Jon Skeet [C# MVP] <[e-mail]:

>
I believe the person who *wrote* the licence rather than Microsoft's
interpretation of it.

No, I believe the person who *adjudicates* the license. That would be
the judge.

>

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:

OK, I concede this, but you then, by your own logic, concede these
four options a) - d) *are* relevant and *are* viral for *modified*
code.

Relevant, yes. Viral, no.

BTW, there's no definition of "viral". It's a layperson's term, not a
legal term. If you incorporate a tiny copyrighted code illegally into
your program, you entire program is toast. That's viral. If you
don't believe me, talk to a lawyer. I have been involved in some
litigation as a non-lawyer and from what I've seen, both in practice
and reading online, damages (where 'viral' is the issue) is always
based on the entire code (both infringing code and untainted code).
That's viral. They don't say (as you imply): "since your code only
uses infringing code in 10% of its total, the damages are 10% of the
revenue the copyright infringing product makes a year". They ask for
100% of revenue, not 10%. That's viral. And, depending on how bad
the infringement is, sometimes they get it. Google and read the
famous story: Cadence sues Avant! Corp.

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.

You are correct--but changing the goal posts.

Not at all. I'm just taking in the whole of the licence, as opposed to
just part of it. You were choosing to ignore the most common case,
where you don't need to modify the library you're using. That's been
the case for probably 90% of the libraries I've used, beyond bug fixes
(which are covered separately in the licence).

OK, I concede this point. You have industry experience in this field;
I don't. I did not know that most of the time 'open source' code was
not modified, but used verbatim. Interesting (if true).

Goodbye, I did learn something from this thread, and, if you're
honest, so did you.

RL