[conspire] (forw) Re: http://linuxmafia.com/faq/Apps/vcs.html

[Rick Moen]

----- Forwarded message from Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> -----

Date: Thu, 07 Jul 2011 15:34:53 +0200
From: Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
To: rick at linuxmafia.com
Subject: Re: http://linuxmafia.com/faq/Apps/vcs.html

Rick Moen <rick at linuxmafia.com> wrote:

> > -	The currently maintained SCCS version that is seen on 
> > 	http://sccs.berlios.de is based on the Sun source of SCCS and Sun 
> > 	introduced support for binary files in late 1986, so this version of
> > 	SCCS offers support for binary files since almost 25 years.
>
> Glad to hear it, Joerg.  I'm well aware of your heroic role in writing
> and rejuvenating code on Solaris and (with some amount of prejudice,
> which is entirely your prerogative) for other Unixes.  Also, thank you
> very much for your creation and support of BerliOS.

Well, I develop on Solaris as it has the best debug tools and as it gives the 
best grant for creating code with few portability issues. If you did look at 
the code, you will see, that I even added workarounds for the baroque Linux 
stdio implemenation that causes problems while trying to achieve performance 
and I even support VMS which is rare these days.

... well I see you corrected the statement related to binary support on your 
page

BTW: You should note that RCS and even more SVN have a confusing command line 
interface when you are used to use SCCS.

And you seem to have understood me wrong with respect to atomic operations.
SCCS always was atomic with respect to files. The history for a single file 
either exists in a consistent old state or it exists in the consistent new 
state. I however plan to make SCCS atomic with repect to projects that are 
made from many files - this is something completely different. This needs 
global locks on a project level and this needs the ability to unroll thousands
of files to the previus state in case one of many actions fails.


> Though you might be mislead by my domain name into thinking the
> contrary, I am quite fond of Solaris (though you'll forgive me for smiling
> more on Illumos / Openindiana and Nexenta, and yes I am also aware of
> SchilliX).  I'm also a fan of the CDDL licence as an improvement on MPL,
> and highly suitable for some purposes, especially where it is desirable
> to plan for interoperation on a code module level with proprietary code.

Well I like the CDDL because it is a nice compromise between BSD license and 
GPL and as the GPL contains claims that cannot be enforced in court, the 
protection from the CDDL is not worse than the protection you get from the GPL,
but do you really like to discuss licenses?

BTW: I am looking for people who like to help with Schillix-ON and Schillix.
Do you know someone who might be interested?

> I'm leery of those who assert there's no licence conflict between CDDL
> and GPL -- and I have not forgotten the cdrtools fiasco and your
> extremely non-constructive behaviour when challenged -- but it's not
> 2006 any more, so let's move past that, shall we?

Nobody claims that there is no license conflict between CDDL and GPL, the GPL 
however would be unusable if it did not permit to link a GPLd program against 
libraries under any arbitrary license. This is something I have discussed 
and influenced in 1987 already, after we detected that early GCC versions used 
a license that cannot be used to publish resulting binaries at all. You cannot 
mix CDDL and GPL code fragments into a single "work", this however is 
something that does not happen in any known project. Existing GPL projects 
link against non-GPL libraries that are independend "works" and this just 
creates a permitted collective work.

In general, I have been the victim os a social attack from Debian and even 
though Debian repeatedly send pointless claims, I have been very constructive
with making proposals that could have been accepted even by people with the 
most unusual interpretation of the GPL (this has been confirmed by Till Jaeger 
- you may know him, he is the lawyer who supports Harald Welte). My proposals 
have been ignored by Debian. If you like to know about the main idea behind the 
proposals: Even though the GPL does not mention linking at all and thus makes 
no difference between static and dynamic linking, Jaeger confirmed that 
dynamically linking a GPL program gainst a library under an arbitrary license 
is something that is permitted even under the strange GPL interpretation from 
the FSF that is in conflict with US Copyright law title 17 parapraph 106.

On March 6th 2009 Simon Phipps (at that time Sun Microsystems OSS Evangelist, 
now part of the OpenSource.org board of directors) repeated my proposal and 
Debian claimed to accept that proposal and promised to include the original 
cdrtools as soon as possible (they said 6 weeks) into their distro. Debian 
however continued to act anti-social and just did nothing. A year later they
made it obvious that they will not redeem their promise. I am now tired of 
this anti-social act from Debian and fortunately, there are binary cdrtools
packages for all major Linux distros that do not include cdrtools in their 
packages - made by disappoited users.

