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

I'm not an authority in this area, but it seems to me that now if you
read somebody else's code and copy it, and that code has a 'artistic
license' in it (whether or not you agree to it or even read it), your
commercial code has to be released to the public domain (see point a)
below). Or, you have to 'rework' the code so it's not the same as
before. Actually this last option--option "c)" below--the 'reworking'
of the code--is less harsh than I thought--it's not a clean room
rework (in that you have to show that you've never seen the code
before), just a rework after the fact. So make sure to always rework
any code with an artistic license in it, so that only the ideas
therein are used and not the form / format of the ideas. Interesting
in that the Artistic License option "c)" requires you to write a man
page (!) to justify your reworking of the code--who has time for that?
I guess, since no time period is stated, you can write the man page
when you get sued by the copyright owner?!

See yesterday's court decision in the USA on artistic licenses
(follows the Wiki entry below).

RL

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.


-

Open-source pact subject to copyrights law - court

NEW YORK, Aug 14, 2008 (Reuters) - A U.S. federal appeals court has
ruled that the holder of a copyright to a computer programming code
made available for free public download can enforce an "open-source"
copyright license to control future use of the work.

The ruling on Wednesday by the U.S. Court of Appeals for the Federal
Circuit is seen as having important ramifications for the licensing of
open-source software. Open-source proponents had argued that
individuals who do not adhere to the conditions of an open-source
license should be subject to copyright infringement claims.

The appeals court reversed a lower court ruling that had denied a
preliminary injunction to plaintiff Robert Jacobsen, a hobbyist who
made software used for model trains available through free downloads.

Jacobsen had brought copyright infringement claims against developers
of commercial software products, contending they did not follow terms
of the software's license. The lower court had ruled that copyright
claims did not apply, but that Jacobsen could pursue breach of
contract claims.

The distinction is important because the potential remedies under
federal copyright law are much stronger than under contract law, said
Jacobsen's lawyer, Victoria Hall. She called the appeals court
decision "a fantastic ruling."

It "shows that open-source groups can protect their code under
copyright laws, and this is a ruling that other open-source groups can
use," she said on Thursday.

An attorney representing defendants Matthew Katzer and Katzer's
company was not available to comment.

Open-source software makers share the source code of their computer
programs, allowing users to help change or improve their software and
redistribute it. It is a collaborative approach to software
development, unlike the proprietary approach by companies like
Microsoft Corp (MSFT.O: Quote, Profile, Research, Stock Buzz), which
generally keep software code secret.

Jacobsen had accused Katzer of copying materials from Jacobsen's
website and incorporating them into a software package without
following the terms of an open-source agreement called the Artistic
License

The lower court, the U.S. District Court for the Northern District of
California, had interpreted the Artistic License to permit a user to
"modify the material in any way." But the appeals court said
conditions in the Artistic License were vital to enable the copyright
holder to retain the ability to benefit from the work of subsequent
users.

The appeals court sent the case back to the district court for further
proceedings to review Jacobsen's request for a preliminary injunction
again. (Reporting by Martha Graybow)

raylopez99 <(E-Mail Removed)> wrote:
> Be afraid, if you code for money, with this recent ruling on Artistic
> Licenses.

No, be afraid if you code for money and try to use other people's code
without looking at or abiding by the licences for that code.

> I'm not an authority in this area, but it seems to me that now if you
> read somebody else's code and copy it, and that code has a 'artistic
> license' in it (whether or not you agree to it or even read it)

If you start copying code without even checking its licence, you
deserve all you get.

> your commercial code has to be released to the public domain (see point a)
> below).

Nonsense. You just need to abide by the licence, which will usually
mean including a copy of the copyright notice etc somewhere in your
distributable.

Plenty of people use open source code in commercial products and get by
just fine, abiding by the licence. Of course, there's another
alternative: if you don't want to abide by the licence, don't use the
code!

Heck, just today I received a mail from someone explaining how he
planned to do that with part of MiscUtil and checking it was okay -
which of course it was.

> So make sure to always rework any code with an artistic license in
> it, so that only the ideas therein are used and not the form / format
> of the ideas.

