Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[metvas]

Yes I know, however we are fully compliant with all other aspects of GPL so kind of OK "I think", for now.
Regards
Darrell

[easuter]

Yes I know, however we are fully compliant with all other aspects of GPL so kind of OK "I think", for now.

The main and probably most important part of the GPL is how source code should (and must) get distributed...
Well, yeah, "for now" we are...but if this goes ahead then very soon we probably won't be OK.

Sorry if I'm nitpicking here, but IMHO its a bit short sighted to not distribute the source code when a move like this will most likely bring a lot more attention from users (good) *and* from the FSF (possibly problematic if things aren't in order).

It would be a shame to release a distro and then have to take it down until we are compliant. This would then also be a problem because:

a) if the distro isn't built with distribution of the source in mind, then one would have to go back and try to figure out how all the packages were made in order to include build scripts, which chews up more time still.

b) we'll have some very disappointed customers if the distro is taken down to be made compliant. This wouldn't be so much of a problem if everything were GPLv3 since this license gives a grace time to correct violations without having the license revoked, but the GPLv2 isn't as accommodating in this aspect.

[metvas]

Speculation on my part. But I would guess a lot of sites are not putting up their source code due to manpower constraints. We comply even to the point of offering our deluxe version CD 1 ( not including the extra's) CD as a free download. How compliant is that. FSF does live in the real world. So with that I trust we do not have any difficulties with FSF. It would be a shame to have our very first contact with FSF to be one of controversy. I do not feel we are flying under the radar on this issue. My opinion anyway.
Regards
Darrell

[bigpaws]

The GPL only requires that source code be made available by either including it
or that a reference to the original work be made. At least that is what I have gotten
from reading the GPL V2. I have not fully read GPL V3 as of yet.

Bigpaws

[easuter]

bigpaws: yes, but it you just include a tarball on its own with the original sources, that is still pretty useless because nobody knows how the package for that particular piece of software was built. Take Slackware an an example: why would Patrick Volkerding bother adding the the SlackBuilds?...because if he doesn't, then you can't make an exact copy of the package when building from source!

I can't remember where I saw an article abut this kind of thing, but Mepis is getting slammed for this very reason, and they are probably even more undermanned than we are...but what choice do they have but to comply!

metvas: yes, indeed, providing the source code is not as quick as just the binary packages, but its really not that much more work if scripts are used and if the packages are built with this objective in mind, ie: prepare a source directory, write a description, use a template build script if you want to speed things up, and run it. Sometimes things need tweaking, but thats nothing extraordinary.
Take exeterdad's Firefox language pack builder as an example:

http://vectorlinux.osuosl.org/veclinux-5.8/source/testing/net/firefox-lang/

That script generates...a ton of packages which would have been a lot harder to do by hand, especially if things need to be changed in those packages at a later stage.

Well, I've made my point many times over so I'm gonna shut up now.

[vector]

I am gonna jump in here just to (hopefully) clariiy the source code controversy. We announce very clearly that we are slackware based that means we use the same source as slack for basic system. We also use for the most part the same build scripts with a change in cflags. The init and scripts we use to to make VL different are available as packages but since they are scripts there is no source code involved. If everyone thinks that yet again copying the slack source tree to our repo will make a gpl2 god happy then ill do it but it seems a waste....and repetitive. The whole gpl thing was aimed at individual  program developers not a distro with the goal of making the code better. When we publish in house coded programs like our gui installer and the gui-packager of course we will supply all but to take up yet another public servers space with redundant packages makes no sense.
Just my humble opinion.
cheers,
Vec

[saulgoode]

I think Mepis ran afoul of the FSF because they had FTP repositories containing GPLed software and they were charging a fee for access. If I interpret the GPL2 correctly, these "for-pay" repos would be considered commercial distribution of the packages -- and thus are not afforded the non-commercial exception (GPL2: Section 3-c) which would have allowed Mepis to just direct users to the Debian FTP repos for the source.

I could be wrong but I think that since Vector's repos are non-commercial, directing users to the original Slackware source fulfills the requirement of 3-c, "Accompany it with the information you received as to the offer to distribute corresponding source code". If such is not the case then how is a site such as LinuxPackages.net or Slacky.eu exempted from providing source?

[exeterdad]

I wish I could find the article that stated that distros based on other distros must supply the base sources/scripts as well.  Apparently this is a common misunderstanding acrossed the board.

[The Headacher]

You mean this one? 

[exeterdad]

You mean this one? 

That is thee one.  If it is accurate, we should rethink some things.

[uelsk8s]

We have to make available source code for every package we distribute. Even the slackware packages.
  This does not mean we have to have it on the server only that if someone requests it that we make it available to them.
    What that means is if I make a request to VL for the source code to 5,8 VL must supply me either a cd or a repo with all the source and build instructions for every package that came with 5.8
    And VL has to do this for 3 years after 5.8 was released. VL can charge me for this source.
   For slackware packages this will be very easy for us, we can just copy the SL source and redistribute it.
   For the other packages that were submitted this becomes much harder we must track down the source and figure out how the package was built.

Because of this I feel we need to setup and enforce a new rule for anyone submitting packages for us to redistribute.
 All packages submitted must be accompanied by a source dir that includes source tarball build instructions or buildscript, and any patches used in making the package.
 Also if you have to add a .desktop file and an icon, that should go to the source dir. And the description-pak

There are source trees at http://www.slacky.eu/repository/slackware-11.0/ and at any slackware mirror. these provide excellent resources for package builders.
You can copy the source dir and with a few slight modifications have a VL package and buildscript.
here are a couple good examples of what should be in our source dirs http://www.slacky.eu/repository/slackware-11.0/games/flightgear/0.9.10/src  and  http://vectorlinux.osuosl.org/veclinux-5.9/source/n/dhcp/

Uelsk8s

[exeterdad]

Because of this I feel we need to setup and enforce a new rule for anyone submitting packages for us to redistribute.

I think you're absolutely right.  Call me paranoid, but I fear someone pulling the plug on us.  And yes, if rules are created, package submission probably will be slower than building, checkinstall, upload.  But not only will we be covering our butts, but it will help us to build packages if/when a package version changes and the submitter is not available to build a new version.  Honestly, it's really quite hard to determine what a package includes or does not include.  Especially for the packages that other packages depend on.  With a slackbuild, vbuild or a well written text file (for checkinstall packages) with all steps taken to build, shuffle/modify, include files, things would be so much better.

I have high hopes that Moe's utility will be able to replace the checkinstall builds.  So the non scripting packagers can easily build quality packages and still be able to submit the recipe they used to create the package.

[metvas]

The "KEY WORD", here is ON DEMAND. In almost a decade I personally have never had a request. So for the interm while we get this together, if a request be made we will get it together for the requestor. No need to rush in to complete this. Also we do not have to have all the tags identified we just point the rerquestor to the latest tag. ie SoHo v5.8 RC1, RC2 etc. do not have to be logged simply the latest tag.
Should we wish to we could say our fee is $590.00 or $920.00 as no scheduled fee is identified.
I agree with Uel on the forming of a plan for the future releases. also I personally cannot see how we could be asked to provide all the information for lets say VL 5.0 it would be an impossible task to undertake.
Regards
Darrell

[metvas]

BTW, we are NOT reqired to provide our build environment nor our test environment..
Darrell

[metvas]

One more comment on this issue then I am done with it. The Telecom companies running Unix/Linux systems require a 6 year exact rollback for every package. For that they pay high 6 figure $$ for that service. So from that we are cannot be required to rollback. If we were required to we would legally be able to charge the same sum of $$ as it is the same service
Regards
Darrell