>
> > -	The SCCS source code is 100% CDDL, so it may be a good idea, to remove 
> > 	the GPL/LGPL entries from the SCCS section on your page.
>
> I am unlikely to summarily remove the material concerning GPL/LGPL code
> that preceded yours.  What I _might_ do is research the change history
> of your CDDL codebase, to see if your CDDL-covered codebase mentioned

How do you come to the strange conclusion that there might be GPL code inside?

> starting in
> https://lists.berlios.de/pipermail/sccs-devel/2011-May/000000.html

This explains that the code is based on the original AT&T code. I am not aware 
that AT&T did ever publish code under GPL.

The code has been put under CDDL by the current Copyright owner (which appears
to be Sun) - it has not been put under a different license.

In contrary to the false claim you recently introduced, there _never_ has been 
GPL code in that project and if you carefully read 
https://lists.berlios.de/pipermail/sccs-devel/2011-May/000000.html you will not 
find the term GPL anywhere in the text.

As there never has been GPLd code in SCCS, nothing needs to be converted.


> appears to be a derivative work (as that term is used in copyright law)
> of someone else's work, and to determine whether you have created yet
> another licence conflict by doing so.

Well I am afraid that you might confuse me with the FSF that is known for 
repeatedly creating license conflicts by taking other people's code and by 
publishing such code claimed to be under GPL even though that code never has 
been published under GPL. 

The FSF unfortunately even ignores attempts to fix the problems they introduced 
and for this reason, it took me 10 years to fix a case where the FSF did 
illegally publish code form Heiko Eißfeld - the author of cdda2wav. To be able
to finally succeed, I needed the help from SuSE.

The fixed project is "vcdimager", the project "libcdio" still is in a license 
conflict and nobody at the FSF seems to be interested to fix the problem.


> Let me be very blunt, Joerg:  You have a history of doing that.  Nobody
> with a competent understanding of software law has ever agreed with your
> past interpretations of licence compatibility issues under copyright
> law, and, in particular, I most certainly do not.  