Or - and you may think this idea is a bit quirky - abide by the terms
of the licence! What a novel concept!

> Interesting in that the Artistic License option "c)" requires you to
> write a man page (!) to justify your reworking of the code--who has
> time for that?

So pick one of the alternative options listed in the licence.

--
Jon Skeet - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

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

On Aug 14, 2:58*pm, Ken Foskey <rmove.fos...@optushome.com.au> wrote:

> 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

On Aug 14, 12:00*pm, Jon Skeet [C# MVP] <sk...@pobox.com> wrote:

> Or - and you may think this idea is a bit quirky - abide by the terms
> of the licence! What a novel concept!
>

You clearly have never read the license, whose salient points I posted
in the OP.


> > Interesting in that the Artistic License option "c)" requires you to
> > write a man page (!) to justify your reworking of the code--who has
> > time for that?
>
> So pick one of the alternative options listed in the licence.


But that was one of the alternatives. And then people wonder how
employers get sued over copyright infringement, with employees as
sharp as the ones in this group.

RL

On Aug 15, 10:31*am, raylopez99 <raylope...@yahoo.com> wrote:
> > Or - and you may think this idea is a bit quirky - abide by the terms
> > of the licence! What a novel concept!
>
> You clearly have never read the license, whose salient points I posted
> in the OP.

Yes, I did. (Both first and second version.) Your idea of "the salient
points" certainly isn't the same as mine.

> > > Interesting in that the Artistic License option "c)" requires you to
> > > write a man page (!) to justify your reworking of the code--who has
> > > time for that?
>
> > So pick one of the alternative options listed in the licence.
>
> But that was one of the alternatives.

Yes, but not the only one. That's my point. Option c requires you to
write documentation, but if you don't want to do that you should look
at the other options.

>*And then people wonder how employers get sued over copyright
> infringement, with employees as sharp as the ones in this group.

What, because we think it's a good idea to read the licence associated
with code before using it, and because we understand that "do at least
one of" isn't the same as "do all of"?

Jon

On Aug 15, 10:30*am, raylopez99 <raylope...@yahoo.com> wrote:
> On Aug 14, 2:58*pm, Ken Foskey <rmove.fos...@optushome.com.au> wrote:
>
> > 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

On Aug 15, 2:48*am, "Jon Skeet [C# MVP]" <sk...@pobox.com> wrote:

> What, because we think it's a good idea to read the licence associated
> with code before using it, and because we understand that "do at least
> one of" isn't the same as "do all of"?
>


But the other options Jon are capitulation to the copyright owner.
Just look at them. Option "C" is the only reasonable option.

Option A: make your stuff free.
Option B: use the code in-house only
Option C: work through and make your own modifications (most
reasonable) and document your workaround
Option D: vague, but basically cut a deal with the original author of
the code you're copying

RL

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.

On Aug 15, 3:03*am, "Jon Skeet [C# MVP]" <sk...@pobox.com> wrote:

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

On Aug 15, 2:47*pm, raylopez99 <raylope...@yahoo.com> wrote:
> > What, because we think it's a good idea to read the licence associated
> > with code before using it, and because we understand that "do at least
> > one of" isn't the same as "do all of"?
>
> But the other options Jon are capitulation to the copyright owner.
> Just look at them. Option "C" is the only reasonable option.
>
> Option A: *make your stuff free.
> Option B: use the code in-house only
> Option C: work through and make your own modifications (most
> reasonable) and document your workaround
> Option D: vague, but basically cut a deal with the original author of
> the code you're copying

A) Only the modifications. Not your whole codebase.
B) Widely applicable anyway
C) Not unreasonable
D) Not particularly vague, just discretionary - happened to me a while
ago, when someone wanted to use some of my code without attribution.
They paid me for a commercial non-exclusive licence, and we were both
happy.

The important thing is that this is only talking about modifications
you make to the package. Most uses of third party code just use it
without modification, in my experience. If you *do* modify the code,
it's only the modifications that you need to open up.

What's so unreasonable about any of that?

Jon