Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Copyright notices and license stuff

6 views
Skip to first unread message

Dan Sugalski

unread,
Oct 26, 2002, 3:17:56 PM10/26/02
to perl6-i...@perl.org
Folks,

On Tuesday I'm going to go through and get the copyright notices and
license stuff sorted out. This includes setting everything to be
copyright YAS, and the license info (if any) in the individual files
that are part of the core to get yanked in deference to the global
license.

If anyone objects, this would be the time to make it known. I'll get
your code removed from the repository so it's not an issue. Code in
the icu/ and languages/ directories will not be affected. Just about
everything else will be, at least potentially.

Please note that we're seriously considering moving to either a BSD
or MIT style license for Parrot. (Over, to my great amazement, no
objections whatsoever from the FSF) If you've provided code and
object, this would be a good time to make your objections known. (We
will be contacting everyone who's e-mail address is in a commit
message in the repository before we do this) Note that objection here
won't result in code yanking, so that's OK if it really bothers you.

One thing we will definitely be doing is officially restricting the
scope of the license leakage. Parrot's license will explicitly not
cover generated bytecode, nor will it cover the internal
representation of anyone's source, much in the way that gcc's license
doesn't apply to the object files it generates (and unlike the way
gcc's license does apply to its internal representations of things)
Note that this won't affect the license and rights of other people's
code--if a bytecode file has bytecode that came from GPL'd source
(that was not parrot core), then the GPL would still apply to it. We
can't and certainly don't want to affect other people's source
licenses, just our own.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Dan Sugalski

unread,
Oct 27, 2002, 11:50:13 AM10/27/02
to Nicholas Clark, perl6-i...@perl.org
At 3:16 PM +0000 10/27/02, Nicholas Clark wrote:

>On Sat, Oct 26, 2002 at 03:17:56PM -0400, Dan Sugalski wrote:
>> Please note that we're seriously considering moving to either a BSD
> ??
>
>curious - this is the first I've been aware of this idea, so I wonder who
>the "we" is. Or what the cause for the formal change is?
>
>["formal" because my reading of the artistic licence is that you can do
>pretty much anything with perl5 code providing you don't call it perl, and
>you credit the author. Hence saying the licence is BSD rather than "GPL +
>artistic" makes no pragmatic difference, as best I can tell. Except that
>other people (and other people's legal departments) may have a better idea of
>where they stand with a BSD licence]

I've discussed this with a number of people, and it's been mentioned
on the list before, but I don't know that anyone's paid much
attention to it. The problem with the current scheme is twofold.

1) There is some question as to whether the AL itself has any
force--it's a bit fuzzy, and it may well be that the AL/GPL combo is
legally just the GPL.

2) There are a lot of people who aren't comfortable, for whatever
reason, releasing their code with the GPL anywhere near it. (And yes,
I know it's the same no matter what license is chosen)

#1 has be a bit nervous for legal reasons. AL or GPL is very
different from GPL-only, and I'd really hate to surprise anyone
(especially me) in the future.

#2 has kept us from getting at least a Prolog front end for Parrot,
and may well stop us from getting other code as well, though I know
the same goes if we move to another license.

If we don't move over, then I'm at least tightening things down
enough that our license doesn't leak out, so that someone can
distribute other parrot-based language parsers, libraries, and
modules without our license leaking out to their code. (And yes, I am
of two minds on the core itself, as I'm not thrilled with the
potential for someone making a few internal changes to the core
itself and not passing those changes back to us)

> > One thing we will definitely be doing is officially restricting the
>> scope of the license leakage. Parrot's license will explicitly not
>> cover generated bytecode, nor will it cover the internal
>> representation of anyone's source, much in the way that gcc's license
>> doesn't apply to the object files it generates (and unlike the way
>> gcc's license does apply to its internal representations of things)
>

>What's the significance in the internal representation? (I can't see why it
>matters, but presumably it does matter to someone for some reason important
>to them, otherwise it would never have become significant enough to need this
>explicit clarification.)

This came up a while back in regards to GCC. Someone was working on a
front (or back, I don't recall) end to gcc to dump out the internal
representation of source as XML for some damn thing or other. This
was essentially stopped (don't recall whether it was stopped
outright, or GPL was put on the generated rep, which is close enough
to stopping for most folks) by the GCC folks as they claimed, quite
rightly, that the internal representation was a derived work of their
code as well as the original source, and as such they could put their
license on it too. This doesn't apply to object files that gcc
generates as there's explicit disclaiming of ownership on them in
gcc's license, as there is with pretty much all compilers.

This is also potentially an issue with perl and things like
B::Deparse, though Larry'll never exercise that. I understand why the
gcc folks do it, and that's fine, and I understand why Larry won't,
and that's fine too. I just want it explicit that we do *not*
exercise any license or copyrights on this internal representation,
as I think some really cool things can come of it. Heck, B::Deparse
alone is enough, and I have no doubts there will be other Keen Things
that come about because of it. I want our stand on the
license/copyright issues really clear, though.

James Michael Dupont

unread,
Oct 29, 2002, 8:18:53 AM10/29/02
to perl6-i...@perl.org, Leon Brocard, ni...@unfortu.net, d...@sidhe.org
Dan Wrote,
>>This came up a while back in regards to GCC. Someone was working on a

>>front (or back, I don't recall) end to gcc to dump out the internal
>>representation of source as XML for some damn thing or other.

I am working on something like that, there are 2-3 other similar
projects. I am using the front end tree structures of the gcc to
extract information about software into a new visualization and reverse
engineering tool.

> This
>>was essentially stopped (don't recall whether it was stopped
>>outright, or GPL was put on the generated rep, which is close enough
>>to stopping for most folks) by the GCC folks as they claimed, quite
>>rightly, that the internal representation was a derived work of their

>>code as well as the original source, and as such they could put their

>>license on it too.

I had stopped distribution for a while on my own accord.

It was not stopped by the gcc. I had stopped for a while, out of
respect of the wishes of the gcc group and rms. It now turns out that
they are doing the same themselves.

There is not any real policy or consistency in the actions of the gcc
and fsf group, therefore I will hold back any longer.

The gcc interface project has been offically restarted.
http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html

>> quite
>>rightly, that the internal representation was a derived work of their

>>code as well as the original source, and as such they could put their

>>license on it too.

This is not correct, there is no way to enforce that via the GPL,
which is based on copyright. Look at the dumping of the ASTS into
GraphViz Format.

The only arguments which are pretty weak where that the data structures
are copyrighted, but there is no real case for it. Just lots and lots
of FUD from the gcc developers.

>> This doesn't apply to object files that gcc
>>generates as there's explicit disclaiming of ownership on them in
>>gcc's license, as there is with pretty much all compilers.

This does not apply to any of the input or output files of a GPled
software, only the creative work of a person can be copyrighted.
Mechanical translations are just derived works.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Tim Bunce

unread,
Oct 29, 2002, 4:02:48 PM10/29/02
to James Michael DuPont, perl6-i...@perl.org, Leon Brocard, ni...@unfortu.net, d...@sidhe.org

On Tue, Oct 29, 2002 at 05:18:53AM -0800, James Michael DuPont wrote:
>
> The gcc interface project has been offically restarted.
> http://gcc.gnu.org/ml/gcc/2002-10/msg00806.html

Congratulations. I think it's an important project.

Tim.

0 new messages