I am sorry to see that you are a victim of wrong and anti-social claims from 
Debian. I do not introduce new license interpretations but I am in frequent 
contact with specialized lawyers and I repeat statements from these lawyers.
One of these lawyers is sitting a few offices from me in our institute....
he even confirmed that I did not missinterpret statements from him or other 
lawyers. So I am well aligned with typical legal interpretations. We all know
that this cannot be said about Debian :-(

My impression is that because I am much more careful with licensing issues, I 
am attacked by some people. It is obvious that some Linux distributors are not 
interested in being forced to check their distro for legality and rather like 
to continue the way they currently do things. This includes e.g. suspect code 
combinations (e.g. GNOME calls libcdio where LGPL code calls GPLd code which is 
generally condifered to be impossible).

> Therefore, it is a relevant question whether your revised SCCS codebase
> has a clear and unproblematic copyright status.  _If_ I have sufficient
> time and interest, I might start there.  I also most certainly will
> amend my pages to attempt to mention your work -- and do so in a
> charitable and encouraging spirit.

I am sorry to see such pointless claims from you. In contrary to many people, I 
am very careful with license issues. 

Unless I have been misslead by a contributor (something that e.g. happened with
cdda2wav - where the research I made after Debian started their attacks 
unveiled that somebody contributed code under GPL that has not been put under 
GPL by its author) I can give a much better license review for the code I am 
using than any other OSS project I am aware of.

Given the fact that SCCS has been originally published under CDDL by Sun, do 
you really like to claim that the Sun legal department did something really 
wrong and tried to hide GPL code?


> I should also be blunt about this:  As of right now, July 6, 2011, I
> _personally_ just cannot bring myself to care very much about SCCS,
> though I am honestly delighted that you are working on it, and hope to
> see remarkable things emerge from your efforts in the future.  My
> attitude may be short-sighted.  I have been known to change my mind, and
> hope that happens.

Well, if you continue to publish false claims about the license  used by SCCS
that even seem to be an invention from you (nobody besides you did ever claim
that SCCS of parts if it is under GPL), you discredit yourself. Is this really 
what you like to do?

> I'm not going to argue with you about opinions reflected in 
> http://linuxmafia.com/faq/Apps/vcs.html .  Some of those are from my own
> past experience; some is a paraphrase of people whose views I respected
> and trusted at the time.  I frankly lack the time and interest to even
> review such matters, right now.

As mentioned above, your statements about the license in use for SCCS are 
pointless and false. Your claims are not correct for the past and they 
are not correct for current version, please correct them as soon as possible.

> If it'll help, I _do_ take your own opinions seriously, though, so I 
> will ponder them and you might find my views changing.  If not, you're 
> welcome to consider me unenlightened or ignorant, and you might be
> right.

I can understand that a creator of a web site has own interpretations about 
things that can be interpreted in different ways. It however does not help 
at all if you publish claims about licensing that are false and that seem to 
have been invented by you. Plase follow the facts that can be verified by 
looking into the project.

> Anyway, I very much thank you for taking on the job of further
> developing SCCS, and I will eagerly await your new versions.

SCCS can create annotated text (with date, SID and programmer) on a line by  
line base at no extra costs and SCCS would allow to implement a time slider 
that  is able to scroll through revisions with aprox. 1000 updates per second 
if the file is smaller than aprox. 50 kB. This is something you cannot get 
with git or hg. 
 
I was close before getting SCCS to become OSS in May 2001 after a long  
discussion with SCO - that did become void with Caldera buying SCO two weeks  
before the source code was expected to be given out. It took some more years  
to do the same with Sun. I will of course continue to work on SCCS. 

The enhancements I did for release 5.1 allow to verify that SCCS is extremely 
fast and that SCCS will have no problem to compete with other systems. Entring 
the OpenSolaris sources did take 1:20 with hg and 1:40 with git under the same 
constraints where SCCS needed 17 seconds. If I add gzip -4 compression, this 
takes another 15 seconds and it will result in 110 MB of compressed history 
files. Hg and Git both need aprox. 300 MB of space for the initial OpenSolaris
check-in. If I add some time for creating a ChangeSet file, I expect to be ready 
in aprox. 40 seconds. This is very promising. I already have a prototype for a 
network protocol and for a file tree transfer protoocol that is as fast as star.

I thank you for adding some of my statements to your site and I am looking 
forward to a corrected license statement.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

----- End forwarded message -----
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Thu, 7 Jul 2011 10:49:57 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
Subject: Re: http://linuxmafia.com/faq/Apps/vcs.html
Organization: If you lived here, you'd be $HOME already.

Quoting Joerg Schilling (Joerg.Schilling at fokus.fraunhofer.de):

> ... well I see you corrected the statement related to binary support on your 
> page

I aim towards accuracy within distinct limits set by available time and
interest.

> And you seem to have understood me wrong with respect to atomic operations.

Entirely possible, but see note about available time and interest.
Also:

> SCCS always was atomic with respect to files. The history for a single file 
> either exists in a consistent old state or it exists in the consistent new 
> state. I however plan to make SCCS atomic with repect to projects that are 
> made from many files - this is something completely different. 

The latter is really what is generally meant by atomic operations for
VCS check-ins.

> BTW: I am looking for people who like to help with Schillix-ON and Schillix.
> Do you know someone who might be interested?

Offhand, I don't.  If I hear, I will certainly pass the idea along.

> Nobody claims that there is no license conflict between CDDL and GPL, the GPL 
> however would be unusable if it did not permit to link a GPLd program against 
> libraries under any arbitrary license. 

Indeed, 'linking' is not per se any sort of issue.  The boundaries of
derivative works, within the meaning of that term in copyright law, are
the issue.

> In general, I have been the victim os a social attack from Debian....

Who somehow cruelly and inaccurately mislead pretty much everyone,
including Jon Corbet, who pointed out that the binary build is a
derivative work of its build tools?  I really don't think so.  Jon was
correct.


> How do you come to the strange conclusion that there might be GPL code
> inside?

I really cannot recall.  This is not an encyclopaedia nor a doctoral
thesis, Joerg.  It's just a Web page with information I've found in a
large number of places and done my best to make accurate within distinct
limits set by available time and interest.

I _have_ added this note:

  2011-07-07 addendum:  Joerg asserts that the codebase never had GPL or
  LGPL components.  As it was origianlly written in SNOBOL by Marc J.
  Rochkind for a 1970s IBM System/370 mainframe running OS/360's MVT
  variant, and then rewritten by Rochkind in C for AT&ampT PWB/UNIX and
  carried forward into various AT&ampT System III and System V proprietary
  Unix releases, that is distinctly possible.  I currently lack the time
  and interest to further research SCCS licensing history.

I have, for now, exhausted my time and interest available for SCCS.  If
my pages do not meet your needs, you are cordially invited to create
your own Web pages.  If you wish, I can recommend some open source
software on which you can offer them to the public.  ;->


> I thank you for adding some of my statements to your site and I am looking 
> forward to a corrected license statement.

You are most welcome, and thank you for taking the trouble to write.


----- End forwarded message -----