launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Hi Keith.

Thank you for this detailed explanation of the issues. I am including
your reply to the public launchpad developer list because this is an
excellent example of licensing problems that projects face.

Launchpad has projects in a similar situation. In most cases, the code
that is not free is hosted off site. The project page or series page
notes that there are licensing issue and that some content cannot be
included in branches uploaded to launchpad. the license of the project
do not mention the problem license since it is not in Launchpad. The
project polices itself to ensure it is compliant with Launchpad's rules
and the rules of the proprietary license. All contributor branches are
reviewed before they are merged into the project's branches.

I think we have one project that purchased a commercial license to so
that it could upload the proprietary code. I do not think this is what
you want to do since you know that the base project will be free one
day.

I will update the question you asked at
<https://answers.launchpad.net/launchpad-registry/+question/101837>
to instruct an admin to rename /squeak to /squeak-proprietary, and
rename your project squeak.

If you choose to restrict your project to free code only, remove the
squeak license from the license-info field and deselect the Other/Open
source check box (Change details link on the project page).

On Mon, 2010-02-22 at 15:23 +0000, keith wrote:
> Hi Curtis,
> 
> 
> The sqk (squeak intended) project is for developing code that is NEW
> code that loads on top of Squeak. Squeak developers tend to use the
> MIT licence had have been doing so for years.
> 
> 
> One does this by defining either totally NEW code, or by exporting a
> slice of code from the release image to modify. The exported code will
> only be slices of relicenced code which is under Apache 2 and APSL,
> (because we apparently cant use the code for which contributors have
> not been tracked down or have died). Each individual method has its
> authorship attribution included, and each individual contributor since
> 1996 has been tracked down, nailed to the wall and forced to sign in
> blood, a legal declaration that they approve the relicensing of their
> code under Apache2 & APSL.
> 
> 
> Following discussions on irc #launchpad yesterday the export tools I
> am using to create packages and slices now define a licence explicitly
> for each export... Have a look at 
> 
> 
> lp:~keithy/cuis/testing
> 
> 
> And you will see that some totally new files are licensed (appended to
> files) as pure MIT.
> 
> 
> Some totally new files are licensed MIT with an additional "Be nice
> and please share" request. 
> 
> 
> Some files are noted to be exports of older code, with modifications.
> The modifications are licenced MIT, but there is also included
> a copyright attribution showing that the history being modified may
> include apple (etc) code.  The code from apple and other contributors
> was originally under Squeak_L and has been relicenced under
> APSL/Apache2 (as explained above), and is now being relicenced to MIT
> under the rules available in Apache2.
> 
> 
> In conclusion EVERY file in the sqk repo will have an explicit
> licence, and copyright attribution and to avoid discussions like this,
> they will all be OSI approved licences.
> 
> 
> However these files build on top of a released image, and while we
> wait for Squeak4.0 which has the offending code (less than 0.5%)
> removed. It would be nice if we could include an image to be used as a
> starting point for builds. This would be according to your rules
> unacceptable. It would also be helpful to include historical images
> for data mining purposes to see the full history if necessary. Under
> your rules this would not be allowed and this is where I think you
> should consider asking you to change the rules. 
> 
> 
> All of this "OSI approved" stuff came along LONG AFTER the Squeak_L
> licence was penned, and at the time is was clearly penned in order to
> be "as open as possible". In fact it was originally intended to allow
> the release team to leave apple and carry on using their ideas in
> other commercial contexts free from problems. This was far far more
> open in practical terms than GPL for example, and it was pioneering
> stuff at the time. The two clauses you mention were merely standard
> legal blurb at the time, and reflected the attitude that was prevalent
> in the days prior to the current enlightenment, of specialist OSS
> lawyers. At the time no one cared, it was open as open could be and
> that was good enough.
> 
> 
> Therefore it was IMO extremely disingenuous for the OSS community to
> turn its back on and cause problems in retrospect for what was already
> an existing thriving open source community that has been going in
> spirit since 1980 and before, when the entire design of Smalltalk was
> published publicly in the blue book and code was routinely shared in
> the manchester goodies archive even back to the 70s.
> 
> 
> Squeak was released in 1996 on the understanding that it was open to
> the metal for anyone to do anything with, and people have done so for
> 14 years without so much as a iota of trouble legally. I was at the
> original announcement at the London Apple developers conference. If
> the developers of smalltalk who are the exact same people who
> organised releasing Squeak under Squeak_L in the first place, had any
> intention of keeping anything proprietary you would probably still be
> using Dos 3. Since it was that very same team who showed Steve Jobs, a
> windowed interface with icons and a mouse and didn't stop them copying
> it for the Macintosh.
> 
> 
> I personally hate licensing issues (and braincells have died while
> writing this email), because they have never effected me, nor any
> member in the history of squeak has ever even in the slightest bit
> concerned about it. This was one reason for using squeak in the first
> place, because it does actually have a free licence virtually from its
> inception (1.1). Freer in practical terms than Java did when it was
> released and freer than it is now. It is a shock to me to be
> artificially constrained by these licence hangups and political
> squabbles which are foisted upon us by the unclean masses of
> "commercial developers gone nice" like yourself at Canonical, the
> "here is our software as oss if you want to fix it for us, or
> commercial if you want us to fix it for you" brigade. that the oss
> community is made up of and is so suspicious of. In contrast the
> Squeak community and technology was founded as a non-commercial
> venture with no commercial interests in the first place, when Apple
> said "We want this to be for you to play with and use even the VM is
> open and the code is readable, being written in itself"
> 
> 
> As you can probably tell I am inclined to react against the any
> discussion of licencing out of resentment at the appalling treatment
> the squeak community has received in recent years by the OSI etc.
> 
> 
> So in conclusion, all code I that will be put up in the sqk/squeak
> repository is for inclusion in release builds of future versions of
> the squeak kernel, the source is explicitly licenced, and the
> licensing and authorship of every method is attributed (and in theory
> is traceable for its entire history).
> 
> 
> Secondly it would be practically useful to be able to include
> historical Squeak_L stuff if you were "feeling nice about it"
> 
> 
> thanks in advance
> 
> 
> Keith Hodges
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part