David Howe wrote:
> It couldn't be "taken over" by anyone else without cash changing
> hands. It's a corporate asset of VA Linux Systems, Inc. -- the Inc.
> is the important part there.
I thought SF was open source?
In which case, only the physical hardware (the servers) could be considered
an asset - the server software being Open Source and the data belonging to
the users.......
In any case, it is really the servers that makes SF a major resource -
almost any project/source management system would have done...
Er, last I checked, making something open source didn't negate one's
ownership or rights to it. It simply means that you have granted certain
specific licenses or rights to others (depending on just which license
you use), generally including non-revokeable permissions to make use of,
redistribute, compile, and modify the code. It doesn't mean you own any
modifications, but it also doesn't mean anyone else owns your code; it
is still an asset.
More than one nominally open-source project has switched to a commercial
codebase by changing it's licensing terms for a new release, and allowing
people to do whatever they want (including forking a different branch)
from the last public code release under open license. One example familiar
to most of those here would be GateD.
So yes, the actual software that drives SF would probably be considered an
asset. It's just an asset with certain license grants for the current
version. As always, IANAL, consult professional counsel if you're
considering what this might mean to your business, etc etc.
Er, last I checked, making something open source didn't negate one's
ownership or rights to it. It simply means that you have granted certain
specific licenses or rights to others (depending on just which license
you use), generally including non-revokeable permissions to make use of,
redistribute, compile, and modify the code. It doesn't mean you own any
modifications, but it also doesn't mean anyone else owns your code; it
is still an asset.
True - but one that the entire world already has a non-revokable licence to
use; I believe VA are selling integrated install and support packages, which
really only have value if there is a support organisation behind them (ie -
if VA goes under, many of them may in fact be creditors for a percentage of
the original support contract value) So the auditors would be left with an
"asset" that anyone can use for free (they can also pay for it, but that
isn't likely) a big database of data they don't own (the projects) and a
number of physical servers that contain that data - they *may* get away with
either selling continued use of the servers, or if they get really nasty,
try to sell access to the current data (most maintainers would have their
copies of the tree held locally anyhow - rebuilding it on a new server would
probably take
hours at most).
More than one nominally open-source project has switched to a commercial
codebase by changing it's licensing terms for a new release, and allowing
people to do whatever they want (including forking a different branch)
from the last public code release under open license. One example familiar
to most of those here would be GateD.
indeed - or SSH (commercial SSH and OpenSSH forked when SSH went commercial)
The problem would be if there are any major patches contributed by an
external programmer - all such patches must of course be replaced with
patches written by company programmers (without looking at the original
patch) unless they have a non-standard licence (like the NS or Sun ones)
I'm presuming we're talking about BSD-style licenses here - with the GPL,
AFAIK, the code cannot be "closed" once it's open, as any derivitive works
must also be released under the GPL.
-C
I would depend greatly upon the SF terms.
For example, if the SF terms include granting SF "a license to use, redistribute under SF's choice of license, etc.", then SF could fork and close even a GPL'ed product because the license THEY received it under (the theoretical SF TOS) allow them to do so.
Again, I haven't sifted over the SF terms, but such a thing is definitely conceivable.
D
I'm presuming we're talking about BSD-style licenses here - with the GPL,
AFAIK, the code cannot be "closed" once it's open, as any derivitive works
must also be released under the GPL.
Not always - the original author always has the right to parallel licence
the source under a closed commercial licence if he so chooses - provided he
so licences only his original code plus any additional code he added himself
(ie, no GPLed user supplied patches)
There is a moral argument against this (in that a commercial licencee is
likely to use the most recent, not the supplied source, and so violate the
GPL behind closed doors) but there is no legal argument preventing it.
Treat it as a code fork at the moment the GPL licence was applied.